The Coming Agent Interoperability Standard and What It Needs

Tool access is converging on a shared protocol. Agent-to-agent interaction is a harder problem and has no equivalent answer yet. This piece covers what it will need, drawing on FISTA Solutions' AI agents engineering work.

What does interoperability require?

Five components, in rough order of difficulty.

Component	State of the art
Message format	Tractable; several proposals
Capability discovery	Emerging; declaration without verification
Identity	Unsolved across organisations
Delegated authority	Unsolved; borrows from existing models
Accountability trail	Rarely implemented
Dispute resolution	Not addressed

Why is this harder than tool access?

Because the other party makes decisions.

A tool call goes to a deterministic service that does what it is asked. An agent call goes to a system that interprets, decides, and may act in ways the caller did not anticipate — which means the caller is accepting a risk rather than invoking a function.

That difference introduces trust as a first-class concern. The receiving agent must decide whether to act, and both sides need a record of what was requested and what authority backed it. See why enterprises are standardizing on MCP.

What does identity need to establish?

Which agent, on whose behalf, with what authority, verifiable by the recipient.

Within one organisation this can borrow from existing identity systems. Across organisations it requires something that does not yet exist in standard form: a way for an agent from another company to prove it is acting for a specific principal with specific permissions.

The absence of this is why cross-organisational agent interaction is currently bespoke and bilateral. Each pair of parties establishes trust directly, which does not scale.

How should delegation work?

As a bounded, time-limited, revocable subset of the original grant.

A user authorises an agent; that agent needs to involve another agent; the second must receive less authority than the first, not the same. Otherwise every delegation hop widens the blast radius.

Existing authorisation models provide a starting point, but they were designed for services rather than for autonomous parties making judgement calls. The gap is that a delegated agent may use its authority in ways the delegator did not foresee. See how to set up agent permissions.

Why must discovery be verifiable?

Because a declared capability is a claim, and claims can be wrong.

An agent that advertises it can process refunds, and cannot, will receive work it fails to complete. At small scale that is an error; at scale it is a system that routes work into dead ends.

Verification could take several forms — attestation, test invocations, reputation from prior interactions — and none is settled. This is the part most likely to be solved first, because it is tractable within a single organisation.

What does accountability require?

A trail that survives several hops and names a human at the origin.

When an action three delegations deep causes harm, the question is who authorised it. That requires each hop to record what was delegated, by whom, under what constraint, in a form that can be reconstructed afterwards.

Most current implementations lose this immediately. The first agent logs its actions, the second logs its own, and nothing connects them. Building the chain is not difficult; it is simply not being done. See human in the loop AI explained.

Where will this appear first?

Inside organisations, where identity and trust already exist.

An enterprise with a directory, established permissions, and a single accountability structure can build agent-to-agent interaction today. The identity problem is solved; the work is delegation and audit.

Cross-organisational interaction waits on trust infrastructure. Expect it initially between parties with existing contractual relationships, extending the agreements they already have rather than relying on an open standard.

What is the counter-argument?

The counter is that this may not be needed — that a single agent with access to many tools is simpler than several agents cooperating, and that the multi-agent framing is largely fashion. There is force in that. Many multi-agent designs would work better as one agent with more tools, and the interoperability problem only matters where the agents genuinely belong to different parties.

What does this change for engineering teams?

It means designing agents with identity and delegation in mind now, even when only one agent exists. Recording who authorised each action, with what constraint, costs little and is very difficult to retrofit.

It also means treating another team's agent as an untrusted caller rather than as an internal function.

What does this change for buyers?

It means asking vendors how their agent identifies itself, what authority it carries, and what record exists of actions it takes on your behalf.

And asking what happens when their agent interacts with a third party's — because that is where accountability currently disappears.

What should leaders do about it now?

Require an accountability chain in any agent your organisation deploys: every action traceable to a human authorisation with its constraints. That requirement is cheap now and is the thing auditors will ask for.

Be sceptical of multi-agent architectures where one agent would do. The interoperability cost is real and should be paid only when the separation is.

Does this connect to the agent supply chain?

Directly. An agent you did not author, running with authority you delegated, is a supply chain dependency with the same questions: what does it do, what can it reach, and what happens when it is compromised.

The standards needed for interoperability are largely the same ones needed for supply chain assurance. See the agent supply chain problem.

How will you know if this is happening?

Watch for bilateral agent integrations being built repeatedly, for delegation implemented by sharing credentials, and for audit trails that stop at the first hop. All three indicate the gap is being worked around rather than solved.

How FISTA Solutions reads this

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: delegation recorded as a bounded, revocable grant at every hop, and accountability chains that reconstruct back to a named human authorisation, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To discuss what this means for your roadmap, message FISTA on WhatsApp, or read why enterprises are standardizing on MCP.