Agent Orchestration Explained

Before 2026, every agent framework invented its own way of calling tools and its own way of letting agents talk to each other. The ecosystem has since consolidated around two complementary, vendor-neutral protocols:

The two protocols sit under separate but related Linux Foundation efforts — a detail many secondary sources get wrong. MCP is hosted by the Agentic AI Foundation (AAIF), a directed fund launched in December 2025 and co-founded by Anthropic, Block, and OpenAI, alongside Block'sgoose agent framework and OpenAI's AGENTS.md standard. A2A, by contrast, is its own Linux Foundation–hosted project — Google contributed it in mid-2025, and by its one-year mark it had grown to over 150 supporting organizations, up from roughly 50 at launch. Different governing bodies, same underlying goal: keep the plumbing vendor-neutral. A third protocol, ACP (Agent Communication Protocol), was consolidated into A2A rather than continuing as a competitor — a useful reminder that this stack is still settling, and a course claiming three separate competing standards today is already out of date.

MCP's largest specification revision since launch removed the protocol-level connection handshake and session tracking entirely. Practically, this means:

• Stateless by default: MCP servers can now sit behind a plain round-robin load balancer — no sticky sessions, no shared session storage to operate.
• MCP Apps: servers can ship interactive UI (rendered in a sandboxed iframe) alongside a tool, so a host application can prefetch and security-review the interface before anything runs.
• Tasks as an extension: long-running tool calls return a task handle; the client polls or cancels it, rather than the server holding open state.
• A formal deprecation policy: features move through Active → Deprecated → Removed with a minimum 12-month window, so integrations get real notice before something breaks.

Older MCP features — Roots, Sampling, and Logging — are being deprecated in favor of tool parameters, direct provider APIs, and standard telemetry streams, respectively. If you're maintaining an existing MCP server, check the protocol's official changelog before your next upgrade; exact version dates are exactly the kind of detail that goes stale fastest.

Full autonomy is no longer the goal for production multi-agent systems. The framework and observability layer are genuinely independent choices — pick any orchestration framework and pair it with a tracing and evaluation layer that understands multi-step agent spans, not just single API calls. A few principles hold regardless of which framework or protocol you use:

• Progressive autonomy: start every new agent workflow supervised, and expand its freedom only after you've measured its accuracy.
• Meaningful human oversight: strategic control points — approval before irreversible actions — not constant micromanagement of every step.
• Dynamic, escalating guardrails: low-stakes decisions can proceed automatically; high-stakes ones (refunds, account changes, external emails) route to a human.
• Auditability by default: log every tool call, every hand-off, and every agent-to-agent message — not just the final output.
• Deploy in monitoring mode first: ship the guardrail policy in observe-only mode, tune it against real traffic, then switch on enforcement.

Cost and latency deserve the same instrumentation as correctness: track cost per request and per agent hop in real time, so a silently looping agent shows up as a budget alert, not a surprise invoice.

A customer-support system is a good example because it needs real coordination, not orchestration for its own sake:

1. Router agent classifies the incoming request (billing, technical, account) — a supervisor at the top of the topology.
2. Specialist agents handle each category, each with its own MCP-connected tools: the billing agent reaches a payments API, the technical agent reaches a knowledge base and ticketing system.
3. Escalation path — any action that’s irreversible (a refund, an account change) pauses for human approval before executing, regardless of how confident the agent is.
4. Cross-framework hand-off (optional) — if the technical specialist is a separately-maintained agent on a different framework or vendor, A2A is what lets the router hand off the task without both sides needing the same internal code.

Notice what this topology does not do: it doesn't use five agents where two would work, and it doesn't give every agent every tool. Scope each agent's tool access to exactly what its role needs.

I'm designing a multi-agent system for [USE CASE].

Current single-agent approach (if any): [DESCRIPTION]
Why it's not enough: [SPECIFIC LIMITATION — e.g. needs distinct tool permissions, needs parallelism, context window too large]

Please help me:
1. Propose the smallest number of agents that solves this (don't over-split roles)
2. Recommend a coordination topology (supervisor/worker, hierarchical, peer-to-peer) and justify it
3. List which tools/data each agent needs — scoped to least-privilege
4. Flag every point where a human approval gate should exist before an irreversible action
5. Estimate the cost/latency multiplier vs. a single-agent baseline
6. Suggest what to log at each agent hand-off for debugging