What are the four pieces every framework has?
Compare any two agent frameworks released in the last year and the differences are mostly naming. Underneath, all of them separate planning from execution, keep tools in a registry with typed schemas, persist state outside the loop, and wrap the whole thing in something that can stop it. The vocabulary changes; the architecture does not.
The consequence for buyers is worth stating plainly. Convergence is good news for portability and bad news for anyone betting on framework lock-in as a moat, because the pieces are substitutable. What survives as differentiation is the supervisor: how failures are detected, and what happens after they are.
Who designs the team now?
Until recently a developer configured a coordinator and a roster of subagents by hand. Anthropic's dynamic workflows move that step into the model: a lead agent drafts a plan and Claude then writes an orchestration program that launches agents, gathers their results and controls how information moves between them. Developers can still hand it preconfigured specialist subagents.
The demonstration was deliberately modest, a stock watchlist scanner in which a scan phase gave each ticker to its own agent with an isolated context and a review phase checked the findings before a report was written. The economics were stated honestly: the flow cost much more than a single agent doing the same job, and was much more effective at finding the details. That is the trade to price, not a free improvement.
The limits named in the session are the useful part. The model does not know its budget while it runs, so developers set a session budget instead. Subagents share a filesystem and can exchange information through it, but there is no way to tell one subagent to message another. Every hand-off is inspectable, with a graph showing the payload the lead agent passed at each transition.
| Piece | What it does | What to ask |
|---|---|---|
| Planner | Decides what to do, separately from doing it | Who writes the plan now, the developer or the model? |
| Tool registry | Holds tools with typed schemas | How are errors and partial or streamed calls surfaced? |
| State store | Persists context outside the loop | What is kept between turns, and for how long? |
| Supervisor | Detects failure and stops or redirects the run | What triggers a stop, and what happens next? |
| Budget | Bounds cost over a session | Does the model know its budget, or only the session? |
| Hand-off record | Shows what passed between agents | Can you inspect the payload at each transition? |
What does the orchestration layer not control?
Where the work physically runs, and that turns out to matter more than the framework choice. Mixture-of-experts serving changed which tensors are active for any given token, and therefore which parts of a cluster have to sit close together, which transfers need strong local bandwidth and which can tolerate a weaker link. Those distinctions decide how much of a cluster's nominal throughput is actually useful.
The unit of work is the turn: a request and its answer. In modern systems a large share of turns are not typed by a person — a client application intercepts parts of the answer as instructions, executes them and returns the results as further requests. The server keeps a context, the KV cache, which lets each new request be interpreted against what came before.
One consequence is worth carrying into any capacity conversation. When a user launches an agent on a long-running task there can be thousands of turns an hour, and the conversation can pause and resume hours or days later. That load profile puts weight on cache retention and scheduling rather than on raw arithmetic, which is why a decentralised network advertising aggregate throughput is describing the part that matters least.
Where does orchestration meet the business?
At context, and the fight over who holds it. Forrester's Wave on revenue orchestration platforms assessed 12 providers and found that persistent understanding of customers and opportunities, built from signals, activities and outcomes, has become a contested asset: buyers want it shared across systems, users and agents, while many providers try to keep it inside their own platforms even while adopting sharing standards. Its question is the sharp one — if five platforms each claim a complete view of the customer, is the organisation building shared context or competing versions of it?
The same report found that building agents is now table stakes and the discussion has moved to governance, oversight, interoperability and auditability. That is the supervisor again, in procurement language: the pieces are commodity, and what is worth paying for is how failure is caught and who can audit the result.
Questions
- What are the parts of an agent orchestration layer?
- Four, in every framework released in the last year: a planner separated from execution, a tool registry with typed schemas, state persisted outside the loop, and a supervisor that can stop the run. The naming differs between frameworks; the architecture does not.
- Does the choice of agent framework still matter?
- Less than it did for portability, more than it did for operations. Because the four pieces have converged they are substitutable, so lock-in is weak. What differentiates is the supervisor: how failures are detected and what happens next.
- What does it cost to let the model write the orchestration?
- In the demonstration Anthropic gave, the flow cost much more than a single agent doing the same job and was much more effective at finding the details. The model also does not know its budget while running, so developers set a session budget instead.
- Why does serving hardware affect agent performance?
- Because mixture-of-experts serving depends on what sits physically close to what, and an agent on a long task can generate thousands of turns an hour then resume days later. That profile loads cache retention and scheduling rather than raw arithmetic, which aggregate throughput figures do not describe.