Google suggestions now put agent handoff pattern beside agent handoff prompt, agent handoff vs subagent, LangGraph, Copilot, VS Code, and GitHub Copilot. That is a useful signal. Developers are not only asking for a schema. They are trying to decide when one agent should stop, when another should start, and what state has to cross that boundary.
The thesis is simple. A handoff pattern is not a nicer sentence at the end of a chat. It is a small ownership transfer: who has the work now, what changed, what should happen next, and which artifact proves the state. If that transfer lives only in prose, the receiving agent is guessing.
An agent handoff pattern starts with ownership, not politeness
Human handoffs can be loose because humans bring memory, judgment, and social context. Agent handoffs get less help. The receiver sees whatever the host gives it on the next turn. If the action is buried after a friendly recap, the model may read the paragraph and still miss the job.
That is why Parler treats handoff as protocol state instead of a convention. A room message can include a com.parler.handoff part with next, summary, to, and an optional bundle. The deeper wire contract is covered in an agent handoff protocol is how work survives the boundary. The pattern question is different: when do you use that contract, and what do you put in it?
| Weak handoff | Useful handoff pattern |
|---|---|
| See above | Review PR #42 and list merge blockers |
| I think this is done | Tests passed, docs updated, migration still needs review |
| Handing to reviewer | to: reviewer, next: audit the diff, bundle: exact commits |
| Long transcript | Short summary plus cursor-backed room history |
Four agent handoff patterns that show up in real work
Most teams do not need a dozen handoff types. They need four boring ones that match how work already moves.
- Planner to builder. The first agent turns intent into a task list, then hands the next concrete action to the coding agent.
- Builder to reviewer. The builder stops changing code and hands over the exact diff, test status, and known risk.
- Specialist pickup. Work goes to a role such as review or docs, and whichever registered agent can serve that role picks it up.
- Human visible transfer. A conversation moves from one host to another while the backlog stays inspectable, not pasted into a new prompt.
Those patterns all use the same Parler primitive: a durable room with per-reader cursors. The membership and addressee change. The state model does not. That is the same design line behind multi-agent communication patterns need rooms, not one-off callbacks.
A handoff prompt is not the handoff pattern
The autocomplete cluster includes agent handoff prompt, which makes sense. Prompts are where people feel the failure first. The old agent ends with a tidy paragraph, the new agent says it understands, and then it works from a stale or partial picture.
A prompt can teach an agent how to write a better summary. It cannot provide durable delivery, unread state, role routing, or an attached code bundle by itself. If the transport still drops the message, or the receiver still has to re-read a whole transcript, the prompt is doing protocol work it cannot reliably do.
sender finishes its part
-> writes handoff into the room log
-> names the next owner or role
-> attaches the artifact if prose is not enough
-> receiver reads from its cursor and sees the handoff first
If the handoff would fail after the receiver restarts, it is not a pattern yet. It is a chat habit.
Agent handoff vs subagent is a boundary question
The phrase agent handoff vs subagent is the most interesting part of the search cluster. It points at a real decision. If one runtime owns the whole loop, a subagent call is often fine. The parent process can pass state directly, wait for the result, and keep control.
A handoff is for the moment that assumption breaks. The next worker may run in another process, another editor, another machine, or another owner's account. Then the transfer needs addressable identity, durable room state, and a clear next turn. That line is close to the one in most AI agent collaboration is one process wearing a costume.
| Use a subagent when | Use a handoff when |
|---|---|
| One host controls the loop | Another host or process may continue the work |
| The parent can hold all state | The state has to survive outside the parent |
| The result comes back immediately | The receiver may be offline or join later |
| No artifact crosses a trust boundary | The receiver needs the actual file, diff, or bundle |
What the Parler handoff pattern looks like
In Parler, the pattern is intentionally small. Send normal messages while agents are exploring. Use a typed handoff when ownership changes. Put the action in next, put the current state in summary, route by name or role with to, and attach a content id when the next step depends on an artifact.
parler handoff --room team --for reviewer --summary "feature branch is ready, unit tests pass, migration needs a second look" --next "review the diff and call out blockers before merge" --bundle <content-id>
The receiver does not need to scrape the whole room looking for intent. When it reads, the matching handoff can be led as the thing to act on. If the socket was down, the unread message is still in the log above that agent's cursor. Push makes it fast. The cursor makes it safe. For the transport side, read real-time messaging for AI agents needs a socket, not a request.
A useful agent handoff pattern has five checks
- One next action. Do not hand over a paragraph with three possible jobs.
- One current state. Summarize what is true now, not every step that happened.
- One owner or role. If anyone can pick it up, say that. If a reviewer should pick it up, route to that role.
- The artifact when needed. Code, files, and diffs should cross as artifacts, not as descriptions.
- Replay after failure. The receiver should recover from its own cursor, not from a human recap.
This is why how AI agents hand each other code is not a side story. For coding agents, artifact transfer is often the difference between a handoff and a rumor.
Bottom line
If you are searching for an agent handoff pattern, start with the boundary. Is this still one runtime calling a helper, or is another agent taking ownership of the work? Once ownership changes, stop hiding the job in prose. Name the next action, name the owner, carry the state, and attach the thing the next agent must inspect.