Orchestrating Agents into Missions

Multi-agent systems almost never fail because one of the agents was wrong. They fail in the half-second between one agent finishing and the next one starting — and that seam is the part almost nobody is designing.

Watch a multi-agent run go wrong and the failure is rarely where you expect it. A mission to resolve a billing dispute begins well: the first specialist reads the ticket history, pulls the account record, walks the invoice line by line, and works out that the customer is right about two of the charges but wrong about the third, and — this is the important part — that the two bad charges exist because the account was migrated between plans mid-cycle and the proration ran twice. That is a genuinely good piece of analysis. Then the agent writes its handoff to the specialist that owns adjustments, and what it writes is: customer disputes three charges; two appear invalid; recommend credit. Every word of that is true. The adjustment agent issues the credit, closes the ticket, and does exactly the wrong thing, because the fact that the root cause was a migration artefact — the fact that this will happen again next month, to this customer and to everyone else who migrated that week — did not fit in the summary, and the summary was all it got.

Nobody in that chain made an error. The first agent reasoned correctly, the second acted correctly on what it was given, and the mission still produced an outcome that a competent human handling the whole case end to end would not have produced. The intelligence was fine; the continuity was not. Once you start looking for this pattern you find it everywhere in agentic systems: the research agent that discovers a caveat and passes on a conclusion, the triage agent that notices something odd and passes on a category, the planning agent that rejects three approaches and passes on the fourth without saying why the others were ruled out — so the executing agent, hitting a wall, cheerfully proposes one of them.

The summary is not the situation

The reason this keeps happening is structural, and it is worth being precise about it, because it is easy to mistake for a prompting problem. When one agent hands work to another, what passes between them is a compression. It has to be — the receiving agent cannot be handed the sending agent's entire working state, and even if it could, most of that state would be noise. So something summarises: a message, a structured payload, a field in a shared record. Compression is not the flaw. The flaw is that the compression is almost always performed by the agent that is finishing, using its own sense of what mattered, for a recipient whose needs it does not know. The sender compresses toward what I concluded. The receiver needs what I would have needed to know if I were you. Those are different documents, and only one of them ever gets written.

This is why the failure is so hard to catch in review. Read the transcript of a run like the billing one and every step defends itself. The analysis is sound, the handoff is accurate, the action follows from the handoff. There is no line you can point at and call a mistake, which is precisely what makes it dangerous: the system has laundered a loss of context into a chain of individually defensible decisions. Debugging tools that show you each agent's reasoning make this worse rather than better, because they invite you to audit the agents one at a time — and one at a time, they all pass.

The second structural problem is that context loss compounds rather than accumulates. Each handoff compresses what the previous handoff already compressed, so the fourth specialist in a chain reasons about a summary of a summary of a summary, several generations removed from the evidence. By then the qualifier that would have changed everything — this figure is provisional, the customer already tried this and it failed — has been rounded off in stages, each rounding locally reasonable. The system's confidence, meanwhile, does not decay at the same rate: downstream agents treat what they receive as settled fact, because nothing in the handoff marks it as an inference rather than an observation. Long chains therefore become simultaneously less grounded and more assured, which is close to the worst possible combination in a system permitted to act.

Every organisation already knows this problem by another name

None of this is new. It is the oldest failure mode in operational work, and every industry where handovers carry real consequence has already learned it the hard way. A hospital's shift change is a handoff problem: the outgoing nurse knows which patient's family is difficult, which line has been troublesome, which reading looked fine but felt wrong, and the handover sheet has fields for none of that. An aviation crew change, a control-room turnover, a case passing from underwriting to servicing, an account moving from the people who sold it to the people who must now deliver it — each is a moment where one party holds a rich situational picture and transmits a thin artefact, and each is where the incidents cluster. Organisations that take this seriously do not solve it by telling people to write better notes. They solve it by specifying the handover: making it a structured, rehearsed, non-optional act with a defined minimum content, an explicit statement of what is uncertain, and an obligation on the receiver to read back what they understood.

That is the part worth carrying into agent design, because it locates the discipline in the right place. The hospital does not fix handover quality by hiring better nurses, and you will not fix it in your agent system by using a stronger model for each specialist. A better model produces a better summary of what it thought was important, which is an improvement in the wrong dimension. The improvement that matters is defining, in advance and independently of any single agent, what a handoff in this kind of mission must always carry — the evidence behind the conclusion, the confidence attached to it, the alternatives considered and discarded, the constraints the next actor must not violate, and above all the open questions the sender could not resolve. Notice that most of those are things the sending agent has no natural incentive to include. Its job felt complete when it reached a conclusion. The obligation to preserve the situation has to come from outside it.

Departments repeat this at a larger scale, and the analogy holds all the way up. When a company complains that sales oversold what delivery can build, or that a strategy decided at the top arrives at the front line as a slogan stripped of its reasoning, it is describing the same defect: each layer forwarded its conclusions and dropped the reasoning, so by the time the work reached the people who had to act, the why was gone and only the what remained. The organisation, like the agent chain, was never short of intelligence at any node; it was short of a discipline for what must survive the gaps between nodes.

Orchestration is deciding what must survive intact

This reframes what orchestration actually is. It is tempting to think of it as sequencing — which agent runs when, what calls what, how work fans out and rejoins — and that framing has produced a generation of tooling that draws very good graphs and still loses the migration artefact. Sequencing is the easy half. The hard half, the half that determines whether a run of specialists behaves like a team or like a game of telephone, is the deliberate decision about what each seam must carry, enforced whether or not the sending agent thought it was relevant.

Doing that well requires treating the mission, rather than the agent, as the unit of design — which is why the vocabulary of platforms built for this work tends to elevate the mission itself. In StudioX's framing, Specialist Agents do not simply message each other; they work inside an AI Mission that holds the shared situation, with a Reasoning Core presiding over it and Observations recorded as part of the mission's own memory rather than as a private note in one agent's head. The point of that architecture is not that any individual agent is smarter. It is that the mission, not the message, is where continuity lives, so a specialist activated late in a run can consult the situation rather than only the summary handed to it. This is also where Human-in-the-Loop earns its place: the moments most worth escalating are usually not the ones where an agent is uncertain about its own task, but the ones where something the mission knows and the current agent does not would change the answer — a distinction only visible from the mission level.

Getting this right is also, quietly, what separates the agentic deployments that survive from the ones that get quietly shut down. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing unclear business value and inadequate risk controls among the reasons. Both of those symptoms have a common cause that rarely gets named: a system whose individual steps are all defensible but whose end-to-end outcomes are unreliable is impossible to value and impossible to govern, because you cannot point at what went wrong. The organisations writing seriously about the operating discipline of the autonomous enterprise keep arriving at the same conclusion from the other direction — that reliability at scale comes from the design of the joints, not the strength of the parts.

So the mental model worth adopting is this: stop picturing a multi-agent system as a set of workers and start picturing it as a set of doorways. The agents are the rooms, and rooms are relatively easy to furnish. What determines whether the work arrives intact is how wide you cut the doors, and what you require every passer-through to bring with them. Judge your architecture accordingly — not by how capable any single specialist is, but by asking what the last agent in the chain can still reconstruct about the first agent's situation. If the answer is the conclusion but not the reason, you do not have an orchestration layer. You have a very expensive game of telephone with a plan attached.