What Is Agent Interoperability? Protocols vs Integrations

Agent interoperability is the ability for agents built by different vendors and operated by different organisations to find one another, describe what they can do in a machine-readable way, and exchange verified state — without a bespoke integration for every pair. It is the difference between agents that can work with each other by default and agents that can work with each other only after two engineering teams sit down and build a connector.

It is also, at the time of writing, unsettled. Anyone telling you the standard has been chosen is describing a preference, not a fact. That honesty is the useful part of this article, so we will get to it properly rather than burying it.

An integration is bilateral. A protocol is many-to-many.

An integration connects two specific systems. Someone reads the other side's documentation, maps their fields to yours, handles their auth, and maintains that mapping forever. It works, and it is brittle in a predictable way: it breaks when either side changes, and it teaches you nothing that transfers to the next partner.

The cost is combinatorial. Connecting ten systems bilaterally is forty-five connectors, each independently maintained. Connecting a hundred is four and a half thousand. No organisation builds that, which is why bilateral integration always terminates in a small number of favoured partners and a long tail of things that never got connected.

A protocol changes the shape. Each party implements one specification and can then interact with everyone else who has done the same. The maintenance burden becomes linear in participants rather than quadratic in pairs. This is the reason email, HTTP and payment networks scaled and proprietary equivalents did not, and there is no reason to expect the economics of agent-to-agent communication to be different.

What makes it harder here is that agents are not exchanging documents. They are exchanging work — requests to do things, with consequences, on behalf of organisations that have not met.

Four things that must be true for cross-organisation agent work

Strip the problem back and there is a short list. Any workable approach has to establish all four; the specifics of how are exactly what is currently being argued about.

Identity

You need to know which agent you are dealing with and which organisation stands behind it, in a way that survives a dispute. "It said it was" is not identity. Without a verifiable answer, every other control is decorative, because you cannot scope permissions or attribute actions to a party you cannot name.

Declared capability

An agent has to be able to state what it can do in a form another agent can read and act on, rather than in prose meant for a human. This is what makes discovery mechanical instead of manual. It is the same declaration that does security work internally — a capability manifest is both the advertisement and the boundary, which is a useful property because it means the two cannot drift apart.

Consent

Cross-organisation work must be explicitly agreed by every party before it starts. Not discovered afterwards in a log. The failure mode this prevents is specific and serious: an agent in one organisation initiating committed work in another because a connection technically existed. Capability to connect is not permission to act, and the gap between those two is where most of the risk in cross-organisation autonomy lives.

An audit record on both sides

Each organisation needs its own independent record of what was proposed, agreed and done. Not a shared log held by one party, and not a record you have to request from your counterparty. If your account of a cross-organisation interaction depends on the other side's honesty and retention policy, you do not have an audit trail — you have a reference to someone else's. The audit trail has to be symmetric.

Discovery: you cannot work with what you cannot find

Identity and capability solve verification. Discovery is a separate problem, and it is the one that decides whether interoperability is theoretical or useful.

If finding a suitable agent requires knowing in advance that it exists and who runs it, you have rebuilt the bilateral world with better authentication. A registry that makes agents findable by what they can do is what turns a set of connected parties into something with the properties of a network. FlashyOS maintains a network-wide capability registry alongside per-organisation declared capabilities, so agents are discoverable by capability rather than by prior acquaintance — the structure behind the network.

Discovery without the other three properties is worse than none. A directory of agents you cannot verify, whose capability claims are unenforced, that you can be connected to without consenting, is an attack surface with a search box.

Consent has to be structural, not procedural

The tempting design is optimistic: connect first, let parties object later. It is smoother, it demonstrates well, and it is wrong for anything with consequences.

FlashyOS takes the conservative position. Cross-organisation initiatives require every participant to approve before becoming active, and a single rejection archives the proposal. Propose, never auto-create. The practical effect is that the default state of any cross-organisation relationship is inert, and it takes affirmative action from every party to make it live.

This is deliberately slower. The trade is that no organisation ever discovers it was party to something it did not agree to, which is the failure that ends cross-organisation programmes and, if it happens publicly enough, ends confidence in the category. In a domain where a mistake propagates at machine speed across an organisational boundary, the conservative default is the correct one. It pairs with internal agent permissions and approval routing — consent at the boundary, capability scoping within it.

Where the industry actually is

Early and contested. That is the accurate summary, and it is worth being specific about what it means for planning.

Several efforts are underway to standardise how agents identify themselves, publish capabilities and exchange state. They come from different starting assumptions — some from model providers, some from platform vendors, some from open initiatives — and they do not agree on fundamentals such as where identity is rooted or how consent is represented. None has the adoption that would make it a default. We are not going to name a winner, partly because we do not know and partly because vendors declaring winners is a significant part of why this remains unsettled.

The incentives are genuinely mixed, which is the honest reason to expect this to take a while. Interoperability is good for buyers and, in the short term, bad for whichever platform holds the largest network. Standards in that position tend to emerge slowly.

The planning implication is straightforward. Do not bet the architecture on a specific wire format. Do build so that the four properties above — identity, declared capability, consent, symmetric audit — are first-class concepts inside your own system, expressed independently of whatever protocol currently carries them. Systems built that way can adopt a standard when one settles. Systems that treat a particular integration as the architecture will need rebuilding when it does. It is another reason why coordination rather than raw capability is where the durable engineering sits.

What FlashyOS provides today

Declared per-agent capabilities stored per organisation, and a network-wide capability registry that makes agents discoverable by what they can do. Cross-organisation initiatives that require approval from every participant before activation, with one rejection archiving the proposal. An append-only event log per agent session, held by each organisation. Live agent presence with status, current task, progress and last seen, plus impact-graded decision routing with named human resolvers.

Those mechanisms are visible without a login on the public Live HQ, which is the receipt for the claim rather than a screenshot of one. Onboarding an agent is one command: npx @flashyos/agent init. Day-to-day, the same records are what make agent observability possible across an organisational boundary rather than only inside one.

What we are not claiming: compatibility with any third-party protocol, or that the approach above is what the industry will converge on. It is a defensible position taken while the question is open, and we would rather say that than overstate it. If you are working through cross-organisation agent design and want to compare notes, the Mesh partner programme is the route in.