Two AI agents can be worse than one.
For most of the agent era the hard part was connection. Getting one AI agent to reach your tools, your data and your systems took custom glue code, and getting agents from different vendors to work together was close to impossible. That barrier has now fallen, and it fell fast. In the space of a few months the industry settled the two protocols that wire agents into everything else, which means building a system where several agents talk to each other is no longer an engineering feat. It is a configuration choice.
That is precisely why the useful question has changed. It is no longer whether you can wire agents together. It is whether you should, and how you govern the result when you do.
The plumbing just got standardised
Two open standards now define how agents connect, and both sit under the Linux Foundation.
The first is the Model Context Protocol, or MCP, which Anthropic donated to the Linux Foundation's new Agentic AI Foundation. The foundation was announced on 9 December 2025, co-founded by Anthropic, Block and OpenAI, with supporting members including Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP is how a single agent reaches out to tools and data. It is the standard that lets one agent read a document store, query a database or call an internal service without bespoke integration.
The second is the Agent2Agent protocol, or A2A, which the Linux Foundation reports has surpassed 150 organisations and reached its first stable specification, version 1.0, with signed agent cards for cryptographic identity verification. A2A does a different job. In the Linux Foundation's own words, it is "an open standard that enables AI agents to discover, communicate, and transact with each other across different frameworks, vendors, and platforms". The press release draws the line cleanly: "A2A defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources."
Read those two together and the picture is complete. MCP is agent-to-tools. A2A is agent-to-agent. With both settled and hosted by a neutral foundation, the connective tissue of multi-agent systems is now off-the-shelf. You can stand up a coordinator agent that hands sub-tasks to specialist agents from three different vendors, and they can find each other, verify identity and pass work between them, without you writing the protocol.
The connectivity problem is largely solved. The design problem is not.
More agents is not more intelligence
The instinct, once coordination is easy, is to reach for more agents. If one agent is useful, surely a team of them is better. The evidence says be careful.
Anthropic published a detailed account of how it built its own multi-agent research system, and the numbers are sobering for anyone planning to spin up agent swarms by default. In its data, "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats". That is not a rounding error. It is an order-of-magnitude jump in cost for the same wall-clock task. Anthropic is blunt about the implication: "For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance."
Cost is only half of it. The other half is that agents coordinating is hard, and it gets harder quickly. Anthropic describes "a rapid growth in coordination complexity" and lists the failure modes its own engineers hit. Sub-agents "misinterpreted the task or performed the exact same searches as other agents". In one case, "one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains, without an effective division of labor". Agents kept "continuing when they already had sufficient results". Early versions "consistently chose SEO-optimized content farms over authoritative but less highly-ranked sources".
None of that is a reason to avoid multi-agent systems. Anthropic ships one. It is a reason to treat them as a considered architecture rather than a default. Multiple agents earn their keep when a task genuinely splits into independent parts that can run in parallel, and when the value of finishing faster or more thoroughly clears the cost of running many models at once. Deep research across dozens of sources is a good fit. Drafting a single document is not. For most work, one capable agent with good tools is cheaper, more predictable and far easier to govern than a committee of them tripping over each other.
The headline to carry into any agent project is simple. Adding agents adds tokens, latency and coordination risk. It does not automatically add intelligence.
When multiple agents genuinely earn their keep
None of this is an argument against multi-agent systems. It is an argument for a test before you build one. Two conditions have to hold. The task has to genuinely parallelise, meaning it splits into parts that can run independently without each waiting on the others, so several agents working at once actually finish sooner rather than just talking more. And the value of the result has to clear the cost, because you are paying roughly an order of magnitude more in tokens for it. Deep research across dozens of independent sources fits, because each strand can run alone and the answer is worth the spend. A single report, a customer reply or a routine analysis does not, because the parts depend on each other and one capable agent does the job cheaper and cleaner. The honest test is one sentence. Can I name the independent parts, and is this worth roughly ten times the cost? If you cannot answer both with a straight face, you do not have a multi-agent task. You have a single-agent task with extra steps.
The new control point is the boundary between agents
For anyone doing regulated or sensitive work, the shift from one agent to many is not just an efficiency question. It changes what you have to govern.
A single agent is one actor with one set of permissions. You govern the model, the data it sees and the tools it can call. A multi-agent system is several actors passing work and information between them, and each one is a point of access. When agent A asks agent B to do something, agent B acts with its own permissions on its own data, and the instruction came from software, not a person. The A2A protocol's signed agent cards exist precisely because identity between agents is now a real security property. Who is this agent, who runs it, and what is it allowed to do, are questions you now have to answer at machine speed.
This is where the standards help and where they stop. A2A settles how agents talk. It does not decide what they are allowed to say, what they may reach, or how you prove after the fact who instructed what. That is your control framework, and for Australian regulated entities it is not a new legal regime. It is the obligations you already carry, applied to a new surface. CPS 234 asks you to secure information assets, and each agent is now an information-handling actor. CPS 230, in force since 1 July 2025, asks you to understand and control the services your critical operations depend on, and an agent your process relies on is such a service. The Privacy Act's use-and-disclosure rules apply to whatever each agent can see and pass on. The technology is new. The duties are not.
There is a practical consequence for how you buy. When a vendor sells you a multi-agent product, ask which agents it contains, who runs each one, what each can reach, and how the hand-offs between them are logged. If the answer is a single opaque box that "coordinates agents for you", you have bought a system of actors you cannot see, and you cannot govern what you cannot name. Insist on the org chart of the agents before you sign.
How to govern a system of agents
If you are building or buying anything that puts more than one agent to work, five moves keep the coordination governable.
- Justify the topology. Before you add a second agent, answer one question in writing: does this task genuinely split into independent parts, and is it valuable enough to pay roughly an order of magnitude more in tokens? If the honest answer is no, use one agent. The default is one, and multi-agent is the exception you argue for.
- Give every agent an identity and least-privilege access. Each agent is a named actor with its own credentials, scoped to only the tools and data it needs. A specialist that summarises documents does not need the permission to send an email or move money. A2A's signed agent cards make identity verifiable, so use them.
- Define the division of labour explicitly. The duplicate-work failures Anthropic documented come from agents that were never told clearly who does what. Write down each agent's job, its boundaries and how results are combined, so two agents do not chase the same question and no question falls between them.
- Log every agent-to-agent message. When something goes wrong in a multi-agent system, "the agents decided" is not an answer. Record which agent instructed which, on what data, against what task. The log is what turns an opaque swarm into an auditable process.
- Bound the blast radius and keep human checkpoints. Cap what any agent can do without a person, and put a human gate on consequential actions. The more autonomous the system, the smaller each agent's individual authority should be, so a single confused agent cannot cascade an error across the others.
The hype check
The protocols settling is real progress, and it is being oversold. A2A reaching 150 organisations and a stable version means agents from different vendors can now interoperate, which is genuinely useful. It does not mean multi-agent coordination is a solved problem. There is still no agreed answer for how agents should divide work, resolve disagreement or recover from a sub-agent going wrong, and competing frameworks are still fighting over the orchestration layer above the protocols. Settling how agents connect is not the same as settling how they should cooperate. The first is plumbing. The second is engineering judgement, and it is still being worked out in production.
What to do this week
- Audit your agent count. For any AI system you run or are piloting, ask how many agents it uses and why. If a task uses several agents and you cannot state the parallel benefit, flag it for simplification.
- Name the actors. For any multi-agent system, list each agent, its owner, its permissions and its job. If that list does not exist, that absence is the finding.
- Reach for one agent first. Make single-agent the default in your team's design guidance, and require a short written justification before anyone adds a second. Cheaper, simpler and easier to govern is the right starting assumption.
The industry spent two years making it easy for agents to work together. The next two will be about learning when they should, and proving you kept control when they did.
TheAICommand. Intelligence, At Your Command.
