A Buyer's Guide to Agent-to-agent protocols

Interoperability protocols solve the format problem: agents from different vendors can exchange structured messages, discover each other's capabilities, and pass tasks along. What they generally do not carry is authority. When agent A asks agent B to do something, B has a message and no verifiable statement of what A is permitted to request, on whose behalf, or with what constraints. B either trusts the caller entirely or has to establish the position out of band, and the first option is how a delegated request becomes an unbounded one.

The protocol carries the message. It rarely carries the permission behind it.

Agent-to-agent protocols means interoperation between agents, where the design questions are delegated authority, provenance, and accountability rather than message format.

Why Engineering Is Heading Toward Agent-to-Agent, Not Just AI-Assisted

Explore how connected agents reshape engineering beyond AI-assisted development.

Download Whitepaper

However, most evaluations compare schema expressiveness, discovery, and ecosystem support, which address interoperation and leave the trust model undefined.

If you are a CTO or Head of Engineering at an enterprise, the intent of this article is:

Define why authority does not travel with the message
Show what a trust boundary between agents requires
Lay out how accountability is preserved across a chain

To do that, let's start with the basics.

What Are Agent-to-Agent Protocols? The Basic Definition

At a high level, these protocols let agents communicate: describing capabilities, sending tasks, returning results. The format work is genuinely useful and solves a real coordination problem. What it does not address is that a request from another agent is an external input with an unknown mandate. The receiving agent needs to know who ultimately authorised the work, what that principal is entitled to, and what constraints apply, and none of that is inherent in a well-formed message. Without it, delegation either collapses into blanket trust or requires bilateral arrangements that defeat the point.

To compare:

A protocol without authority is a standard form for requesting work between departments with no signature block. Everyone can read the request. Nobody can tell who authorised it or whether they could.

Why Do Agent-to-Agent Protocols Matter?

Issues that they address or resolve:

Requests arriving without a verifiable mandate
Delegation chains losing the original principal
Accountability unassignable across agents

Resolved Issues by Protocol Design Done Well

Delegated authority conveyed and verifiable
Original principal preserved through the chain
Accountability traceable per hop

Core Components of Agent-to-Agent Interoperation

Delegated authority conveyed with the request
Provenance identifying the originating principal
Trust boundaries between agents defined
Message semantics beyond format
Accountability and audit across the chain

Modern Interoperation Practice

Token-based delegation carrying scope and principal
Provenance chain preserved through hops
Explicit trust configuration per counterparty
Capability declarations with constraints
Cross-agent tracing with correlation identifiers

These practices make delegation safe. Token-based delegation carrying scope and principal is what turns a message into an authorised request.

Other Core Issues They Will Solve

Blast radius bounded across agent boundaries
Chains auditable end to end
Counterparty trust decided rather than implicit

In Summary: Agent-to-agent protocols solve format, and the design work is conveying authority, provenance, and accountability across the boundary.

Importance of Agent-to-Agent Protocols in 2026

Multi-agent arrangements are moving beyond single-vendor systems. Four reasons explain why this matters now.

1. Agents are crossing organisational boundaries.

A request may originate outside your control entirely.

2. Format standardisation does not imply trust.

Being able to parse a message says nothing about honouring it.

3. Chains lose the principal.

By the third hop, the original requester is frequently unrecoverable.

4. Accountability becomes diffuse.

When several agents contributed, attributing an outcome is hard without design.

Traditional vs. Modern Interoperation Design

Format and discovery vs. authority and provenance
Implicit trust in callers vs. explicit trust configuration
Principal lost at each hop vs. preserved through the chain
Tracing per agent vs. correlated across agents

In summary: A modern design carries permission and provenance alongside the request.

Details About the Core Components of Agent-to-Agent Interoperation: What Are You Designing?

Let's go through each component.

1. Authority Layer

What the caller may request.

Authority decisions:

Delegation token carrying scope
Verification on receipt
Scope narrowing at each hop

2. Provenance Layer

Who started this.

Provenance decisions:

Originating principal recorded
Chain preserved through hops
Tampering resistance considered

3. Trust Layer

Which counterparties.

Trust decisions:

Counterparties explicitly configured
Default posture defined as deny
Capability constraints per counterparty

4. Semantics Layer

What the message means.

Semantics decisions:

Intent expressed beyond payload shape
Constraints and deadlines conveyed
Result semantics defined

5. Accountability Layer

Who answers for the outcome.

Accountability decisions:

Correlation identifiers across agents
Per-hop logging retained
Responsibility model documented

Benefits Gained from Protocol Design Done Well

Requests honoured within a verifiable mandate
Chains auditable to the original principal
Trust decided per counterparty rather than assumed

How It All Works Together

The design treats an inbound agent request as an external input requiring a mandate rather than as an internal call. Delegation tokens carry scope and the originating principal, are verified on receipt, and are narrowed rather than widened at each hop, so authority decreases along the chain instead of being re-established from nothing. Provenance preserves the original requester through the hops with tamper resistance considered, because accountability collapses without it. Counterparties are explicitly configured with a default posture of deny and capability constraints per party, rather than any well-formed caller being honoured. Message semantics convey intent, constraints, and deadlines beyond payload shape. And correlation identifiers plus per-hop logging make the chain auditable end to end.

Common Misconception

We adopted the protocol, so agent interoperation is handled.

The protocol gives you a shared message format, capability discovery, and a transport, all of which are necessary and none of which answer the security question. When a request arrives, your agent needs to know whether the caller is entitled to ask, on whose behalf, and within what bounds. A well-formed message asserts none of that. Teams that adopt a protocol and leave the trust model implicit end up either honouring any structurally valid request or building bilateral arrangements per counterparty, which is exactly the interoperation problem the protocol was meant to solve.

Key Takeaway: The protocol standardises the message. Whether to honour it is a trust question the format does not answer.

Real-World Interoperation Design in Action

Let's take a look at how it operates with a real-world example.

We worked with a team whose agents honoured any well-formed request, with these constraints:

Convey delegated authority with scope and principal
Preserve provenance through every hop
Configure counterparty trust explicitly

Step 1: Carry the Authority

Scope and principal.

Delegation tokens issued
Verified on receipt
Narrowed at each hop

Step 2: Preserve Provenance

Through the chain.

Originating principal recorded
Chain maintained per hop
Tampering resistance considered

Step 3: Configure Trust

Deny by default.

Counterparties configured explicitly
Default posture deny
Capability constraints applied

Step 4: Convey Semantics

Beyond format.

Intent expressed
Constraints and deadlines included
Result semantics defined

Step 5: Make It Auditable

End to end.

Correlation identifiers applied
Per-hop logging retained
Responsibility documented

Where It Works Well

Ecosystems supporting delegation tokens
Chains where scope can be narrowed per hop
Deployments able to configure counterparties explicitly

Where It Does Not Work Well

Protocol adoption treated as a trust model
Any well-formed request honoured
Chains where the principal is lost at the first hop

Key Takeaway: Carry authority, preserve provenance, configure trust, convey semantics, make it auditable.

Common Pitfalls

i) Treating the protocol as a trust model

Format standardisation makes messages parseable and says nothing about whether to honour them. Add delegated authority.

Well-formed request
No verifiable mandate
Honoured entirely

ii) Losing the principal

By the third hop nobody can say who originally asked, which makes accountability and permission checking impossible. Preserve provenance.

iii) Implicit counterparty trust

Honouring any agent that can reach you is an open door. Configure counterparties explicitly with deny as the default.

iv) Widening scope across hops

Authority should narrow along a chain, never expand. Enforce narrowing at each delegation.

Takeaway from these lessons: Interoperation is a trust problem wearing a format problem's clothes.

Interoperation Best Practices: What High-Performing Teams Do Differently

1. Convey delegated authority with scope and principal

Make every inbound request carry a verifiable mandate rather than relying on the caller's identity alone.

2. Preserve provenance through every hop

Keep the original principal recoverable so permission and accountability remain answerable.

3. Configure counterparty trust explicitly with deny by default

Decide which agents you honour rather than accepting anything well-formed.

4. Narrow scope at each delegation

Ensure authority decreases along the chain instead of being re-established.

5. Correlate tracing across agents

Make the whole chain auditable end to end rather than per participant.

Logiciel's value add is helping teams design agent interoperation where authority and provenance travel with the request, so delegation is bounded.

Takeaway for High-Performing Teams: Carry authority, preserve principal, deny by default, narrow per hop, correlate the trace.

Signals You Are Doing This Well

How do you know it is working? Not by protocol compliance, but by whether you can refuse an unauthorised request. These are the signals that separate a trust model from a message format.

Authority travels. Requests carry verifiable scope and principal.

Provenance survives. The original requester is recoverable at any hop.

Trust is explicit. Counterparties are configured, not assumed.

Scope narrows. Authority decreases along the chain.

Chains are auditable. Correlated tracing spans every participant.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Interoperation depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

Agent permission scoping supplies the authority model. Multi-agent handoffs cover the task transfer. API gateways for machine clients cover the edge. Agent orchestration covers internal coordination. Naming these adjacencies upfront keeps the work scoped and helps leadership see authority as the gap.

The common mistake is treating each adjacency as someone else's problem. The delegation design is your problem. The trust configuration is your problem. The provenance chain is your problem. Pretend otherwise and a parseable message will be an authorised one. Own the adjacencies you depend on, partner with the teams that hold them, and share the model.

Conclusion

Agent interoperation protocols solve a genuine problem, which is that agents from different systems need a shared way to describe capabilities and exchange tasks. They do not solve the question that determines whether interoperation is safe: when a request arrives, is the caller entitled to make it, on whose behalf, and within what bounds. A well-formed message asserts none of that, so an agent receiving one either trusts every structurally valid caller or negotiates bilaterally, and both defeat the purpose. Carry delegated authority with scope and principal, preserve provenance through every hop, configure counterparty trust explicitly, narrow scope at each delegation, and correlate tracing across the chain.

Key Takeaways:

Format standardisation makes messages parseable, not authorised
Provenance is lost by the third hop unless it is designed to survive
Authority should narrow along a chain and frequently gets re-established instead

Designing interoperation well requires carrying permission. When done correctly, it produces:

Requests honoured within a verifiable mandate
Chains auditable back to the original principal

An API Review Template Built for a World Where Agents Are Your Caller

Review APIs for agent callers before ambiguity becomes an integration risk.