Agentic Coding: The Current State of Orchestration Patterns (2026)

As of mid-2026, orchestration in agentic coding (software development by LLM agents) is rapidly converging. Anthropic, OpenAI, Google, Microsoft, and Amazon have each put multi-agent frameworks into production, and the shared design challenges and points of divergence have become clear.

This note organizes the patterns of inter-agent communication, orchestration architectures, the design philosophies of the major frameworks, and the best practices that are converging.

Related: design-agent-tools-landscape-2026 (design agent tools) / agentic-experience-design-synthesis (AX and design) / mcp-design-agent-integration (MCP integration) / the roundtable on delivering multi-agent value (the value of multi-agent systems).

Five Patterns of Inter-Agent Communication

The design choice of how agents exchange information determines the performance, cost, and debuggability of the entire system. The patterns in practical use as of 2026 can be organized into five.

1. Hierarchical (Supervisor / Tool-Mediated)

A parent agent (orchestrator) invokes child agents as “tools” and aggregates the results. Children do not communicate with each other directly.

Suited to subtasks that can be decomposed independently. The parent can centrally manage quality gates, and retries and fallbacks are easy when a child fails. Because each child’s context is minimized, each child can concentrate on its specialty.

The parent becomes a bottleneck (all communication passes through it). Integrating many results tends to saturate the parent’s context window. Deep nesting increases latency and information loss.

Adopted by Claude Code (Agent tool), Claude Managed Agents (coordinator-worker), OpenAI Agents SDK (agent-as-tool), LangGraph (supervisor node), CrewAI (hierarchical process), Google ADK (AgentTool), Amazon Bedrock (supervisor mode), and MS Agent Framework (MagenticOrchestration)¹²³⁴.

2. Handoff (Transfer)

One agent passes control of the conversation and the entire history to another. It is a baton-relay approach; only one agent holds control at a time.

Suited to situations where the required domain expertise switches mid-conversation (such as department routing in customer support). The conversational context is not broken, and implementation is simple.

Parallel processing is not possible (linear). Misrouting can produce loops and dead ends. Because the entire history is transferred, it puts pressure on the context window. Not suited to complex dependency structures.

The OpenAI Agents SDK is distinctive in defining handoff() as a first-class primitive, and it is the representative implementation of this pattern. Its predecessor OpenAI Swarm (transfer_to_agent), LangGraph (conditional edges), and MS Agent Framework (HandoffOrchestration) also support it²⁵.

3. Shared State (Blackboard)

Multiple agents read and write a shared state object. There are no direct messages between agents; they communicate indirectly through changes to the data structure.

Suited to situations where multiple agents progressively enrich the same data structure, or where loose coupling is desired. Coupling between agents is low, and adding new agents is easy. Partial results are immediately visible to the whole system.

Managing state conflicts and consistency becomes necessary. Debugging who wrote what and when is difficult. Thread safety must be considered under parallel execution.

LangGraph’s StateGraph is the core of this abstraction, and the entire framework is built on top of this pattern. CrewAI (Flow’s Pydantic models, thread-safe proxies) and Google ADK (InvocationContext.session.state) also support it³.

4. Message Passing (Chat-Based)

Agents exchange text messages directly. Communication happens in a group chat (everyone sees every message) or pairwise, with speaking order decided by a manager or round-robin.

Suited to review, critique, consensus building, and multi-perspective analysis. Flexible exchange in natural language is possible, making it apt for discursive tasks.

Token consumption is large (every agent reads every message). Control is difficult (termination conditions must be designed), and it scales poorly. There is a risk of non-convergence.

AutoGen/AG2’s GroupChat is the representative of this pattern, and MS Agent Framework (GroupChatOrchestration) also supports it⁶⁷.

5. Context Isolation + Summary Return (Isolated Context)

Each subagent operates in an independent context window and returns only a final summary text to the parent. Intermediate steps (tool calls, reasoning processes) are invisible to the parent. It overlaps with the hierarchical pattern, but the design choice of “what to hide” is the core.

Suited to situations where a subagent’s exploration is extensive and the intermediate steps would pollute the parent’s context. It prevents context accumulation in the parent, and parallel subagents do not interfere with one another. Resetting the trust boundary (children do not inherit the parent’s privileges) is also an advantage.

There is information loss at summarization. The child’s reasoning process cannot be observed from the parent, so debugging requires separate tracing. All necessary context must be passed explicitly in the prompt.

Claude Code / Claude Agent SDK make this pattern their primary design principle. A subagent launches with a fresh conversation, and only the final message is returned. Claude Managed Agents likewise run each agent in an isolated session thread, displaying only a condensed activity summary in the primary thread⁸⁹.

Orchestration Architectures

On top of the communication patterns sits the architecture for structuring the task as a whole.

Architecture	Overview	Suited for	Main drawbacks
Pipeline	Fixed-order chain of steps; each step’s output becomes the next step’s input	Tasks whose order is naturally determined; gate checks can be inserted between steps	Latency accumulates; later stages cannot influence earlier ones
Fan-out/fan-in	Execute independent subtasks in parallel and aggregate; a variant runs the same task multiple times (voting)	Reducing latency for independent tasks; improving reliability through redundancy	Aggregation logic must be designed; cost is linear in the degree of parallelism
Router	Classify input and dispatch to specialist agents	Cases where processing differs fundamentally by input type	Routing accuracy determines system performance
DAG	Express dependencies as a graph; execute nodes whose dependencies are resolved	Situations requiring complex dependencies and partial parallelism	Dynamic task addition is difficult; design is complex
Orchestrator-worker	A central LLM dynamically decomposes tasks and delegates to workers	Situations where the decomposition itself is input-dependent and unpredictable	Cost is hard to predict; depends on the orchestrator’s capability
Evaluator-optimizer loop	Iteration of generate -> evaluate -> feedback -> regenerate	Iterative improvement with clear evaluation criteria	Cost/latency accumulate; no convergence guarantee
Debate/adversarial	Multiple agents argue from different positions to raise the quality of conclusions	Maximizing judgment quality; multi-perspective analysis	High token cost; risk of non-convergence

Anthropic organizes five workflow/agent patterns: “prompt chaining (pipeline),” “routing,” “parallelization (fan-out/fan-in),” “orchestrator-workers,” and “evaluator-optimizer”¹.

Fundamental Axes of Design Tension

Model-Driven vs Framework-Driven

Model-driven approaches (Claude Agent SDK, AWS Strands) minimize the framework’s decision logic and entrust the workflow to the model’s own reasoning, planning, and tool-calling capabilities. According to a codebase analysis of Claude Code (arXiv 2604.14228), AI decision logic accounts for 1.6% of the entire codebase, while the remaining 98.4% is infrastructure for permission management, context control, tool execution, and error recovery¹⁰.

Framework-driven approaches (LangGraph, Google ADK Workflow Agents) explicitly define control flow in code as graphs or DAGs. Routing logic lives in Python code, not in LLM prompts.

Model-driven has the advantage when tasks are unpredictable; framework-driven has the advantage when reliability and auditability are required. Neither is universally correct.

Context Strategy: Isolation vs Sharing

Approach	Representative	Characteristics
Isolation	Claude Agent SDK	Fresh context for subagents; intermediate steps invisible to the parent; solves context accumulation but incurs information loss
Full-history sharing	OpenAI handoff	Transfers the entire conversation history at handoff; maximal contextual continuity but increased context pressure
Structured sharing	LangGraph StateGraph	Explicitly defines the shared state with types; an intermediate choice but requires schema design

Measured data from Anthropic’s multi-agent research system (Opus 4 as lead, Sonnet 4 as workers) gives quantitative guidance on this axis of tension. Performance improved 90.2% over a single agent, but token consumption was roughly 15x, and 80% of the performance gain could be explained by token expenditure⁹ (the pattern of designing this hierarchy by model price is organized in Model Tiering Patterns). A design refinement shares the prompt cache across parallel subagents, making the cost of five parallel agents roughly equivalent to sequential execution⁸.

Design Philosophies of the Major Frameworks

Claude Code / Claude Agent SDK / Claude Managed Agents

Anthropic explicitly recommends “start simple, and go multi-agent only after the limits of a single agent have been proven”¹.

It provides three tiers of multi-agent support. The CLI level (Claude Code’s Agent tool), the SDK level (Claude Agent SDK’s AgentDefinition, tool restrictions, model overrides, five levels of nesting), and the API level (Claude Managed Agents: up to 20 agent types, 25 concurrent threads, shared sandbox/filesystem/vault)⁸¹¹.

The core of the design is context isolation. A subagent’s intermediate tool calls and reasoning stay within its own context, and only the final message is returned. This solves “context accumulation” (the biggest practical problem of multi-agent systems) at the architectural level. Peer-to-peer communication is currently unsupported, with a feature request filed¹².

OpenAI Agents SDK

Its design policy is “sufficient capability from a small number of primitives.” It consists of four concepts: Agent, Handoff, Guardrail, and Tracing².

Making handoff a first-class primitive is the most distinctive feature of the design. When Agent A hands off to Agent B, the entire conversation history is transferred, and B can reference the context as if it had been part of the conversation from the start. This is a design choice fundamentally different from Anthropic’s context isolation.

Its predecessor Swarm was an experimental/educational framework, a stateless design consisting of only two concepts: routines (instructions + tools) and handoffs. Production use is not recommended⁵.

LangGraph

Its design policy is a graph-based state machine. Control flow is explicitly defined as nodes and edges, and routing logic is written in Python code³.

StateGraph is the core, providing nodes (Python functions that receive state and return updates), edges (fixed or conditional transitions), Command (a composite of state update plus routing directive), subgraphs (hierarchical composition), and human-in-the-loop via interrupt()/Command(resume=...).

Its production-oriented features (checkpointing/persistence, streaming, audit trails, rollback, LangSmith integration) are the most mature. Benchmarks rate it as having the lowest latency among the major frameworks, and its token consumption from “management overhead” is roughly one third of CrewAI’s¹³.

CrewAI

Its design policy is role-based agent collaboration. It consists of Agent (role + goal + backstory + tools), Task (description + expected_output + assigned agent), and Crew (a container of Agents and Tasks, with a specified process type)¹⁴.

Its prototyping speed is the fastest. The role-based design is intuitive, and the distance from idea to prototype is short.

Production deployment faces challenges. Checkpointing is not built in. The granularity of inter-agent communication is coarse. The hierarchical process can produce circular delegation and drift. Roughly 3x the token consumption of LangGraph has been reported¹³.

In the practitioner community, a migration path of “prototype in CrewAI, productionize in LangGraph” is becoming established.

Microsoft Agent Framework 1.0

A unified framework integrating AutoGen and Semantic Kernel, which reached GA in April 2026. It aims at enterprise multi-agent orchestration and runs cross-runtime on .NET and Python⁷.

It officially provides five orchestration patterns (Sequential, Concurrent, GroupChat, Handoff, Magentic). The original AutoGen has moved to maintenance mode (bug fixes only), and the community fork AG2 continues development independently⁶.

Google ADK

Its design policy is code-first, using the same framework as Google’s internal products (Agentspace, CES). It recommends AgentTool (wrapping an agent as another agent’s tool) over sub_agents delegation, emphasizing a design in which the root agent retains control⁴.

Native support for Google’s A2A (Agent-to-Agent) protocol is unique to it, aiming at agent interoperability across frameworks and languages. It provides three workflow agents: SequentialAgent, ParallelAgent, and LoopAgent.

AWS Strands Agents SDK

It adopts a model-driven approach, with a design philosophy close to the Claude Agent SDK. The framework does not prescribe the workflow, entrusting it to the model’s planning, reasoning, and tool-calling capabilities. It reached v1.0 GA in 2026 with over 14 million downloads¹⁵.

Mastra

A TypeScript-native agent framework: Y Combinator W25, raised $35 million in April 2026, over 300,000 weekly downloads. It provides a graph-based workflow engine (.then(), .branch(), .parallel()), durable agents (surviving client disconnection), and an event system (Redis Streams / Google Cloud Pub/Sub)¹⁶.

Communication Protocols: MCP and A2A

As communication standards between agents, MCP and A2A are coming to play complementary roles.

MCP (Model Context Protocol) standardizes access from agents to tools/resources. Stateless request-response is the basis, used for connecting to DBs, APIs, and filesystems.

A2A (Agent-to-Agent Protocol, proposed by Google) standardizes task delegation and multi-step coordination between agents. It is a stateful design with task state, memory, and context.

The standard architecture is converging on a configuration that uses A2A for communication between agents and MCP when each agent internally accesses tools.

Converging Best Practices

The following seven points are broadly agreed upon by Anthropic, OpenAI, and the practitioner community.

Prove the limits of a single agent before going multi. This is the strongest point of consensus. A single agent plus good tools can solve the majority of problems. Introduce multi-agent systems only when the limits of a single agent have been proven¹.

Prefer workflows (fixed flows) over agents (dynamic flows). Anthropic’s explicit hierarchy: prompt engineering -> workflows (pipeline/router/fan-out) -> autonomous agents. Autonomous agents are the last resort for cases where the task decomposition itself is unpredictable¹.

Minimize each agent’s context. Pass only the necessary information. Irrelevant information scatters the model’s attention and increases cost. Even with large context windows, this principle does not change.

Tool design determines agent capability. Clear descriptions, informative error messages, easy-to-use APIs. This applies equally to single agents and multi-agent systems¹.

Build in observability from the start. Tracing, logging, and recording each agent’s inputs and outputs are essential. Debugging a multi-agent system without observability is practically impossible. OpenAI Tracing, LangSmith, and Claude Code JSONL transcripts are in practical use.

Define clear termination conditions. For every agent loop and multi-agent interaction, set one of: a maximum turn count, a maximum token count, convergence detection, or human approval. Unbounded loops are the most common failure mode.

Place gate checks between steps. In pipelines and orchestrator-worker setups, validate intermediate outputs before passing them to the next step. This catches failures early and prevents bad outputs from propagating through the entire system.

Known Anti-Patterns

Too many agents. Agent count does not correlate linearly with quality. Each addition multiplies cost, latency, and debugging complexity. Every agent added requires concrete justification.

Premature multi-agent adoption. Reaching for multi-agent before exhausting a single agent’s capability. The improvement often does not justify the complexity cost.

Overfitting to the framework. Distorting the task to fit the framework’s abstractions. Anthropic’s explicit warning: “frameworks conceal the underlying API calls, make debugging difficult, and can prevent full exploitation of model capabilities”¹.

Context bloat. Passing all information to all agents. More context does not mean better performance. It invites attention diffusion, cost growth, and quality degradation.

Implicit state sharing. Communication through global variables or implicit filesystem conventions. It invites race conditions and debugging difficulties. Sharing should be done through explicit mechanisms (shared state, message passing).

Overconfidence in autonomy. Delegating excessive judgment to agents without human checkpoints. The danger is high for high-risk operations (file deletion, external API calls, deployment).

Framework Comparison

	Claude Code/SDK	OpenAI Agents SDK	LangGraph	CrewAI	MS Agent Framework
Communication	Context isolation + summary	Handoff (full history)	Shared state	Task delegation	Choice of 5 patterns
Control flow	Model-driven	Model-driven	Explicit graph	Role-driven	Hybrid
Token efficiency	High (cache sharing)	Medium	Highest	Low (approx. 3x)	Medium
Production readiness	High	High	Highest	Medium	High
Learning cost	Low	Low	Medium to high	Low	Medium
Language	TypeScript/Python	Python	Python/JS	Python	.NET/Python

Decision Flow for Pattern Selection

1. Can the task be decomposed into fixed steps -> pipeline. If some steps can be parallelized independently, add fan-out/fan-in.
2. Does processing differ fundamentally by input type -> router -> type-specific specialist pipelines/agents.
3. Are subtasks determined dynamically depending on the input -> orchestrator-worker. If iterative quality improvement is needed, add an evaluator-optimizer loop.
4. Is multi-perspective analysis needed -> debate/adversarial.
5. None of the above applies -> a single agent plus tools suffices (no multi-agent needed).

The majority of tasks can be handled by combinations of 1 and 2. Before proceeding to 3 and beyond, confirm the limits of 1 and 2.

Sources

Footnotes

1. Anthropic. “Building effective agents.” 2024-12. https://www.anthropic.com/research/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. OpenAI Agents SDK. https://openai.github.io/openai-agents-python/ ↩ ↩² ↩³

3. LangGraph documentation. https://langchain-ai.github.io/langgraph/ ↩ ↩² ↩³

4. Google ADK. https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/ ↩ ↩²

5. OpenAI Swarm (experimental). https://github.com/openai/swarm ↩ ↩²

6. AutoGen / AG2 documentation. https://microsoft.github.io/autogen/ / https://docs.ag2.ai/ ↩ ↩²

7. Microsoft Agent Framework 1.0. https://learn.microsoft.com/en-us/agent-framework/ ↩ ↩²

8. Claude Agent SDK: Subagents. https://code.claude.com/docs/en/agent-sdk/subagents ↩ ↩² ↩³

9. Anthropic. “How we built our multi-agent research system.” https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩²

10. Claude Code architecture analysis. arXiv 2604.14228. https://arxiv.org/html/2604.14228v1 ↩

11. Claude Managed Agents: Multi-Agent Sessions. https://platform.claude.com/docs/en/managed-agents/multi-agent ↩

12. GitHub: Agent-to-Agent Communication feature request. https://github.com/anthropics/claude-code/issues/4993 ↩

13. Multi-Agent Orchestration: Supervisor vs Swarm (DEV Community). https://dev.to/focused_dot_io/multi-agent-orchestration-in-langgraph-supervisor-vs-swarm-tradeoffs-and-architecture-1b7e ↩ ↩²

14. CrewAI documentation. https://docs.crewai.com/ ↩

15. Strands Agents SDK 1.0. https://aws.amazon.com/blogs/opensource/introducing-strands-agents-1-0-production-ready-multi-agent-orchestration-made-simple/ ↩

16. Mastra. https://mastra.ai/ ↩