The hard part of agents talking to agents is not the message format; it is identity, authority and what happens when something goes wrong. Wire protocols are the easy layer and several credible ones exist. The unsolved questions are institutional, and no specification resolves them.
The question usually asked is which agent-to-agent protocol will win. The better question is narrower: when an agent acting for one organisation asks an agent acting for another to do something, who is accountable if it was not authorised?
That question has no technical answer, and until it has an institutional one, cross-organisational agent interaction stays limited to low-stakes work.
At a glance
- Within one organisation this is an architecture problem, already solvable
- Across organisations it becomes a trust and liability problem
- Identity must cover the agent, the principal it acts for, and the delegation between them
- Authority needs to be verifiable by the receiving party, not asserted
- Dispute resolution has no standard and is the real blocker
- Build against today’s reality: bounded authority and human-backed commitments
What actually needs standardising?
| Layer | Maturity | Why |
|---|---|---|
| Message transport | Solved | Ordinary networked application concerns |
| Capability discovery | Emerging, credible | Existing tool protocols already do this within a trust boundary |
| Agent identity | Partial | Machine identity exists; agent-specific semantics do not |
| Delegated authority | Weak | Proving an agent may act for a principal, to a third party |
| Commitment semantics | Weak | What it means for an agent to agree to something |
| Dispute and reversal | Absent | No standard for unwinding an unauthorised interaction |
Read down the maturity column and the pattern is clear. Everything mechanical is close to solved. Everything about accountability is not, and the gap widens as you move toward consequences.
Why is delegated authority the hard problem?
Figure 1 — The same request, two trust contexts
Inside one organisation
Both agents run under the same identity system. Permissions are checked against one directory, logs live in one place, and a dispute is an internal incident.
This is a solved architecture problem. Use existing service identity and per-invocation authorisation.
Tractable today
Across organisations
The receiving agent must decide whether an unfamiliar agent genuinely speaks for a party it has a relationship with, and to what limit.
An assertion is not evidence. Verifying it requires infrastructure neither side controls, and a wrong decision has consequences no log resolves.
Unsolved
The boundary is organisational, not technical. The same message over the same protocol is routine in one context and unacceptable in the other, and no amount of specification changes which context you are in.
What a workable scheme needs to convey: which agent is speaking, which principal it acts for, what specific authority was delegated, when that delegation expires, and how the receiver can verify all of it without trusting the sender’s word.
Public key infrastructure and verifiable credentials give plausible mechanisms for parts of this. What they do not supply is agreement on what the assertions mean or who is liable when one turns out to be wrong.
What does commitment mean for an agent?
This is where the analogy to human negotiation breaks down, and it is worth being precise about.
When a person agrees to a price, a body of contract law determines what happened. When an agent does, the question is whether it had authority, whether the counterparty could reasonably rely on that, and whether the principal is bound.
Existing legal frameworks around electronic agents and automated contracting cover some of this, and they were written for deterministic systems that execute rules. An agent that reasons and can be persuaded is a different object, and the fit is imperfect.
Watch for this
An agent exposed to another party’s agent is exposed to adversarial input from a system that reasons. Prompt injection across an agent boundary is not hypothetical: the other side’s messages enter your model’s context. Treat every cross-boundary message as untrusted input, never let it modify your agent’s authority, and enforce limits in code rather than in instructions.
What can you build today?
Considerably more than the unsolved layer suggests, provided you scope the authority.
- Bounded authority. Agents may transact only within pre-agreed limits established by humans in advance — value caps, permitted actions, named counterparties.
- Existing contracts underneath. The agent interaction operates inside a commercial relationship that already exists, so the accountability question is answered before any agent speaks.
- Human-backed commitments. Agents negotiate and prepare; a human confirms anything binding. Slow, and it makes liability unambiguous.
- Full logging on both sides. Each party records the exchange completely, since reconstruction is the only dispute mechanism that currently exists.
- Reversibility by design. Prefer interactions that can be unwound, because the reversal standard does not exist and you will need to do it manually.
The pattern across all five: constrain the blast radius rather than solving the trust problem. That is achievable now and does not depend on any standard being adopted.
What is genuinely uncertain?
Several things, and being honest about them is more useful than predicting a winner.
- Whether one protocol consolidates or interoperability happens through adapters, as it has in most previous integration waves.
- Where liability lands when an agent commits its principal to something unintended, which will likely be settled by litigation rather than specification.
- Whether machine-to-machine negotiation is desirable at all for consequential transactions, or whether it stays confined to routine ones.
- How adversarial robustness is achieved when both parties run systems that can be manipulated through their inputs.
Anyone claiming confident answers to these is forecasting rather than reporting. The technical layer is moving quickly; the institutional layer moves at the speed of contract law and insurance.
Where do teams go wrong?
Solving the format and calling it done
A working message exchange between two agents demos well and answers none of the questions that block deployment. The demo is the easy 20%.
Treating the counterparty agent as trustworthy
Even a legitimate counterparty runs a system that can be manipulated. Messages arriving from it must be treated as untrusted input regardless of the relationship between the organisations.
Granting standing authority
An agent with open-ended permission to transact is a liability with no upper bound. Scope authority per interaction, with explicit limits and expiry, even where the counterparty is well known.
What do experienced teams do differently?
They keep the agent on their own side of the boundary.
Rather than agents negotiating directly, each side’s agent prepares a position and a conventional integration carries the actual exchange. The flexible component stays inside the trust boundary and the crossing itself remains deterministic and auditable.
They also write down the authority model before building anything. Which actions an agent may take, up to what value, on whose behalf and with what expiry is a document that should exist before code does, because retrofitting it means discovering the limits during an incident.
A short glossary
- Principal
- The person or organisation on whose behalf an agent acts and who bears the consequences.
- Delegated authority
- The specific, bounded permission granted to an agent, ideally verifiable by a third party.
- Verifiable credential
- A cryptographically checkable assertion a receiver can validate without trusting the sender.
- Commitment
- An agreement an agent makes that purports to bind its principal.
- Blast radius
- The maximum harm an interaction can cause, constrained by scoping authority narrowly.
Where to go deeper
Three directions, and the first is not where engineers usually look.
Start with the law of agency and electronic contracting, because it defines what a commitment is and who is bound, and no protocol overrides it. Then look at verifiable credentials and decentralised identity, which supply the mechanisms for proving delegated authority to a party that does not know you. Finally, read the adversarial input literature, since cross-boundary agent messages are untrusted input entering a system that reasons.
The connecting thread: the interesting problems here sit at the seam between engineering and institutions, and treating it as purely a protocol question is what leads teams to build something correct that nobody can safely deploy.
Key takeaways
- Message format is the easy layer; identity, authority and dispute resolution are not.
- Within one organisation this is a solvable architecture problem using existing service identity.
- Across organisations it becomes a trust and liability problem no specification resolves.
- Authority must be verifiable by the receiver, not asserted by the sender.
- Cross-boundary messages are untrusted input entering a system that reasons.
- Build with bounded authority, existing contracts underneath and human-backed commitments.
- Keep the flexible component inside your trust boundary and make the crossing deterministic.
Frequently asked questions
What is an agent-to-agent protocol?
A standard for autonomous systems representing different parties to discover each other, exchange messages and coordinate work. The transport and discovery layers are straightforward; the difficulty lies in identity, delegated authority and accountability when an interaction goes wrong.
Why is cross-organisational harder than internal?
Internally both agents share one identity system, one permission directory and one incident process, so a dispute is an internal matter. Across organisations the receiver must verify an unfamiliar agent’s authority using infrastructure neither side controls, and errors have external consequences.
Can an agent enter into a binding agreement?
It depends on jurisdiction and on whether it had authority. Existing frameworks for electronic agents and automated contracting cover some cases, but they were written for deterministic rule-following systems. An agent that reasons and can be persuaded fits imperfectly, and much of this will be settled by litigation.
What is the security risk in agent-to-agent interaction?
Messages from the counterparty enter your model’s context, making prompt injection across the boundary a real attack path. Treat every incoming message as untrusted, never let it alter your agent’s authority, and enforce limits in code rather than in instructions.
What can I safely build today?
Interactions with bounded authority inside relationships that already exist. Set value caps, permitted actions and named counterparties in advance, have humans confirm anything binding, log completely on both sides, and prefer interactions that can be reversed manually.
Will one protocol become dominant?
Genuinely unclear. Previous integration waves consolidated in some cases and interoperated through adapters in others. Anyone stating this confidently is forecasting, and the technical layer is moving far faster than the institutional layer that determines what is deployable.
How should authority be scoped?
Per interaction, with explicit limits and expiry, even for well-known counterparties. Standing open-ended permission to transact is a liability with no upper bound. Write the authority model down before building, since retrofitting it means discovering the limits during an incident.
Is direct agent negotiation the right architecture?
Often not yet. Having each side’s agent prepare a position while a conventional integration carries the actual exchange keeps the flexible component inside the trust boundary and leaves the crossing deterministic and auditable, which is what current accountability gaps require.
References
- Anthropic. Model Context Protocol documentation, covering capability discovery and host-mediated permission within a trust boundary.
- W3C. Verifiable Credentials Data Model, a mechanism for third-party-verifiable assertions.
- OWASP. OWASP Top 10 for Large Language Model Applications, covering prompt injection through untrusted input.
- NIST. AI Risk Management Framework.
