In April 2026, Microsoft shipped Agent Framework 1.0, the production-ready merger of Semantic Kernel and AutoGen into a single runtime with graph-based workflows and enterprise-grade state management. Around the same window, Anthropic added hierarchical subagent spawning to the Claude Agent SDK. Neither vendor coordinated with the other, yet both landed on the same architectural shape: a controlling agent that decomposes a task and delegates pieces of it to narrowly scoped subagents, rather than a set of peer agents talking freely among themselves. Independent surveys of the agent framework ecosystem through the first half of 2026 found the same convergence across five separate vendors and projects, all arriving at orchestrator-plus-isolated-subagents as the pattern that actually holds up once you move past a demo.
The timing matters. Gartner now projects that 40% of enterprise applications will carry an embedded agent by the end of 2026, up from under 5% a year earlier. That is not a gradual rollout, that is a land grab, and it means a lot of teams are choosing an orchestration shape under deadline pressure rather than by design. We spent the spring watching pilots stall on evaluation, governance, and identity gaps. The pattern showing up now is different: teams that do get a pilot shipped are running straight into an orchestration design they never chose deliberately, and paying for it in token bills and unreliable output. This piece is about making that choice on purpose, before the architecture makes it for you.
Research into how these systems actually behave describes five distinct shapes. Fan-out splits a task into independent pieces and runs them in parallel before gathering the results. Pipeline runs a sequence of agents where each one's output feeds the next. Debate has multiple agents argue different positions before a decision is reached. Supervisor has one agent hold the plan and delegate steps to specialists. Swarm lets a set of peer agents coordinate dynamically with no fixed hierarchy. Teams tracking production deployments through 2026 found that only three of these hold up once real users and real data are involved: an assembly-line variant of pipeline, a hub-and-spoke variant of supervisor, and a bounded version of fan-out where subagents work in parallel but never talk to each other directly. Open swarm and unstructured debate look impressive in a demo and then degrade in production, because peer agents start arguing past each other, loop on the same decision, or lose track of which agent owns which step.
Microsoft's Agent Framework formalizes this same choice explicitly by offering two orchestration modes rather than one. Agent Orchestration is LLM-driven and suited to open-ended reasoning tasks where the right next step genuinely depends on judgment. Workflow Orchestration is graph-based and deterministic, suited to repeatable business processes where the steps are known in advance and only the inputs vary. That vocabulary is useful even if your stack has nothing to do with Microsoft, because it forces the same question onto any framework: does this task need judgment, or does it need a repeatable sequence. Most production systems need both, in different parts of the same workflow.
Multi-agent systems use on the order of fifteen times the tokens of a single chat call, because the orchestrator itself makes multiple LLM calls to decompose the task and again to aggregate the results, on top of every worker call underneath it. Analysis of production deployments has found that token usage alone explains roughly 80% of the variance in how these systems perform against their budget, which means the line item most teams treat as an afterthought is actually the dominant cost driver in the whole architecture. A workflow that costs fifty cents against a handful of test cases can reach fifty thousand dollars a month once it runs at one hundred thousand executions, and the jump catches teams by surprise because nothing in the design changed, only the volume.
The prompt handed to a subagent is not a chat turn, it is closer to a function call with a natural language interface, and it should be written like one. The pattern that survives production gives every subagent a structured contract: a clear objective, an explicit output format, guidance on which tools and sources it may use, and firm boundaries on what is out of scope for that call. Each subagent gets its own dedicated system prompt written for its specific job, never a copy of the orchestrator's system prompt with the task pasted in underneath.
This matters more than it sounds like it should. A subagent without a defined output format returns prose that the orchestrator then has to re-parse, which adds a fragile extra step and burns more tokens doing it. A subagent without explicit task boundaries will happily wander into work another subagent was supposed to do, duplicating effort or producing two conflicting answers that the orchestrator has to reconcile. Treating the handoff as a strict contract, with inputs and outputs typed and validated the way you would validate any other internal API, removes an entire category of failure that shows up as vague, hard-to-reproduce bugs once the system is under real load.
How a subagent reports back matters as much as how it was instructed. Returning the subagent's full reasoning transcript to the orchestrator, rather than a concise summary of the result, is one of the more common and more expensive mistakes in these systems. Inlining a full transcript burns tokens at roughly the same fifteen-times rate described above, and it also pollutes the orchestrator's own context window with intermediate reasoning that was never meant to inform its next decision. An orchestrator working from a context window full of other agents' scratch work makes worse decisions than one working from clean, structured summaries, even though it technically has more information in front of it.
The fix is to make the subagent's return value a small structured object rather than a transcript: the result itself, a brief justification if one is needed, and any source references the orchestrator might have to cite later. Everything else the subagent produced along the way stays local to that call and never re-enters the shared context. This is the same discipline that separates careful context engineering from prompt engineering more broadly, and it applies with extra force in a multi-agent system, where every subagent's output becomes part of the orchestrator's working memory whether you intended it to or not.
The teams getting this right measure the shape of the task first, choose the orchestration pattern second, and pick a framework third, in that order. A task that is genuinely a fixed sequence does not need an LLM-driven orchestrator deciding what happens next, and a task that needs real judgment at each step will fight a rigid graph-based workflow. Get the first two decisions right and the framework choice becomes much less consequential than it feels right now, because the underlying patterns transfer across tooling and the tooling itself is still consolidating. A year ago AutoGen and Semantic Kernel were separate frameworks with separate communities; today they are one framework. Betting heavily on any single vendor's specific abstractions this early is a smaller risk than betting on the wrong orchestration shape for the workload in front of you.
The practical checklist we use with clients starting a multi-agent build is short. Default to a supervisor pattern unless the task has a genuinely fixed sequence or genuinely independent subtasks. Budget for the token multiplier before you write the first line of orchestration code, not after the first invoice arrives. Write every subagent prompt as a strict contract with a defined output shape, not a chat message. Return summaries across agent boundaries, never full transcripts. And validate the cost model against real execution volume before you let a pilot anywhere near production traffic. This is exactly the kind of architecture decision we walk clients through in our AI consultancy engagements, well before a single subagent gets written, because the pattern you pick on day one is the one you will be living with, and paying for, at scale.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.