A team demos two agents talking. One researches. One drafts. They pass notes in plain English. The chat looks smart. Everyone relaxes.
Then a bad run hits review. Nobody can say which note added the wrong assumption. Nobody can say what "done" meant. Nobody can say which agent was allowed to invent missing details.
The talk was fluent. The ownership was missing.
That is the pattern. Freeform agent chat is not design. It is design postponed.
Chat feels like progress. It hides the hard part.
People work in language, so agent language feels natural. It also hides four questions:
- What is ready enough to send?
- What is complete enough to accept?
- What may the next agent invent when something is missing?
- What happens when the handoff fails?
With one agent, those questions stay in one place. With many agents, they become the system.
Skip them and you still get text. You just lose accountability.
That is why agent-to-agent systems are a different game. The hard part is the seam, not the model size.
Write the handoff as five plain lines
Treat every hop like a small contract:
- Ready - what must be filled before send.
- Done - what must be filled before accept.
- Authority - what the next agent may decide, and what it must escalate.
- Failure - retry, stop, escalate, or ask. Name it.
- Evidence - what travels with the message so a human can rebuild the hop.
If you cannot write those five lines, the agents are not collaborating. They are guessing.
This feels stiff until the first quiet failure. Then it feels necessary.
Plain English can ride inside rules. It cannot replace them.
You can still use short prose. The mistake is using prose as the only rule.
Weak hop: "Here is what I found. Take it from here."
Better hop: clear fields, a short why, open questions marked as open, guesses marked as guesses.
The next agent should not hunt for what is fact, what is guess, and what is leftover scratch. That hunt is how mush becomes confident mush.
If you cannot see which check passed or failed, you do not have a clear system. You have a chat log. That gap shows up again when orchestration is treated as plumbing instead of product.
What this is not
This is not "never use multi-agent."
It is "do not mistake a talking demo for interaction design."
A fleet can be right when roles truly split. It is wrong when the team wants the feeling of teamwork without paying for rules, checks, and traces.
Also not: "only JSON forever." Humans will read the bad runs. Design for machine checks and human reading.
Do this on Monday
Pick one live hop between two agents. Write the five lines. Run the next five jobs against them.
- Easy to satisfy? Keep the hop.
- Agents keep breaking it? The split is wrong, or "ready" is fantasy.
- Humans cannot rebuild a failure from the evidence? Not ready for production.
Do not add a third agent until that hop is boring.
Take-home
- Agent chat without rules speeds up confusion.
- Write ready, done, authority, failure, and evidence for every hop.
- Prose can sit inside a clear handoff. It should not be the handoff.
- Keep the fleet small until seams are easy to read.
Related reading:
- Agent-to-Agent Systems Are a Different Game
- Confident Wrong Output Marked Done Is the Agentic Failure Mode
- Design the Escalation Layer Before You Add More Agents
- Orchestration Is a Product Surface, Not a Backend Detail
- The Agent Handoff Is the Product Surface
- What the Spec Doesn't Decide, the Model Will
If you want agent handoffs reviewed before the fleet grows, book a discovery call.