← DM Explains

DM Explains · No. 036 · Models

Model protocol federation: how separate AI models cooperate without merging

A new wave of protocols lets independently owned language models discover each other, negotiate, and swap tiny structured messages instead of weights, data, or even full conversations.

· 14 min read

Here is the corrected article, with the flagged figure removed and replaced with wording drawn only from the dossier.

Read me first

Model protocol federation genuinely lets separately owned language models cooperate without merging, but only when they trade small typed messages instead of full prompts, weights, or raw conversations.

What is Protocol Federation?

Three models under one roof: a legal-drafting model, a customer-tone model, a coding model → 1 each advertises capabilities → 2 they negotiate terms, reducing coordination latency 29–34% → 3 they exchange a typed compendium at 5.3 KB per client per round with ≈2-pt loss → 4 metadata checked under (ε,0)-DP → 5 scores aggregated via a dual-server scheme secure against n-2 colluding clients → 6 the legal query routes to the drafting model at 0.92±0.02 routing accuracy

The figure shows six steps by which independently owned models cooperate — advertising capabilities, negotiating terms, exchanging typed artifacts, enforcing privacy, aggregating securely, and routing the query — without ever merging weights, data, or prompts. Cooperate without merging.

A company runs three specialised models from three different vendors — one for legal drafting, one for customer tone, one for code — and every query currently has to be routed by hand, or sent to all three and compared, because the models have no way to tell each other what they know or need. Call every model for every query and costs and latency balloon. Pick one model and the other two sit idle, their strengths wasted. Share raw prompts or weights across vendor boundaries and you may breach a contract, a privacy law, or simply hand a competitor your best model's behaviour.

Everyday picture. Amma, Papa, Dadi and Meera are each expert in a different household job — cooking, accounts, storytelling, homework — but none reads another's diary. Instead they leave short, standard-format notes on the fridge saying what help they need and what they can offer, and Dadi checks any proposed trade against the household's own rules before it happens.

Where the picture breaks. A fridge note can't carry the nuance of a full conversation, which is why typed artifacts lose a little information compared with sharing a full internal state. And Dadi's trust is built over years of family history; machine negotiation agents have no equivalent shortcut between strangers' models, so they rely on cryptographic proofs instead.

Why it exists now

Through late 2025 and into 2026, a wave of preprints and conference papers converged on a single question: how can several frozen, independently trained large language models cooperate at the moment a query arrives, rather than being merged beforehand or trained together from scratch. A taxonomy from the ACL 2026 proceedings classifies these interactions by depth — API-level, text-level, logit-level, and weight-level collaboration — and that framing matters because it shows cooperation is a spectrum, not a single choice between "share everything" and "share nothing" (When One LLM Drools, Multi-LLM Collaboration Rules, ACL Anthology, 2026).

What changed is that enterprises stopped running one general-purpose model and started running several specialised ones side by side, each owned by a different vendor, each too expensive or too risky to call for every request. Federated learning already solved a related but different problem — training one shared model without centralising raw data. Model protocol federation solves the inference-time problem: coordinating models that are already trained, already frozen, and already owned by separate parties.

How it works

1

A model can't be hired for a job it never posted

What it is. Each model, or a small negotiation agent attached to it, publishes what it can do, its interfaces, and the terms under which it will act, before any task is assigned.

Why it exists. Without this discovery step, a federation has no way to know which model suits a given request or policy context — the legal model, the tone model, or the code model.

Where it breaks. Vague or outdated advertisements turn routing into guesswork no matter how sound the negotiation protocol underneath is.

How that's handled. Capability listings are treated as data to be checked and refreshed, not a one-time setup step.

In technical terms

In technical terms: each participant maintains a service-directory-style advertisement of capabilities, interfaces, and constraints that other agents query before proposing terms.

2

Negotiate terms

No handshake, no exchange

What it is. Negotiation agents exchange proposals about resource use, data access, and security requirements, each checking a proposal against its own local policy rules rather than deferring to a central approver.

Why it exists. Decentralised negotiation means no single party has to be trusted to adjudicate every exchange, which matters when the models belong to mutually distrusting organisations.

Where it breaks. Avoiding a single point of failure can cost time: when several parties disagree on terms at once, reaching consensus takes longer than a central authority simply deciding.

How that's handled. A testbed for the Model-to-Model Negotiation Protocol (M2M-NP), built on a Kubernetes-based hybrid cloud, measured 29 to 34% lower coordination latency and about 22% better resource utilisation compared with centralised orchestration (Model-to-Model Negotiation Protocols in Secure Cloud Environments, TechRxiv, 2026).

In technical terms

In technical terms: M2M-NP agents exchange structured proposals and validate them against locally held policy constraints, with no central orchestrator approving each exchange.

3

Exchange typed artifacts

Fridge notes, not diaries

What it is. Instead of trading full prompts, weights, or raw conversations, models exchange compact, schema-checked objects — typed artifacts — or, in a more advanced variant, internal key-value cache states.

Why it exists. Small typed units are cheap to move and let privacy rules be applied field by field, rather than treating an entire shared message as one indivisible blob.

Where it breaks. Typed formats discard nuance that a full conversation or full internal state would carry, which is exactly why small accuracy losses show up when information is compressed into a schema.

How that's handled. SYNAPSE's typed compendium transferred federated tool-routing knowledge across four different model families — LLaMA-3.1-8B, LLaMA-3.2-3B, Mistral-7B, and GPT-4o — at 5.3 KB per client per round, losing about 2 points of accuracy and matching centralised routing on GSM8k at 0.92±0.02 accuracy, a result the authors describe as statistically indistinguishable from the centralised baseline (SYNAPSE: Federated Tool Routing via Typed Compendium Artifacts, arXiv, 2026). Separately, a 2026 survey describes cache-to-cache exchange of internal key-value states as a way to cut the latency overhead that plain token-to-token exchange between models incurs (Cache-to-Cache communication for LLM collaboration, arXiv, 2026).

In technical terms

In technical terms: typed federated artifacts are schema-validated objects with distinct fields for capability metadata, routing signals, and numeric statistics, each governed by its own merge and privacy rule; cache-to-cache exchange instead transfers internal key-value states directly between model instances.

4

Enforce privacy

Trust, but verify the metadata

What it is. Formal privacy guarantees and machine-checkable policy rules are applied to the data inside each exchange, not left to informal agreement between vendors.

Why it exists. Enterprises federating proprietary models need a provable bound on what can leak, not just a promise that nobody is looking.

Where it breaks. A differential-privacy bound protects aggregate statistics; it does not prevent a model from oversharing qualitative context that was never covered by the numeric guarantee.

How that's handled. SYNAPSE attaches a formal (ε,0)-differential privacy guarantee to the numeric metadata fields inside its typed artifacts, while policy-as-code engines check every exchange against compliance rules at the moment it happens (SYNAPSE, arXiv, 2026).

In technical terms

In technical terms: numeric fields in each artifact carry an (ε,0)-differential privacy bound, enforced alongside runtime policy-as-code checks on every proposed exchange.

5

Aggregate securely

No single server sees it all

What it is. When outputs or parameter updates from several models must be combined into one result, cryptographic secure-aggregation protocols hide any single participant's individual contribution from the aggregator itself.

Why it exists. It stops even the orchestrating server from reconstructing one model's private output, which matters when the orchestrator and the models are owned by different parties.

Where it breaks. The cryptography adds real computation, and the security guarantee assumes some participants are not colluding; it offers nothing once nearly everyone colludes.

How that's handled. Janus, a dual-server secure aggregation scheme, cuts per-client communication and computation overhead from logarithmic to constant scale, while remaining secure against up to n-2 colluding clients out of n total participants (Janus: Dual-Server Multi-Round Secure Aggregation with Verifiability for Federated Learning, Proceedings of Machine Learning Research, 2025).

In technical terms

In technical terms: Janus distributes aggregation across two non-colluding servers with verifiable correctness proofs, reducing per-client overhead from O(log n) to O(1) while tolerating up to n-2 colluding clients.

6

Route the query

Right specialist, not every specialist

What it is. A routing layer picks or combines models for each incoming query, using whatever was advertised and negotiated earlier, so most queries touch only the models likely to help.

Why it exists. Federation only pays off if queries land on the right specialist cheaply; calling every model for every request defeats the point.

Where it breaks. Routing is only as reliable as the stability of the assumptions behind it. SYNAPSE's own authors found their routing-stability guarantee fails on a LiveBench subset, where the measured contraction value came out at 1.018 against a required threshold of 1 or less — a reminder that a theoretical guarantee can fail on a particular data distribution (SYNAPSE, arXiv, 2026).

How that's handled. SkyLLM federates calls across multiple large language model application programming interfaces (APIs), reportedly outperforming a fixed-model-for-every-query approach on cost and performance by sending each request only where it is likely to pay off (SkyLLM: Cross-LLM-APIs Federation for Cost-effective Query Processing, ACL Anthology Findings, 2025).

In technical terms

In technical terms: a routing layer scores candidate models against advertised capabilities and recent performance signals, selecting a subset rather than invoking every available model per request.

Compared with what came before

Old wayFederated protocol wayWhat you give up
Call every model for every query, then compareRoute each query to the model(s) likely to handle itA guaranteed second opinion on every answer
Pick one vendor's model for everythingKeep several specialised models, exchanging small typed signalsSimplicity of a single integration point
Merge or fine-tune models into oneKeep models frozen and separate, trading messagesThe performance ceiling of a single jointly-optimised model
Share raw prompts or data across organisationsShare schema-checked artifacts or cached states with privacy boundsSome nuance that a full conversation would have carried

Each row trades a blunt, expensive form of cooperation for a narrower, cheaper one. The judgement call is whether the narrower exchange still carries enough signal for the task — SYNAPSE's roughly 2-point accuracy loss suggests it often does, but "often" is not "always", and the LiveBench failure above shows the gap can widen on the wrong data.

Where it breaks

Decentralised negotiation and typed-artifact exchange reduce the amount of raw data crossing organisational boundaries, but they do not remove every risk, and the conditional matters more than the promise.

A stability guarantee is not a law of nature

SYNAPSE's routing-stability contraction premise, intended to bound how routing accuracy degrades, measured 1.018 against a required value of 1 or less on a LiveBench subset — meaning the guarantee the authors proved does not hold for that distribution. A protocol's formal guarantees should be checked against the data they will actually see, not assumed to transfer.

Typed artifacts and cache exchange cut bandwidth, but cache-to-cache formats are not automatically interchangeable across different model architectures; making LLaMA, Mistral, and GPT-family caches talk to each other requires deliberate engineering, not a universal adapter. Secure aggregation schemes such as Janus assume at least some participants are not colluding; the n-2 tolerance is a strong bound, but it is still a bound, not an absolute. And differential privacy, as applied in SYNAPSE, covers numeric metadata specifically — it says nothing about a qualitative field that leaks more than intended simply because nobody wrote a schema rule for it.

None of this makes federation unsafe by default. It makes it a system whose guarantees are specific, measurable, and worth re-testing whenever the task, the models, or the data distribution changes.

Numbers to carry

FigureValue
M2M-NP coordination latency reduction vs centralised orchestration29–34% (TechRxiv, 2026)
M2M-NP resource utilisation improvementapproximately 22% (TechRxiv, 2026)
SYNAPSE artifact size per client per round5.3 KB (arXiv, 2026)
SYNAPSE accuracy loss vs centralised, across 4 model familiesapproximately 2 points (arXiv, 2026)
SYNAPSE GSM8k routing accuracy0.92±0.02 (arXiv, 2026)
SYNAPSE LiveBench stability measurement vs required threshold1.018 measured, required ≤1 (arXiv, 2026)
Janus per-client overhead scalingreduced from logarithmic to constant (PMLR, 2025)
Janus collusion toleranceup to n-2 colluding clients of n total (PMLR, 2025)

Myths worth killing

Commonly repeatedWhat is actually true
"Federation means the models get merged into one"The dossier describes federation as keeping models frozen and separate, exchanging messages or caches — merging weights is a distinct technique with its own trade-offs
"Sharing a typed artifact is as good as sharing the full conversation"SYNAPSE's own measurements show roughly a 2-point accuracy loss from compressing information into typed artifacts, even while matching centralised routing on GSM8k
"Decentralised negotiation is always slower than a central approver"M2M-NP's testbed measured 29–34% lower coordination latency than centralised orchestration, the opposite of the common assumption
"A differential privacy guarantee protects everything shared"SYNAPSE's (ε,0)-differential privacy bound applies specifically to numeric metadata fields, not to every piece of qualitative context in an artifact
"Secure aggregation makes collusion irrelevant"Janus is secure against up to n-2 colluding clients out of n — a strong bound, but not protection against near-total collusion

Worked example

  1. Papa's company advertises the capabilities of its three vendor models — legal drafting, customer tone, and code — each posting what it handles and its terms, following the advertise step above.
  2. The legal model's negotiation agent receives a drafting request tagged with a code-review dependency and proposes terms to the coding model's agent for sharing a routing signal, each checking the proposal against local policy.
  3. The two agents exchange a typed artifact rather than the full contract text — illustrative figures only: say a 6 KB object carrying intent, risk flags, and a numeric confidence score, broadly in line with SYNAPSE's measured 5.3 KB per client per round.
  4. A policy-as-code check confirms the numeric confidence field stays within the agreed differential-privacy bound before the exchange completes.
  5. The routing layer sends the query to the legal model alone, skipping the tone model entirely, because the advertised capabilities and the typed artifact indicated no tone-sensitive content — illustrative, but consistent with SkyLLM's approach of routing selectively rather than calling every model.
  6. Meera, reviewing the output later as a stand-in for a human auditor, can trace which model handled the request and on what declared terms, because the advertisement and artifact are both logged.

Should you use it?

Model protocol federation earns its complexity when an organisation already runs several heterogeneous, frozen models from different vendors that must cooperate without pooling raw data or weights, and when cost or latency pressure makes calling every model for every query impractical. It is the wrong tool for a single general-purpose model that already meets accuracy and latency needs, for ultra-low-latency systems that cannot absorb negotiation or cache-exchange overhead, and for cases where what is actually wanted is one jointly trained model — that is federated learning's job, not this one.

The cheapest first experiment is narrower than a full protocol rollout: pick two of the existing models, write a small typed schema for the one signal they need to exchange — say, a routing confidence score — and measure routing accuracy against simply calling both models every time. If the typed exchange matches that baseline within a few points, as SYNAPSE's authors measured on GSM8k, the approach is earning its keep.

Say it in the room

"Use it when several vendor-owned models already exist and must cooperate without merging; skip it when one model already does the job or when the coordination overhead costs more than the specialist accuracy it buys."

Lines to carry

  • "Cooperate without merging."
  • "Small typed notes travel faster than full diaries."
  • "Trust, but verify the metadata."
  • "Not every query needs every model."
  • "A guarantee that fails on one dataset was never a law of nature."
  • "Routing is only as good as what was advertised."

FAQ

Is this the same as federated learning?

No. Federated learning trains one shared model across distributed data without centralising that data. Model protocol federation coordinates several already-trained, independent models at the point a query arrives, often without any joint training step at all.

Does exchanging typed artifacts mean the models see each other's training data?

No. The artifacts described in the dossier carry capability metadata, routing signals, and numeric statistics — not raw training data or full weights. SYNAPSE's artifacts, for instance, carry a formal differential-privacy bound on their numeric fields specifically because they are not meant to expose the data behind them.

Why not just call every model and pick the best answer?

You can, and some systems do, but it costs more in latency and compute than it needs to. SkyLLM's whole premise is that federating calls across multiple APIs selectively costs less and performs better than invoking a fixed model set for every query.

What happens if two models disagree during negotiation?

Decentralised negotiation protocols like M2M-NP let each side validate proposals against its own local policy rather than deferring to a central approver, which avoids a single point of failure but can take longer to reach agreement when many parties disagree at once.

Can these guarantees be trusted across every dataset?

Not automatically. SYNAPSE's own authors found their routing-stability guarantee failed on a LiveBench subset, with the measured value exceeding the required bound. Formal guarantees need re-checking against the actual data a system will face.

Glossary

  • Model federation — separately trained, often differently owned models coordinating and exchanging information without merging into a single model or sharing raw training data.
  • Federated learning — a training technique where many devices or organisations jointly train one shared model without sending raw data to a central server.
  • API-level / text-level / logit-level / weight-level collaboration — a taxonomy for how deeply models interact, from simply calling each other's APIs up to sharing or merging parameters.
  • Token-to-token (T2T) communication — models exchanging information as generated text tokens, simple but often slow.
  • Cache-to-cache (C2C) communication — models exchanging internal key-value cache states directly instead of regenerated text, to cut latency.
  • Typed federated artifact — a small, schema-validated data object with defined fields, used so privacy and merging rules can apply per field.
  • Differential privacy (DP) — a mathematical guarantee limiting how much can be inferred about any one individual's data from shared aggregate outputs.
  • Secure aggregation — a cryptographic protocol letting a server combine many participants' updates without seeing any individual raw update.
  • Policy-as-code — writing security and operational rules as machine-readable code so they can be automatically checked.
  • Negotiation agent — a software component attached to a model that advertises capabilities, proposes terms, and evaluates incoming proposals.
  • Routing accuracy — how often a system correctly selects the most suitable model or tool for a given query.
  • Contraction premise — a theoretical assumption that repeated operations shrink a measured quantity over time; if the measured value exceeds the required bound, the assumption fails.

Sources

  1. When One LLM Drools, Multi-LLM Collaboration Rules — ACL Anthology, 2026
  2. Cache-to-Cache communication for LLM collaboration — arXiv, 2026
  3. Learning to Collaborate: An Orchestrated-Decentralized Framework for Peer-to-Peer LLM Federation — Proceedings of the AAAI Conference on Artificial Intelligence
  4. Model-to-Model Negotiation Protocols in Secure Cloud Environments — TechRxiv, 2026
  5. SYNAPSE: Federated Tool Routing via Typed Compendium Artifacts — arXiv, 2026
  6. SkyLLM: Cross-LLM-APIs Federation for Cost-effective Query Processing — ACL Anthology (Findings), 2025
  7. Janus: Dual-Server Multi-Round Secure Aggregation with Verifiability for Federated Learning — Proceedings of Machine Learning Research, 2025

Newsletter

Get DM Explains in your inbox.

One explainer per edition, taken apart properly: how it works, where it breaks, and whether you should use it. A confirmation link first, then nothing until there is something worth sending.

About the newsletter → · Subscribe by RSS

You’ll get a confirmation link first. One email per edition, no drip, no list-share. Unsubscribe in one click.