Hand-offs: when one agent passes to the next

A fleet earns its name the moment one agent's output becomes the next agent's input without you carrying the baton between them, because that is when work flows through the org chart instead of through you.

You have agents wired to their data and their triggers. Now you chain them, so research flows into a draft, the draft flows into a review, and the review flows into a scheduled send. The conductor pattern is what makes this a workforce rather than a pile of disconnected automations, and it is also where you decide the handful of points at which a human still has to step in.

What a hand-off actually is

A hand-off is a contract: agent A guarantees an output in a known shape, and agent B knows how to read exactly that shape as its input.

The contract is the whole trick. If the research agent always produces a brief with the same headings, the drafter can be built to expect those headings, every time. If the drafter always produces a draft in the same structure, the reviewer can check it against a fixed list. When the shape is stable, the baton passes cleanly. When the shape wobbles, the next agent chokes, and the chain breaks at the seam. So every hand-off needs a defined output format on the upstream side and a matching expected input on the downstream side.

This is why chapter two insisted on one job per agent. A single-job agent produces a single, predictable output shape, which is exactly what makes it safe to hand off.

The conductor pattern

You do not let agents call each other freely; you put a conductor in the middle that sequences the chain and holds the state.

The conductor is the orchestration layer doing its real job. It runs the researcher, waits for the brief, passes the brief to the drafter, waits for the draft, passes the draft to the reviewer, and only then routes the approved output to the scheduler. The conductor knows where the work is in the chain at any moment, so when something stalls you can see which hand-off it stalled at. Agents stay dumb about each other; the conductor stays smart about the sequence. That is the pattern that scales, because adding a step means adding one node to the conductor's sequence, not re-teaching every agent who comes next.

The mid-chapter reframe worth holding: you are not building a chat that does everything, you are building an assembly line where each station does one operation and the conveyor between them is the conductor. Assembly lines are debuggable and improvable station by station; a single genius pass is neither.

Where you stay in the loop

Full automation end to end is the wrong goal; the right goal is automation with a human gate at the points where being wrong is expensive.

Decide, per chain, where a human approval sits. A safe default for client work is to let research, drafting, and review run unattended, but to require your sign-off before anything reaches a client or moves money. The conductor pauses the chain at that gate, shows you the output, and waits for a yes. Everything upstream of the gate runs while you sleep; the gate is the one place your judgement is non-negotiable. As your trust in a chain grows you can move the gate later, but you start with it early, because an unattended chain that sends to a client on day one is how a fleet does damage at speed.

A worked example: a four-agent client-report chain

Take a freelance data analyst who produced a monthly performance report for eight clients, each report taking the better part of a day to assemble by hand.

• Challenge. Each report needed data pulled from several dashboards, a written narrative explaining the numbers, a quality pass to catch mistakes, and delivery on a fixed date. Eight clients meant roughly eight full days a month lost to assembly, and a tired pass occasionally let a wrong figure through.
• Approach. She built a four-agent chain run by a conductor. The research agent pulled and reconciled the month's metrics into a fixed brief; the drafter wrote the narrative from that brief; the reviewer checked every figure in the narrative against the brief and flagged mismatches; the scheduler delivered the approved report on the client's date. The conductor sequenced all four and paused at a human gate before delivery, where she gave a final yes.
• Result. Assembly time per report dropped from about 7 hours to about 45 minutes of review, reclaiming roughly 50 hours a month across the eight clients. Because the reviewer checked every figure against the source brief, the wrong-number errors that used to slip through monthly fell to zero over the following quarter. The chain replaced six working days a month with a single afternoon of approvals.

Pitfalls in chaining agents

• Unstable output shapes. If the upstream agent's format drifts, the downstream agent silently mis-reads it. Lock each agent's output format and have the conductor validate it before passing on.
• No human gate before send. A fully unattended chain will eventually send something wrong to a client at machine speed. Keep an approval gate before any irreversible step until the chain has earned trust.
• A conductor that loses state. If the orchestrator cannot tell you where a stalled job stopped, you cannot debug the chain. Use an orchestrator that shows the run's position at each hand-off.
• Chaining before each agent works alone. Wire and verify each agent in isolation first; chaining amplifies a single broken agent into a broken pipeline.

INTERVIEW EWOUD: Tell the story of the first agent hand-off that broke in your own fleet. What was the contract that wobbled, what reached the far end mangled, and what gate did you add so it could not happen again?

With agents chained and a human gate in place, the fleet produces work end to end. The remaining risk is the quality of what comes out of that gate, which is the next chapter: quality control so a bad output never reaches a client.