DM Explains · No. 015 · Architecture
Cross-model interoperability: why AI vendors are finally learning a shared language
Enterprises juggling multiple AI vendors used to write custom glue code for every pair. New translation layers and protocols promise one dictionary instead of many.
· 14 min read
Read me first
Translation layers between AI vendors genuinely do cut the integration work from one adapter per pair of providers to one per provider, but only because the APIs turn out to disagree on words, not on meaning.
OpenAI Chat Completions call hits LLM-Rosetta → 1 confirmed to share semantic core with Anthropic/Google formats → 2 mapped into the 9-type IR → 3 one of 4 converters applies → 4 streamed as ordered IR events → 5 a tool call is dispatched via MCP → 6 business terms resolved via shared schema → 7 round trip validated against 1,364 tests → delivered with sub-100µs overhead
A company calls OpenAI for one task, Anthropic for another, and Google's models for a third, and every time it adds a provider, someone has to write fresh glue code translating one vendor's request format into another's. Add a fourth vendor and the glue code does not grow by one more adapter — it grows by three, because every existing provider now needs a path to the new one too.
Without a shared format, that integration work grows with the square of the number of providers, locking teams into whichever vendor they integrated first and making it expensive to switch when a cheaper or better model appears next quarter. The arithmetic below is illustrative: four providers calling each other directly need up to six bilateral adapters; a fifth provider adds four more. The pattern is combinatorial, and it is exactly the problem a shared translation layer is built to remove.
Everyday picture. At the dinner table, Amma, Papa, Dadi and Arjun each speak a different language, and the family used to need a separate translator pair for every two people who wanted to talk, which got exhausting as more relatives visited.
Where the picture breaks. Human languages diverge in genuine meaning, not just vocabulary. The AI APIs in this story share far more underlying structure, so one shared family dictionary works for everyone far more cleanly than a human translator ever could.
Why it exists now
The fragmentation is not new; multiple incompatible LLM APIs have existed for years. What changed is that researchers finally measured how deep the incompatibility actually goes, and three concrete pieces of infrastructure arrived to act on that measurement. A research framework called LLM-Rosetta compared OpenAI's Chat Completions and Responses APIs, Anthropic's Messages API, and Google's GenAI API, and found that despite the superficial differences, these providers encode the same underlying concepts — messages, tool calls, streaming — just with different field names and structures (LLM-Rosetta — arXiv, 2026). That finding matters because it means the problem is tractable with one shared format rather than needing bespoke semantic reconciliation for every pair.
Alongside that, the protocols that let AI agents reach tools and reach each other matured fast. Model Context Protocol (MCP) adoption among surveyed organisations rose from 12% to 48% between Q3 2025 and Q1 2026 (The State of Agent Interoperability — OSSA Research, 2026). Google's Agent-to-Agent (A2A) protocol, introduced in April 2025, has gathered backing from over 50 enterprise partners including Salesforce and SAP (A2A protocol — AgentModeAI, 2026). And Apache Ossie, an open specification for representing business data definitions across platforms, began incubating at the Apache Software Foundation and is now backed by more than 60 companies (Microsoft, Google back Apache Ossie — CIO.com, 2026). Three different layers of the stack, moving towards shared formats at roughly the same time.
How it works
Divergence is skin-deep
Different words, same shared core underneath
What it is. The surface-level disagreement between major LLM APIs — different field names, different nesting, different ways of marking a tool call — sits on top of a shared conceptual structure.
Why it exists. Each provider built its API independently, so naming and shape diverged even where the underlying ideas did not.
Where it breaks. Syntactic similarity does not mean the models behave the same way once a request actually reaches them; a converted prompt can be perfectly well-formed and still produce a worse answer.
How that's handled. Treat format translation and model behaviour as separate problems — solve the format problem with a shared representation, and measure behaviour separately.
In technical terms
In technical terms: LLM-Rosetta's authors found that despite substantial syntactic divergence across OpenAI Chat Completions, OpenAI Responses, Anthropic Messages and Google GenAI, the APIs share a common semantic core, meaning naïve pairwise translation would otherwise require a combinatorial number of bilateral adapters as more providers are added.
One shared dictionary
Translate once, not for every pair
What it is. A provider-neutral Intermediate Representation (IR) that every vendor's format converts into and out of, so the problem becomes one converter per provider rather than one per pair of providers.
Why it exists. If a shared semantic core already exists, encoding it once avoids rebuilding the same translation logic for every new combination of vendors.
Where it breaks. Designing an IR expressive enough to capture every vendor's current features, without losing nuance, is itself a hard and ongoing design problem — one that has to be maintained every time a vendor ships something new.
How that's handled. The IR is built from an explicit, typed model rather than a loose grab-bag of fields, so additions have a defined place to go.
In technical terms
In technical terms: LLM-Rosetta's Intermediate Representation captures messages, content parts, tool calls, reasoning traces and generation controls using a 9-type content model and a 10-type stream event schema.
Modular converters
Add a vendor without touching the others
What it is. Each provider gets its own converter, assembled from reusable pieces that each handle one concern — content, messages, tools, configuration.
Why it exists. Modularity means the work of adding a new vendor does not depend on how many vendors are already wired in.
Where it breaks. Modularity reduces effort but does not eliminate it; a genuinely novel vendor feature can still require new modules across several converters at once.
How that's handled. The converters are built against the same orthogonal module boundaries for every provider, implemented so far for four major API standards.
In technical terms
In technical terms: LLM-Rosetta implements converters for OpenAI Chat Completions, OpenAI Responses, Anthropic Messages and Google GenAI, each assembled from shared content, message, tool and configuration modules rather than bespoke per-pair code.
Streaming translation
Keep the pieces in order as they arrive
What it is. Converting a live, chunk-by-chunk response as it streams, rather than converting one finished answer.
Why it exists. Production chat and agent systems overwhelmingly stream responses, so a translation layer that only works on completed answers misses most real traffic.
Where it breaks. Stateful translation adds complexity exactly where production systems are most sensitive to latency and dropped connections.
How that's handled. Requests and responses move provider to Intermediate Representation to provider, with typed event kinds and context tracked across the whole stream so chunks stay synchronised.
In technical terms
In technical terms: LLM-Rosetta demonstrates lossless round-trip fidelity and correct streaming behaviour, validated across 1,364 tests and the Open Responses compliance suite, with conversion overhead measured at sub-100 microseconds — competitive with single-pass tools while adding full bidirectionality.
Tool and agent protocols
Bruno fetches the ball for anyone who whistles
LLM-Rosetta at Argonne: 1 OpenAI, Anthropic, Google payloads arrive → 2 shared core found despite syntax → 3 built into a 9-type IR → 4 converters restore each provider's syntax → 5 MCP/A2A handle 18,000+ tool servers separately → 6 1,364 tests confirm lossless round trips → sub-100µs overhead in production
What it is. Two separate standards sitting above the model-API layer: Model Context Protocol (MCP) standardises how an agent discovers and uses external tools and data; Agent-to-Agent protocol (A2A) standardises how agents built on different frameworks discover each other and hand off tasks.
Why it exists. Interoperability isn't only about one model's request format matching another's — multi-agent systems also need a shared way to reach tools and pass work between agents.
Where it breaks. These protocols address tool access and task handoff, not the raw request and response translation between model APIs — a different layer entirely, easily confused with it.
How that's handled. Keep the layers distinct: a translation layer like LLM-Rosetta converts model API payloads; MCP and A2A sit above it governing tool access and agent coordination.
In technical terms
In technical terms: MCP adoption among surveyed organisations rose from 12% to 48% between Q3 2025 and Q1 2026, while A2A adoption reached 22% over the same period; A2A, introduced by Google in April 2025, now counts more than 50 enterprise partners including Salesforce and SAP.
Shared business meaning
One borrowing card for every shelf
What it is. A shared format for business-level definitions — datasets, fields, relationships, metrics — so a metric means the same thing whether it is read in one analytics platform or another.
Why it exists. Even once models and agents interoperate, the numbers they reason over still need to agree, or analytics drift apart across platforms.
Where it breaks. Apache Ossie is still an incubating, version 0.2 development draft that does not yet define bundles or cross-model references, and even a metric that converts cleanly can still produce a different result on another platform because of how that platform interprets joins, nulls, time calculations or filters.
How that's handled. Vendors are building bidirectional converters now rather than waiting for the specification to be complete — Microsoft, for instance, built a two-way converter between its own semantic models and the shared format.
In technical terms
In technical terms: Apache Ossie, formerly Open Semantic Interchange, began incubating at the Apache Software Foundation and is backed by more than 60 companies including Microsoft, Google, Databricks, Mistral AI, Nvidia and Oracle; it represents datasets, fields and metrics in JSON and YAML, with converters to platforms including Power BI, Snowflake and Databricks.
Prove it round-trips
Trust is earned in round trips, not promises
What it is. Formal evidence that a translation layer preserves information exactly and does not add unacceptable delay, rather than a claim taken on faith.
Why it exists. Enterprises will not put a translation layer between themselves and production model calls without proof it does not silently drop or distort data.
Where it breaks. Passing a compliance suite proves format fidelity, not that two different models give equally good answers to the same question — translation guarantees the envelope arrives intact, not that the letter inside says the same thing twice.
How that's handled. Measure round-trip fidelity and latency as a distinct, published result, separate from any claim about answer quality.
In technical terms
In technical terms: LLM-Rosetta demonstrates lossless round-trip fidelity and correct streaming across 1,364 tests and the Open Responses compliance suite, with sub-100 microsecond conversion overhead.
Compared with what came before
| Bilateral glue code | Shared translation layer | |
|---|---|---|
| Integration effort per new vendor | Grows with every existing vendor already wired in | One converter, independent of how many vendors exist |
| Where fidelity is checked | Ad hoc, per integration | Against a compliance suite and round-trip tests |
| Switching vendors | Rewrite application logic tied to the old format | Point at a different converter |
| What's guaranteed | Nothing beyond what each custom adapter was tested for | Format and semantic fidelity of the request and response — not answer quality |
The judgement is unglamorous: a shared translation layer trades a pile of brittle, bespoke adapters for one well-tested converter per vendor, and that trade is worth making the moment a team is juggling more than two providers.
Where it breaks
Translation layers solve the format problem, but only when the thing underneath is genuinely shared — and it genuinely does help, provided nobody mistakes format fidelity for behavioural equivalence.
Not a guarantee of equal answers
Converting a request losslessly from one vendor's format to another's does not mean the two models will produce comparably good answers to that request. Translation preserves the envelope; it says nothing about what the model inside does with it.
Business semantics are younger than model semantics
Apache Ossie's specification is still a version 0.2 development draft that does not yet define bundles or cross-model references. A metric can convert cleanly on paper and still produce a different number on a new platform, because that platform interprets joins, nulls, time calculations or filters differently.
Tool-access and agent-handoff protocols — MCP and A2A — sit at a different layer again, and conflating them with API-level translation is a common mistake. MCP governs how an agent reaches a tool; A2A governs how one agent hands a task to another built on a different framework; neither one translates a raw request from one model vendor's format into another's.
Numbers to carry
| Figure | Value |
|---|---|
| MCP adoption, surveyed organisations, Q3 2025 to Q1 2026 | grew from 12% to 48% |
| A2A adoption, surveyed organisations, as of Q1 2026 | 22% |
| A2A enterprise partners, as of 2026 | over 50, including Salesforce and SAP |
| Apache Ossie backers, as of 2026 | over 60 companies |
| Apache Ossie incubation start | June 2026 |
| Apache Ossie specification status | version 0.2, development draft |
| LLM-Rosetta API standards covered | 4 (OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Google GenAI) |
| LLM-Rosetta content/stream schema | 9-type content model, 10-type stream event schema |
| LLM-Rosetta validation | 1,364 tests plus the Open Responses compliance suite |
| LLM-Rosetta conversion overhead | sub-100 microseconds |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Every LLM vendor's API is fundamentally different" | Researchers found a shared semantic core beneath the syntactic differences across four major APIs |
| "MCP and A2A solve the same problem" | MCP standardises tool access; A2A standardises agent-to-agent task handoff — different layers, different jobs |
| "A shared format means identical answers" | A translation layer preserves the request and response faithfully; it says nothing about whether two models answer equally well |
| "Apache Ossie is finished and ready for complex enterprises" | It is an incubating, version 0.2 development draft without bundles or cross-model references yet |
| "Agent protocols replace model-API translation layers" | They sit above it; a system can need all three — MCP, A2A, and a format translator — at once |
Worked example
- Argonne National Laboratory (illustrative framing of the dossier's reported deployment) runs LLM-Rosetta in production, with converters for OpenAI Chat Completions, OpenAI Responses, Anthropic Messages and Google GenAI.
- A researcher's application sends a request written against OpenAI's Chat Completions format.
- LLM-Rosetta converts that request into its provider-neutral Intermediate Representation, using its 9-type content model to capture messages, tool calls and generation controls.
- The IR is converted onward into Anthropic's Messages format and sent to Anthropic's API, because that is the provider the application wants to query this time.
- Anthropic streams its response back chunk by chunk; LLM-Rosetta translates the stream using its 10-type stream event schema, tracking context statefully so the chunks arrive in order.
- The translated stream reaches the application in the shape it originally expected, having added sub-100 microsecond overhead, with fidelity checked against the Open Responses compliance suite and 1,364 tests.
- Next quarter, the team adds a fourth provider. Because the architecture is hub-and-spoke, this requires one new converter, not a rewrite of the three that already exist.
Should you use it?
Reach for a shared translation layer when an organisation genuinely calls more than two model vendors and the integration code between them is starting to duplicate itself. Skip it when there is only one vendor in play, or when the real goal is to lock in behaviour from one specific model rather than keep the option to switch — a translation layer buys flexibility, not identical output.
The cheapest first experiment is not adopting a framework; it is auditing how many bilateral adapters already exist across current vendor integrations and totting up what each new vendor has actually cost to add. If that number is climbing with every new provider rather than staying flat, the combinatorial problem described above is already live, whether or not anyone has named it yet.
Say it in the room
"Use a shared translation layer when the API glue code is growing with every vendor added; skip it when there's only one model provider and no plan to switch."
Lines to carry
- "Different words, same shared core underneath."
- "Translate once, not for every pair."
- "A shared format doesn't guarantee a shared answer."
- "Syntax travels easily; meaning doesn't always survive the trip."
- "One dictionary beats a translator for every pair of relatives."
FAQ
Is this the same thing as using a router like OpenRouter?
Not quite. An aggregator service sits behind one endpoint and routes calls to many providers, which solves a different problem — picking a provider — rather than providing the bidirectional, lossless, provider-neutral representation that a true translation layer like LLM-Rosetta is built around.
Do MCP and A2A replace the need for API-format translation?
No. MCP standardises how an agent reaches external tools and data; A2A standardises how agents hand tasks to each other across frameworks. Neither one converts a raw request from one model vendor's format into another's — that is the job a translation layer does.
If the formats translate cleanly, will the answers be the same across vendors?
No, and that is worth saying plainly. Translation preserves the shape and semantics of the request and response; it says nothing about whether the model receiving that request produces an equally good answer. Format fidelity and answer quality are separate questions.
Is Apache Ossie ready for a large enterprise with many interconnected systems?
Not yet by its own description. It is still an incubating, version 0.2 development draft that does not define bundles or cross-model references, so large enterprises with deeply interconnected models may find it insufficient today, even as more than 60 companies back its direction.
Why does streaming make translation harder than it sounds?
Because a streamed response arrives in pieces, and a translation layer has to keep track of context across every chunk rather than converting one finished block of text. Get that wrong and chunks can arrive out of order or desynchronised, which a system converting complete responses never has to worry about.
Glossary
- API (Application Programming Interface) — a defined way for one piece of software to request services or data from another.
- LLM (Large Language Model) — an AI system trained on large amounts of text that generates or processes language.
- Intermediate Representation (IR) — a common internal format that different systems' data or requests are converted into and out of, so only one converter per system is needed rather than one per pair.
- Hub-and-spoke model — an architecture where every participant connects to one central format rather than directly to every other participant.
- Model Context Protocol (MCP) — an open standard, created by Anthropic, for how AI applications discover and use external tools and data sources.
- Agent-to-Agent protocol (A2A) — a protocol, introduced by Google, for AI agents built on different frameworks to discover each other and delegate tasks.
- Apache Ossie (formerly Open Semantic Interchange, OSI) — an open specification, incubating at the Apache Software Foundation, for representing business data definitions in a shared format across platforms.
- Streaming (in LLM APIs) — sending a model's response back in small pieces as it is generated, rather than waiting for the whole answer.
- Tool calls — a mechanism by which a model requests that an external function or API be executed on its behalf.
- Round-trip fidelity — the property that converting data from one format to another and back again produces the exact original, with nothing lost or altered.
- Vendor lock-in — a situation where switching away from a supplier is costly because of deep integration with that supplier's specific format.
- Semantic model — a structured definition of business concepts like datasets, metrics and relationships, independent of any one analytics tool.
- Compliance suite — a set of standardised tests used to check whether a system correctly implements a given specification.
Sources
- LLM-Rosetta: A Provider-Neutral Intermediate Representation for Cross-Model LLM API Translation — arXiv, 2026
- Microsoft, Google back Apache Ossie to make enterprise data and AI platforms more interoperable — CIO.com, 2026
- The State of Agent Interoperability: 2026 Report — OSSA Research — Open Standard Agents, 2026
- A2A protocol: enterprise agent interoperability — AgentModeAI, 2026
- Agent Interoperability: A Developer's Architecture Guide — Lyzr.ai