LangChain's discussion of Sierra's architecture gives a very specific reason to be cautious about multi-agent decomposition.
Split triage from task execution and the task worker can lose information the triage step learned. The triage worker, meanwhile, may not have the procedural knowledge needed to understand what execution actually requires.
Then OpenAI's Agents API makes the complementary case. Complex work can be delegated to subagents when it separates cleanly into independent pieces, each with a focused context, while a coordinating agent retains responsibility for the overall task.
I don't read those as competing universal rules. Sierra is a practitioner architecture example, not a controlled benchmark proving that one agent is generally better. OpenAI's subagent model does not establish that every complex task should be decomposed.
What they expose is a boundary condition.
Every delegation boundary changes what information stays locally continuous. The boundary earns its place only when the advantage created by the separate worker is larger than the cost of transferring, rediscovering, or reconstructing the context that no longer comes along for free.
Delegation changes the information topology
One worker carrying a task from beginning to end does not need to formalize every useful thing it learned into a handoff.
The user's objective can stay beside the evidence that changed the plan. A rejected path can remain visible beside the reason it was rejected. Tool results, partial work, stop conditions, and unresolved uncertainty can all remain inside the same active lineage.
A second worker does not automatically inherit that continuity, so the system now has to decide what gets transferred, what can be rediscovered, what should stay hidden for isolation, and what can safely disappear.
That is why I find the interface framing useful. An agent boundary behaves a little like an API boundary inside an evolving problem. The new interface can be valuable, but it also forces previously local knowledge to become explicit enough to cross it.
Three kinds of context are especially easy to lose:
| Context | What it carries | What omission can do |
|---|---|---|
| Task or problem context | Goal, relevant history, evidence, rejected interpretations, unresolved questions, why this branch exists | Produce a competent answer to the wrong version of the problem |
| Procedural context | Allowed tools, source-authority rules, verification requirements, exclusions, stop conditions, success criteria | Produce work that looks useful but violates the operating contract |
| Execution state | Completed steps, partial artifacts, tool results, failed attempts, changed assumptions, live environment state | Duplicate work, use stale assumptions, or repeat a failure the parent already discovered |
Those labels are my synthesis of the source material, not vendor terminology.
They also do not imply that every subagent should receive the entire parent context. Focused context is one of the reasons decomposition can help.
The point is narrower:
The system needs to know which information is load-bearing before it decides that omission is cheap.
Missing context usually returns as work
A bad handoff rarely announces itself as a missing-context error.
More often, the cost reappears later.
The child agent searches for information the parent already found. It reopens files. It infers why a decision was made from the artifact left behind. It repeats an experiment that already failed. It returns an answer that the coordinator has to reinterpret against the original objective because the branch solved something adjacent rather than exact.
That is reconstruction cost.
Some reconstruction is deliberate and useful. Independent review, for example, can benefit from not inheriting the generator's full reasoning because the separation reduces anchoring. Permission isolation can justify a narrow context even when it adds coordination. A specialist tool environment may be worth the extra handoff because the branch can do something the parent cannot.
Accidental reconstruction is different. The system pays to create the boundary and then pays again to rebuild the information the boundary removed.
The bill is not only tokens; it can show up as latency, duplicated tool calls, inconsistent assumptions, more verification, more coordinator work, and more opportunities for state to drift while workers operate from different snapshots.
A workflow can become more modular on paper while becoming harder to keep coherent.
Parallel work is not automatically independent work
The distinction between parallelizable and independent matters more than agent count.
Two research branches may be genuinely independent if they inspect separate source families under the same stable question. Two implementation branches may be independent if they touch isolated areas behind a clear contract. Two reviewers may be intentionally independent because disagreement is useful evidence.
Those branches can receive bounded packages, work locally, and return results without repeatedly asking what the parent meant.
Other work only looks parallel.
A worker evaluating an option may depend on why earlier options were rejected. A writer may depend on qualifications discovered during research. An implementer may depend on live state that changed during diagnosis. A task agent may need not only the selected instruction but the evidence that made it the selected instruction.
Separate agents can still perform those jobs, but the architecture just has to pay for the coupling it introduced.
This is adjacent to the broader context-system problem I wrote about in The Context Window Is the Last Mile, but the decision boundary is different. A context system can retrieve, compress, and scope information well while still creating a poor delegation interface. Here the question comes earlier: should another lineage exist for this piece of work at all?
A boundary should buy something concrete
Delegation has several real advantages.
A separate worker can run in parallel. It can use a different model or tool environment. It can hold a deep local context without filling the coordinator's working set. It can operate under narrower permissions. It can provide an independent judgment. It can isolate a risky or noisy branch from the main task.
Any of those can justify the handoff.
"Another agent can own this part" is weaker. A role label tells me how the diagram is organized. It does not tell me what the boundary improves.
That is the part I would make explicit before fan-out. The system should be able to name the advantage it expects from the new worker, then compare that advantage with the context that stops being locally continuous.
Otherwise the design can quietly ship its own coordination problem.
A five-question pre-fan-out check
Before creating another worker, I would ask five questions.
-
What context stops being locally continuous? List the goals, evidence, rejected paths, operating rules, current state, and unresolved uncertainty the parent currently holds that the child will not automatically share.
-
Can that context cross the boundary cleanly? Some information fits into a stable task contract. Some is cheaply discoverable from a canonical source. Some exists as a fast-changing sequence of observations and decisions. The last category is usually the expensive one.
-
How independent is the branch in practice? Can the worker complete the task without repeatedly consulting the parent or sibling branches? A branch that needs upstream reasoning at every step is still coupled, even if it runs in another context.
-
What does specialization actually buy? Name the gain: parallelism, a specialist tool, a different model, reduced context noise, permission isolation, independent review, or deep local work. If the gain is vague, the handoff cost is hard to justify.
-
Where does the result return? This stops short of the separate post-fan-out problem of reduction and reconciliation. It still matters before delegation that someone can interpret the returned work against the original objective. Otherwise the system has delegated activity without establishing responsibility for what comes back.
None of those questions produces a universal threshold. The sources do not support one, and I don't think a useful threshold would be universal anyway.
They do make the trade-off inspectable.
The best handoff is not the biggest one
Passing the entire parent context is an obvious response to context loss, but it creates another failure mode.
Large handoff packets raise reading cost and dilute salience. The child can technically receive everything while still missing which facts are load-bearing. A full transcript is not automatically a good interface.
The useful target is smaller: preserve the minimum context that keeps the delegated unit semantically connected to the parent task.
In practice that usually means some version of the objective, relevant evidence, constraints, current state, required output, and conditions for stopping or returning upstream. What belongs in that package depends on the task. The principle is that compression should remove noise without severing the reasons the work is being done.
Good delegation does not preserve every token. It preserves causality.
Context is a budget for decomposition
I would not turn this into an argument for monolithic agents. The evidence does not support that, and the useful multi-agent cases are real.
Independent work can benefit from focused contexts. Specialist workers can justify their own environments. Review can improve when a second worker is deliberately insulated from the first. Parallel branches can reduce wall-clock time. Permission boundaries can be worth the coordination cost.
The mistake is assuming those benefits arrive automatically with another agent.
Every new boundary asks the system to convert live context into an interface. Some tasks make that conversion cheaply. Others lose exactly the information that made the task tractable in the first place.
That makes context a practical budget for decomposition, so spend it where the boundary creates a real advantage.
A cleaner diagram is not one.
// End of transmission. Make the boundary earn it — ZYANE