Handoffs between agents: passing context without losing details

The rescheduled appointment that went wrong. Picture a small beauty salon that runs on an agent team. A customer named Sara sends a message: can I move my Tuesday three o'clock to Thursday morning, same deposit? The manager agent reads it and passes a note to the booking agent that says "customer wants to reschedule." The booking agent finds a Sara, picks Thursday at nine, and charges a new deposit. Every agent did its job, and the result is still wrong. Nothing broke. Details just fell out between agents. Passing work from one agent to another is called a handoff, and it's where most multi-agent systems quietly lose money and trust.

What you will learn. In this lesson you'll learn three things. First, what a handoff really is, and the three ways details slip through when one agent passes work to another. Second, how to design a handoff packet, a small structured note that travels with every task so nothing important depends on memory or guesswork. And third, how a worker agent hands the work back: a result, a clear status, or a question when something is unclear. By the end you'll be able to look at any handoff in your own automations and say exactly what it carries and what it might drop.

A handoff is a relay baton. Think of a relay race. Here's the sender, the runner who has done their part of the lap and is about to let go. Now look at the baton. It's the only thing that actually moves between them. Whatever isn't in the baton stays behind with the first runner. And here's the receiver, already moving, who can only work with what lands in their hand. In an agent team, the manager is often the sender, a worker is the receiver, and the baton is the message the manager writes. The receiver never sees the original conversation unless you put it in the baton.

Three ways details get lost. Let's trace Sara's message through the team. Slow down here, because each loss looks harmless on its own. The first loss is summarising. The manager is a language model, and it loves short summaries, so "move my Tuesday three o'clock to Thursday morning, same deposit" becomes "wants to reschedule." The time and the deposit vanish. The second loss is paraphrasing. Even when the time survives, "Thursday morning" may be rewritten as nine o'clock, which is a guess dressed up as a fact. The third loss is missing links. The note says Sara, but not which customer record or which booking. The booking agent has to search, and searching is where it picks the wrong one.

The handoff packet. The fix is a handoff packet. It's like a work order in a repair shop: the same boxes every time, so nobody forgets to fill one in. It has four parts. The task is one clear action name, like reschedule booking. The facts are the details as separate fields: customer ID, booking ID, the new date and time window, deposit rule. The original is the customer's message copied word for word, so the worker can check anything the manager got wrong. And done when says what finished looks like, for example booking moved and confirmation text sent. In no-code tools like n8n or Make, this packet is simply the JSON object you pass from one step to the next. JSON is just a simple text format of named fields and their values, like booking ID: B-2207.

Worked example: check the packet first. Here's the packet for Sara's request, written as JSON. Each line is one field with its value. Notice the date is Thursday the eighth, and the time stays a window, morning, exactly as Sara said it, not a guessed hour. Now the gate. Mark which fields are required, then put one check step at the start of the worker. In n8n that's an IF node that asks: is any required field empty? Right now every field is filled, so the packet passes and is safe to hand over. Now imagine a sloppy manager leaves the booking ID blank. The IF node stops the task and sends back needs info, before the booking agent ever touches the calendar. That one gate catches missing details in seconds. Wrong details, like a guessed time or the wrong Sara, are caught by the other two habits: keeping the original message, and looking records up by ID.

Point with IDs, not names. Look at these two customer cards. Both say Sara. A small business with a few hundred clients will have repeats very quickly, and a language model will happily pick the first match it finds. So inside a packet, every person, booking, invoice or order is pointed at by its ID, the unique code your booking system or CRM already gives it. Names can travel too, but only as a friendly label. Here's a simple habit to adopt: the worker reads the ID, then fetches fresh details from the system itself, instead of trusting whatever the manager typed. That way, a typo in a handoff can't become a wrong appointment.

Handoffs across the whole team. Now let's zoom out to the whole team. It starts when a customer writes in and the manager agent reads the message. The manager has two workers, a booking agent and an invoice agent, plus a handoff log. Let's follow one request all the way through. The manager sends a packet to the booking agent. The booking agent moves the appointment and sends a result packet back. The manager builds a new packet for the invoice agent, which moves the existing deposit to the new booking and reports that the updated invoice was sent. Finally, every packet is saved to the handoff log. That log is a gift: when something goes wrong, you can read exactly what each agent was told.

Handing work back: result or question. A handoff goes both ways. When the worker finishes, it returns a small packet too. The status says done, failed, or needs info. The result says what changed, using IDs, like booking B-2207 moved to the eighth, at the slot Sara chose. And when something is unclear, the worker returns a question instead of a guess. So what should the booking agent do if Thursday morning has two free slots, nine and eleven? It shouldn't pick one. It returns needs info with the question, which slot does Sara prefer, and the manager asks the customer. One short question costs far less than an angry client.

Common mistake: everything or almost nothing. The most common mistake comes in two opposite forms. The first is the pile: forwarding the entire chat history, every email and every note to each worker. It feels safe, but the important detail gets buried, the model gets slower and costlier, and it may act on an old request from last month. The second is the sticky note: a one-line summary that leaves out the time, the amount and the IDs. Both fail for the same reason, which is that nobody decided what the worker actually needs. The fix is the packet: named fields for the facts, plus the one original message that started this task.

Exercise: design one packet. Here's your task before the next lesson. Pick one real handoff from a small online business, yours or an imagined one. For example, the manager passing a qualified lead to the booking agent, or the booking agent passing a finished appointment to the invoice agent. Write its handoff packet as JSON with every field it needs, including the original message and a done when line. Then mark the required fields and add a gate, like an IF node in n8n or a filter in Make, that stops the task when one is empty. Test it by leaving one field blank and watching the gate catch it. Keep it small, one handoff done well.

Recap. Let's recap. A handoff is the baton between agents, and the receiver only gets what's inside it, so details lost there are lost for good. Use a handoff packet every time: one task name, the facts as fields with IDs instead of names, the customer's original words, and a clear done when. A quick gate before the worker starts catches anything missing. And make workers hand back a status, a result with IDs, or a question, never a guess. With just these habits, your agent team stops playing telephone and starts working like a well-run front desk. Next lesson, we'll add a checker agent that reviews the work.