What is agent orchestration?

The definition

Agent orchestration is the coordination of several agents so they share context, hand work to each other, and complete a multi-step job reliably. Three verbs, and each is a place things break.

It is worth being precise because the word gets used for two different things. Orchestrating steps — do this, then that — is workflow automation, and a flowchart does it better. Orchestrating agents means coordinating parties that each decide what to do next, which is a harder and more interesting problem.

The two shapes of handoff

Every multi-agent system uses one or both, and they are not interchangeable:

• Delegation (parent to subagent). One agent hands a task down to a specialist, which runs in its own context and reports a result back. The parent's own conversation stays clean — it gets the answer, not the working. Right when the work is a step inside somebody else's job.
• Messaging (peer to peer). One agent asks another and waits for a reply. Both are full agents with their own memory, channels and responsibilities, and the pair accumulates a shared history. Right when the other party owns its domain.

Choosing wrongly is the most common structural mistake, and it is expensive to fix later because the two are configured differently — delegation in detail.

What travels, and what does not

The subtlest part. When agent A asks agent B for something, how much of A's context goes with the question?

Too much and B is reading a transcript of work it does not need, which costs money, slows the answer and degrades quality by burying the actual question. Too little and B asks clarifying questions A already answered, or guesses.

A good system makes this a design decision rather than an accident: the handoff carries the task and the relevant facts, not the history. If you are evaluating a platform, ask what travels — a vendor who has not thought about it has not run a real multi-agent system.

What breaks

• Loops. A asks B, B asks A. Trivially possible and surprisingly common once several agents can reach each other.
• Duplicated work. Two agents independently research the same thing because both were asked something adjacent.
• Silent failure. B never replies, A waits, and the job stops with nothing surfacing.
• Diffused responsibility. Three agents each did part of a task and none noticed the gap in the middle.
• The one-node team. Everything routes through a single agent that does the work itself. Common, hard to spot, and it means you are paying orchestration overhead for a single-agent system.

Four of those five are visibility problems before they are logic problems, which is why the ability to watch handoffs live matters more than it sounds.

Permission is not visibility

The control that prevents most of the above. Two separate questions:

• Which peers does this agent know exist?
• Which is it allowed to message?

Keeping them separate matters because an agent told about a dozen colleagues will try to involve them. Restricting the roster is how you prevent loops and duplicated work before they happen, rather than detecting them afterwards. A sensible default is to tell each agent about nobody except the colleagues it needs, and to generate messaging permissions from the org chart rather than hand-maintaining a matrix.

Where approval sits

One gate at the edge, not a gate per agent. If three agents collaborate on a customer email, you want one approval on the email leaving — not three approvals on internal handoffs, which trains everyone to click through without reading.

This is also why an audit trail has to span agents. "Who sent this?" has a useless answer if the record stops at the agent that pressed send rather than the chain that produced the content.

How to tell whether yours is working

One diagnostic, and it is visual: watch which agents actually talk. If the same node lights up for everything, you have one agent with extra steps — usually because the specialists were never given distinct enough jobs. If every node talks to every other, you have a committee, and the fix is restricting the roster.

A healthy team looks like an org chart in use: a lead fielding most requests, specialists handling their own domains, and traffic concentrated on a few well-worn paths. A real one, if you want to see it.