A week after the Wednesday standup in Part 1, the same Lagos fintech's compliance officer walks into the AI team's Friday review with a question. Last night the risk-scoring agent talked to the payment-routing agent, and one transaction was blocked and later un-blocked without either engineer on the call being able to say when. Who signed off? Which agent held the authority to override? What credentials did the second agent use? The engineers can point to the traces. The traces show the calls. The traces do not show who was accountable.
Coordination is where the audit trail is either designed in or improvised later. The six terms in this part are the connective tissue that lets an agent reach anything outside itself — tools, other agents, other systems, other teams. They also carry the trust boundaries that the previous generation of software did not have to answer for, because the previous generation of software did not delegate a decision to a model at the end of the chain. The vocabulary is where the boundary either gets named or gets skipped.
Key takeaways
- MCP is the standard for agent-to-tool. A2A is the standard for agent-to-agent. Both are still in early consolidation; betting on both is the practical position for the next two quarters.
- Every coordination hop is a delegation of authority. The audit chain has to survive the hop, or the compliance officer has questions the engineers cannot answer.
- The orchestrator is the most engineered component in most production stacks — and the most common single point of failure. Design it as infrastructure, not as a feature.
- Multi-agent systems solve coordination problems single agents cannot. They also introduce coordination problems single agents did not have. The choice is not free.
- Sloppy handoffs are where multi-agent systems lose their coherence and where audit chains break. Treat the handoff protocol as a first-class design artefact, not an implementation detail.
The Standards
Three terms cover the standards that let agents talk to things. All three are moving fast enough that a piece written this quarter will need editing next quarter.
MCP (Model Context Protocol)
Anthropic's open standard for how agents connect to tools, systems, and data sources. It defines a common interface — the agent speaks MCP, the tool speaks MCP, whatever model sits in between does not need a bespoke integration.
- Reach for it when you have more than one tool integration and you want a standard interface rather than a model-specific wrapper per tool. Reach for it earlier if you know you will switch models.
- Trade-offs — MCP is winning market share fast, and the ecosystem of servers is uneven. Vendor-specific servers do not always behave identically to the spec. Treat lock-in around a specific MCP server implementation as a real cost, not a hypothetical one.
- Cost and effort — connecting to an existing MCP server is minutes. Writing a production-grade MCP server yourself is a two-week project including authentication, rate-limiting, error semantics, and the audit-log integration the compliance officer will ask about.
A2A (Agent-to-Agent)
Google-led protocol for how agents coordinate directly with other agents across trust boundaries — different teams, different vendors, different accountability chains.
- Reach for it when the work genuinely divides across multiple agent owners and you need a standard way for one agent to hand a task to another agent that neither of them wrote.
- Trade-offs — A2A adoption is earlier than MCP, and the specification is still moving. The identity and authorisation model in A2A is where most of the design work sits, because which agent has the right to ask another agent to do a thing is a question the pre-agent internet never had to answer at protocol level.
- Cost and effort — reach for A2A when the alternative is a bespoke agent-to-agent API you would otherwise have to build and maintain forever. Reserve capacity for a re-implementation as the spec stabilises.
Agent Protocols
The umbrella term for the standards that let agent ecosystems interoperate — MCP, A2A, ACP, and whatever the next quarter names.
- Reach for it as a category when you are deciding which standards to bet on. The question is not which protocol has the best specification; it is which one has the vendor commitment and the ecosystem to still exist in eighteen months.
- Trade-offs — pick the standard with the most stable vendor commitment and the largest ecosystem of production deployments, not the one with the best specification document. Standards adoption is a network-effect question, not a technical one.
- Cost and effort — the cost is switching. The effort is picking correctly the first time. Revisit every two quarters as the ecosystem consolidates further.
The Coordination
Three terms cover how more than one agent gets work done together. All three are where the ambition of the multi-agent design meets the reality of production operations.
Orchestrator
An agent or a piece of orchestration code that breaks a goal into work and delegates it across tools, humans, and other agents.
- Reach for it when the work is too large for a single agent's context window, when different steps require different capabilities, or when the trust boundaries between steps do not match. The orchestrator is where the principal-of-record chain either survives the delegation or breaks.
- Trade-offs — the orchestrator becomes a single point of failure and a single point of latency. Every sub-agent call adds a hop, and each hop is a place the audit chain can lose its thread. An orchestrator without observability is an orchestrator that will surprise the compliance officer.
- Cost and effort — orchestration is what turns a research-agent demo into a production system. Expect the orchestrator to be the most engineered component in the stack, and expect to rewrite the first version once you know which delegation patterns actually recur.
Multi-Agent System
Multiple agents working as one coordinated system, each with a defined scope and role. Not every agent does everything; different agents are experts in different work.
- Reach for it when the problem genuinely partitions along skill boundaries (researcher, writer, reviewer), trust boundaries (customer-facing, internal, admin), or accountability boundaries (this agent's decisions are audited by that agent).
- Trade-offs — multi-agent systems solve coordination problems single agents cannot. They also introduce coordination problems single agents did not have — inconsistent state, deadlocked handoffs, cost multipliers when every agent calls every other agent. If you cannot draw the boundary between agents in one sentence, you probably do not have one.
- Cost and effort — three-to-five times the engineering effort of a single-agent design for the first production release. The multiplier drops as your platform matures, but so does the appetite for adding new agents to an already-multi-agent system.
Handoffs
The clean transitions between agents, tools, and people. What data crosses. Who owns the next step. What state is preserved. Who holds the authority for the next decision.
- Reach for it as a first-class primitive on any multi-agent system. The handoff protocol is the design artefact that decides whether the audit chain survives coordination.
- Trade-offs — sloppy handoffs are where multi-agent systems lose their coherence and where compliance officers lose confidence. A handoff without a defined data contract is a handoff nobody can debug.
- Cost and effort — the handoff protocol is a design decision, not a coding decision. Get it right on paper before the second agent goes in. The pattern reuses the principal-of-record chain unchanged — each hand-off carries the identity of the actor, the authority delegated, and the trace_id that binds the entire chain.
If the compliance officer walked into the Friday review at your team next week with the same question about who signed off, which of the six terms above is the one whose implementation would let you answer them without checking the code first?
FAQs
Should we standardise on MCP now or wait for the ecosystem to settle?
Standardise now for the internal work you would otherwise build a bespoke integration for. The alternative — waiting for the ecosystem to consolidate — means writing and maintaining your own protocol in the meantime, which is the worst of the available options. Accept that some MCP servers you adopt today will need to be reworked as the spec matures; that cost is smaller than the cost of running a bespoke protocol.
When does a multi-agent architecture pay off, and when does it just add coordination cost?
It pays off when the work genuinely partitions along skill, trust, or accountability boundaries, and the single-agent version has hit a real ceiling — context window, tool sprawl, safety confusion, audit-chain complexity. It adds cost when the partition is aspirational, three agents doing what one could do with better context, coordinating through hand-offs the single agent would not have needed. If you cannot draw the boundary in one sentence, do not draw it in code.
How do we handle authorisation across an A2A hop when the two agents belong to different teams?
The two agents delegate authority up to a shared principal — usually the end user, sometimes a service identity representing the business. Neither agent grants itself authority the other side did not carry in. The A2A protocol has to carry the delegation chain, and the receiving agent has to verify it before acting. This is the same discipline as OAuth token delegation; treat A2A trust boundaries with the same rigour, and reference the principal-of-record chain as the design reference.
What is the single most common orchestrator mistake we see?
Building the orchestrator as a feature rather than as infrastructure. The orchestrator ends up owning routing, error handling, retries, cost caps, audit logging, and delegation — and the first version usually handles two of those well and the rest as afterthoughts. Design the orchestrator with the same rigour you would design a service mesh; the first version does not have to do everything, but it does have to know where each of those responsibilities will live.
Companion content
- Building the Agent — The Working Vocabulary, Part 1: Foundations — the seven foundation terms that sit under this part
- Governing the Agent — The Working Vocabulary, Part 3 — the seven govern-and-run terms that sit on top of this part
- IAM for AI Agents: Delegation and the Principal-of-Record Chain — the audit-chain discipline that underlies A2A trust boundaries and orchestrator delegation
- MCP in Production: What the Spec Doesn't Tell You — deeper on MCP for teams committing to it
How to engage
If your multi-agent design is at the whiteboard stage and you want a vendor-neutral read on protocol choices and delegation-chain discipline before the first two agents ship, talk to us at creativeminds.dev/contact. The diagnostic covers protocol selection, orchestrator architecture, and the audit-chain design that survives the compliance officer's Friday review.