Learn index
Pattern

Three-agent handoff pattern

The three-agent handoff pattern splits a workflow into implementation, testing, and review agents, then uses claims and handoffs to keep state moving without losing ownership.

Use this as the first real multi-agent workflow.

  • Teams trying their first multi-agent engineering workflow
  • Operators who want a small repeatable pattern before scaling
  • Engineering leads evaluating whether agent work can be supervised cleanly

Three agents reveal the coordination system quickly

Many teams jump from one agent to many agents without a coordination pattern. The result is parallel activity, not parallel progress.

A three-agent loop is small enough to supervise and rich enough to expose the real issues: scope ownership, test evidence, review context, and human intervention.

Give each role a boundary and a handoff

Midfleet gives each agent a role and connects them through explicit handoffs. The implementation agent claims the feature scope, the test agent claims validation scope, and the review agent receives the final state with evidence.

The operator watches the loop, resolves blockers, and intervenes when a handoff is unclear or a claim overlaps.

Role table for the first run

The pattern works because each agent has a different job and a different ownership boundary.

Implementation
Owns the feature change and primary code paths. Success is a bounded implementation handoff.
Testing
Owns validation scope and evidence. Success is a clear pass/fail state with failed checks explained.
Review
Owns risk review and readiness. Success is a merge, revise, or reassign recommendation.
Operator
Owns intervention. Success is knowing where the workflow stands without reading every log.
Do not add a fourth agent until these three roles can hand off cleanly.

Run the pattern

01stage

Implementation agent claims feature scope

It reserves the primary files and builds the change inside a bounded area.

02stage

Implementation hands off to test agent

The handoff includes changed scope, assumptions, and known risk.

03stage

Test agent claims validation scope

It reserves test files, runs checks, fixes test-only issues, and records evidence.

04stage

Test agent raises blockers if needed

Ambiguous failures or missing decisions go to the operator instead of being guessed through.

05stage

Review agent receives final handoff

It reviews the combined state, evidence, and unresolved risks.

06stage

Operator decides next action

Merge, revise, reassign, or run another loop with clearer ownership.

What to avoid

  • Letting all three agents touch the same scope at once.
  • Skipping evidence in the handoff between implementation and testing.
  • Using the review agent as a vague critic instead of a bounded reviewer.
  • Adding more agents before the three-agent loop is reliable.
  • Letting blockers sit outside the coordination surface.

Questions teams ask next

Why three agents?

Three is enough to separate implementation, testing, and review while still keeping the workflow easy to observe.

Can one agent play multiple roles?

Yes, but the pattern is most useful when ownership changes are explicit. Even one agent can hand off between phases if the state is captured.

What is the success signal?

The operator can explain who owns what, what changed, what evidence exists, and what should happen next without reconstructing it from scratch.

Bring us the workflow. We will shape the control path.

Midfleet Learn explains the model. Private preview proves it against a real engineering workflow with agents, ownership, handoffs, blockers, and operator visibility.

Request private preview ->