Interoperability is not organization.

A shared language solves only one layer

When two AI agents can discover one another, exchange a task and return a structured artifact, an important engineering problem has been solved. The work can cross systems without requiring every participant to expose its internal memory, tools or implementation. But communication is not the same thing as organization.

A team of interoperable agents can still duplicate work, drop a constraint, argue past one another or act without a clear owner. The protocol may show that a message arrived. It does not decide which participant is responsible for the decision, which role may approve a consequential action or what should happen when the agents disagree. Those are organizational and governance choices layered on top of transport.

Capability discovery is not a governance charter

The current Agent2Agent protocol describes a common language for agent discovery, task-oriented collaboration, streaming or asynchronous updates, and exchange of text, files and structured data. Its Agent Cards advertise capabilities and connection information. Those mechanics can make collaboration possible across otherwise opaque systems. They should not be mistaken for proof that the resulting collaboration is accountable.

NIST's AI Risk Management Framework separates responsibilities across design, development, deployment, operation and monitoring, evaluation, domain expertise, and governance and oversight. The same system may therefore involve several actors whose duties are intentionally different. A capability declaration can help route work to an agent. It cannot, by itself, assign organizational responsibility or grant authority. This distinction is my design synthesis from the protocol and risk-management sources; neither source certifies a particular multi-agent operating model.

Give the organization an explicit contract

Before connecting agents, define the unit of work and the decision rights around it. Which role frames the task? Which participant owns each evidence source? Who may revise a requirement, approve an exception, reject an artifact or stop the workflow? When a specialist returns a result, what makes that result accepted rather than merely received?

A useful organizational contract can remain compact: named roles, bounded authority, required evidence, acceptance criteria, escalation paths, stop conditions and a recovery owner. It should also state the resource budget and the data each participant may access. That record lets a reviewer distinguish a coordination failure from a model failure. It also prevents a polished transcript from becoming the only evidence that the group worked as intended.

Test the organization, not the number of agents

I would compare three conditions under the same models, tools, evidence, total inference allowance and reviewer time. The first would use one agent to coordinate the work. The second would use interoperable specialist agents with task state and artifact exchange. The third would add the explicit organizational contract: roles, authority, evidence ownership, acceptance, escalation and recovery.

Measure legitimate task completion, dropped constraints, duplicated work, conflicting actions, unsupported escalation, unauthorized attempts, correction uptake, recovery time, reviewer burden, latency and cost. Include cases with an unavailable specialist, stale evidence, ambiguous ownership and a late change in requirements. Independently observe task effects instead of relying only on agent-generated summaries.

This is a proposed study, not a report of measured results. Its purpose is to isolate the value of organization from the value of a common protocol or additional computation. Interoperability can connect capable systems. Organization determines whether their combined work remains responsible, correctable and useful.