Clarion Street

Orchestration Is a Spectrum, Not Four Silos: Choosing Your Agent Architecture in 2026

·7 min read

In September I wrote that the agent-framework market had consolidated into three clean silos: Graph, Crew, and Handoff. Pick the one that matches your workload and move on. The piece was useful and also wrong in a specific way, because those silos leak into each other as soon as you look closely.

The missing fourth pattern is the reason. Google’s ADK organizes multi-agent systems as a parent and its sub-agents, with two documented shapes. There is Coordinator and dispatcher, one LLM routing to specialists, and there is Hierarchical task decomposition, a multi-level tree that breaks a complex goal into sub-tasks. That is a real, distinct pattern, and the September piece left it out. But the more interesting problem appears when you add it back. Hierarchical is something CrewAI already ships.

CrewAI’s core abstraction is the crew, a group of agents where each carries a role, a goal, and a backstory. The crew runs either a sequential or a hierarchical process, and the hierarchical mode takes a manager_llm or manager_agent to supervise the rest. So the pattern I would have filed under “unique to Google ADK” is not unique to Google ADK. CrewAI has had a manager agent for a while.

The leak runs the other direction too. Google ADK 2.0 ships graph-based, dynamic, collaborative, and template workflows in a single kit, so graph and hierarchical live inside the same framework. The mapping everyone reaches for, graph means LangGraph and hierarchical means ADK, is one the framework vendors undercut in their own documentation.

None of this is a mark against the frameworks. It means the four-silo taxonomy is a starting heuristic, not a truth table. The patterns are primitives, and the frameworks are converging on each other’s primitives. The decision is not which framework to adopt. It is which primitive the workload needs, and which framework expresses that primitive cleanest in the stack you already have.

The four primitives

Graph-based means LangGraph. You model the agent as an explicit state graph of nodes and edges, and checkpointers persist a thread’s state so a run can pause for human review, time travel, and resume after a fault. This is the deterministic end of the spectrum.

Role-based means CrewAI. You name the roles, describe the goal, and the crew runs. NomadX describes CrewAI as the fastest way to stand up a role-specialized team, and it also notes that the autonomous end of the spectrum is harder to evaluate because the execution path changes run to run.

Handoff-based means the OpenAI Agents SDK. An agent delegates to another agent, and the handoff is represented to the model as a tool. A triage agent routes to anorder-status specialist, a refund specialist, or an FAQ specialist.

Hierarchical means Google ADK, mostly. A parent agent supervises sub-agents, and the coordinator either dispatches to specialists or recursively decomposes a goal into sub-tasks, per the coordinator/dispatcher and hierarchical task decomposition patterns in ADK’s docs.

I have now written out the exact taxonomy I am arguing against. That is the point. The list reads clean, and it is mostly false at the edges.

The spectrum

Sort them by who picks the next step. At one end you code the flow. LangGraph’s checkpointers persist a thread’s state for human review, time travel, and fault tolerance, which makes the state inspectable in a way a free-running loop’s is not. Whether that inspection counts as an audit trail is a separate question; I covered the difference between a trace and an audit trail in Beyond the Prompt: The Audit Trail Is the New Security Boundary. The relevant trade-off here is simpler: deterministic control costs engineering time.

At the other end the model picks the next step. A crew is fast to stand up, but it gives you a result rather than a reproducible path. That is fine for a lot of work. It is a problem when someone asks you to prove why the agent did what it did.

Handoffs sit toward the middle, on my reading. The routing is explicit but the path is the model’s to choose, so a handoff tends to be more predictable than a free-running crew and less inspectable than a graph.

The guides I read mostly say start with one agent. Add multi-agent structure only when the work is genuinely parallel, needs distinct roles, or exceeds a single context window. Most workloads do not clear that bar. A fair amount of the multi-agent architecture people build exists because it demos well, not because the task required it.

The exit door

Underneath all four sit MCP and A2A. MCP standardizes how an agent reaches tools and data. A2A standardizes how independent agents discover and delegate to each other. They are complementary, one is the agent-to-tool layer and the other the agent-to-agent layer, and both now sit under neutral Linux Foundation governance. I have covered the A2A governance move and the MCP stateless rewrite elsewhere, so the only point here is that this neutrality changes the decision. MCP and A2A make your tools and your agent-to-agent boundaries portable, which lowers the cost of switching frameworks. What they do not make portable is the orchestration code. State and control-flow semantics are still framework-specific, so moving a graph from one framework to another is still rework.

There is a performance reason to take the choice seriously. The same model scores differently inside different orchestration scaffolds. The comparison literature reports a 7-point GAIA gap between two scaffolds running identical models, and up to about 30 points between a bare model and a well-engineered scaffold. Those numbers come from a secondary source, so treat them as direction rather than precision. The direction still matters. Orchestration is not neutral plumbing. It changes what the model does.

That is why the advice most comparison pieces land on is to pick the primitive first and the framework second, and to standardize on MCP for tools and A2A for agents. That does not make framework choice free. It makes the tool and agent boundaries portable. The orchestration logic itself still has to move by hand.

Caveats

The surveys this whole framing rests on are dev-agency and vendor-marketing content, not independent measurement. Star counts and adoption figures are attention metrics, not production installs. I have flagged that before and it holds here. The four-silo taxonomy leaks by the vendors’ own docs, which is not a flaw in my argument so much as the argument itself.

One thing the taxonomy does not fix is evaluation. On the autonomous end of the spectrum, where the model chooses its own path, you still have to decide what good looks like before the run, not after. That is a harder problem than framework selection, and no pattern solves it.

Bottom line

The consolidation is real, in the specific sense that three 2026 surveys converged on the same six frameworks, and four patterns describe most of what those frameworks do. What is not real is the clean mapping from pattern to framework. CrewAI does hierarchical, ADK does graphs, and the vendors are converging on each other’s primitives. Sort your workload on the line from deterministic to autonomous, pick the primitive that matches, and keep MCP and A2A in place so that switching frameworks costs less, even though the orchestration logic itself still has to be rebuilt.

Sources

  1. Six Agent Frameworks Now Control Where Most Builders Ship Production Agents — NewClawTimes
  2. Agentic AI Frameworks in 2026: The Production Comparison — Uvik
  3. Multi-Agent Orchestration: Patterns and Frameworks 2026 — NomadX
  4. Agentic Open-Source Tools, 2026 Edition — You.com
  5. LangGraph: Persistence — LangChain
  6. CrewAI: Crews — CrewAI
  7. OpenAI Agents SDK: Handoffs — OpenAI
  8. Model Context Protocol: Introduction — MCP
  9. A2A Protocol — Agent2Agent
  10. Google ADK: Workflows — Google ADK