A2A Federation: How Two Networks Of Agents Bridge Without Becoming One Network

TL;DR

Two agent networks that need to cooperate face a choice: merge into one network and accept the governance and operational consequences, or stay separate and lose the ability to interact. The third option is federation, which lets each network keep its own governance and trust regime while exchanging signed claims about its agents through a bridge. The bridge translates trust signals across regimes and mediates A2A calls. This post is the spec for that bridge: what it does, what it cannot do, and how to build one without violating the trust models on either side.

The Failure Mode That Forces Federation

A logistics consortium runs an internal agent network. Each member airline registers its scheduling agents in a private trust registry, runs them under shared pacts, and has spent two years building governance around the registry. A second consortium of freight forwarders runs its own network with its own registry, its own pacts, and its own governance. A high-value contract requires a freight forwarder agent to query a scheduling agent and book capacity. The two agents are in different networks. Neither registry recognizes the other. Neither network's pacts apply to the counterparty.

The naive solution is to merge the registries. This fails for the obvious reason: the airlines and the forwarders have different governance models, different score formulas, different pact templates, and different operational priorities. Merging means renegotiating all of that, which neither side will do for one contract.

The second naive solution is to give up and use a human in the middle. The forwarder calls the airline by email, the airline updates the schedule manually, and the entire promise of A2A is wasted. This is what most cross-organizational agent interactions look like today, which is why most cross-organizational agent interactions are not actually agent interactions.

The third option is federation. Each network keeps its own registry, its own pacts, and its own governance. A bridge agent on each side translates trust signals from its network's regime into a portable form that the other side can verify. The bridge mediates A2A calls between the networks: the forwarder talks to its bridge, the bridge talks to the other bridge, the other bridge talks to the airline. Each leg of this chain is governed by its own regime, but the chain as a whole carries enough signed evidence that both sides can audit it later if something goes wrong.

Federation is the right pattern, but it has subtleties. Done badly, it is a backdoor that lets untrusted agents into a trusted network under the guise of being a federated peer. Done well, it preserves the trust model on each side while enabling cross-network interaction. The difference is in the spec, which is what this post lays out.

The spec is the named artifact: the Federation Bridge Spec. It defines the bridge agent's role, the format of cross-network claims, the protocol for claim exchange, the dispute resolution path, and the failure modes that operators need to handle. It is opinionated enough to implement and general enough to apply to most A2A federation scenarios.

What A Bridge Agent Is And Is Not

A bridge agent is a specialized agent that acts as a translator and gateway between two networks. It is registered in both networks, holds trust attestations from both, and is governed by pacts in both. It is not a router; it does not blindly forward calls. It is not a proxy; it does not impersonate either side. It is a translator that mediates calls and carries signed evidence about what each side did.

The bridge agent has three primary responsibilities. The first is identity translation. When a foreign agent's identity needs to be presented to a local agent, the bridge attests that the foreign agent is registered in its home network and carries a specific trust posture. The local agent does not need to trust the foreign network's trust system; it trusts the bridge's attestation, which is signed by the bridge and verifiable in the local network.

The second responsibility is policy translation. When a foreign agent's pacts need to be presented to a local agent, the bridge translates the foreign pacts into the local network's pact vocabulary. The translation is lossy: foreign pact terms that do not have local equivalents are flagged and surfaced to the operator. Foreign pacts that do not satisfy the local network's minimum requirements are rejected; the call does not proceed.

The third responsibility is evidence collection. Every call mediated by the bridge produces a signed transcript: the foreign agent's request, the bridge's translation of the request, the local agent's response, the bridge's translation back, and the timestamps of each step. The transcript is signed by the bridge and stored on both sides for auditability. If a dispute arises, both sides can produce the transcript and reconstruct what happened.

What the bridge does not do is more important than what it does. It does not import the foreign agent's identity into the local registry. The foreign agent stays foreign; the local network never accepts it as a local agent. It does not import the foreign agent's score. The local network has its own composite score, and any judgments about the foreign agent are made by the local network based on the bridge's attestations, not by trusting the foreign network's score directly. It does not allow the foreign agent to take actions that require local pact compliance, unless the foreign agent has accepted equivalent pacts in its home network.

The bridge's role is intentionally narrow because every expansion of the role expands the trust assumption. A bridge that translates is a trust-bearing element, but a small one. A bridge that imports identities is a much larger trust-bearing element, and the failure modes scale with the size of the trust assumption. Keep the bridge narrow.

The Federation Bridge Spec

Here is the named artifact. The spec has six parts: identity attestation, capability attestation, call mediation, evidence transcript, dispute path, and failure modes.

1. Identity Attestation

A bridge agent is registered in both networks under separate DIDs. When a foreign agent needs to be presented to a local agent, the bridge produces an identity attestation: a signed statement that the foreign agent is registered in the foreign network with a specific DID, certification tier, composite score, and certification date. The attestation includes the foreign network's identifier so the local agent can apply network-specific policies (for example, preferring agents from networks with stricter governance for high-stakes calls).

The attestation has a freshness window. The bridge regenerates it periodically (every 5-15 minutes for active counterparties, longer for idle ones) and pushes invalidations when the foreign agent's status changes. Local agents that consume the attestation must check the freshness and reject stale attestations.

2. Capability Attestation

Alongside the identity attestation, the bridge produces a capability attestation: a signed statement that the foreign agent's active pacts in the foreign network include specific capabilities, expressed in a translation that the local network understands. The translation is performed by a translation table that the two networks have agreed on; capabilities that do not appear in the translation table cannot be exercised across the federation.

The capability attestation also includes any policy gaps: foreign capabilities that have no local equivalent, local capabilities that the foreign agent has not been granted, and any caveats specific to the foreign network's governance (for example, that the foreign network does not enforce on-chain settlement). The local agent can use these gaps to decide whether to proceed with the call.

3. Call Mediation

When a foreign agent calls a local agent, the call goes through both bridges. The foreign agent calls its home bridge with the request and the local agent's address. The home bridge calls the local bridge with the request, the foreign agent's identity attestation, and the foreign agent's capability attestation. The local bridge verifies the attestations, translates the request into the local pact vocabulary, and calls the local agent with the translated request and a local-form attestation about the foreign agent.

The local agent responds to the local bridge. The local bridge translates the response back into the foreign agent's expected format and returns it to the home bridge. The home bridge returns the response to the foreign agent. Each leg is signed by the agent or bridge that produced it; each leg is verified by the next agent or bridge that consumes it.

4. Evidence Transcript

Every call produces a transcript: the original request from the foreign agent, the home bridge's signed forwarding to the local bridge, the local bridge's signed translation to the local agent, the local agent's signed response, the local bridge's signed translation back, the home bridge's signed return to the foreign agent. The transcript is stored on both sides and is the canonical record of the call.

The transcript format is JSON Lines, with each line a signed envelope containing the actor, the timestamp, the operation, the payload hash, and the signature. The full payloads are stored separately and referenced by hash. Storing only hashes in the transcript reduces storage cost and makes the transcript itself small enough to query and replay.

5. Dispute Path

If a dispute arises (the foreign agent claims the local agent did not honor the request, or the local agent claims the foreign agent's request was malformed), both sides produce their copy of the transcript. The transcripts should match by content; if they do not, one of the bridges is misbehaving. The dispute is resolved by comparing the transcripts and the signed envelopes, with the bridge's signatures providing non-repudiable evidence of who said what when.

If the dispute escalates, both networks have the option to refer the bridge's behavior to their respective governance processes. A bridge that consistently produces transcripts that do not match its peer's transcripts loses its registration and is replaced. A bridge that loses too many disputes has its trust score lowered and may be removed from the federation by either network.

6. Failure Modes

The bridge can fail in several ways. The home bridge can be unreachable, in which case the foreign agent cannot make calls until it is restored. The local bridge can be unreachable, in which case calls fail with a clear error and the foreign agent can retry. The translation table can be incomplete, in which case calls that require missing translations are rejected at the bridge. The attestations can be expired, in which case the receiving bridge requests a fresh attestation before proceeding.

Each failure mode has a defined response in the spec, so operators can implement consistent handling. The bridge should never silently fall back to a less safe path. If the spec cannot be honored, the call fails.

The spec is intentionally conservative. It rejects calls that cannot be fully attested rather than allowing them with caveats. The cost of this conservatism is that some calls will fail that could have succeeded with looser semantics. The benefit is that every call that succeeds is fully auditable and the trust assumptions are explicit on both sides.

Translation Tables: Where Federations Succeed Or Fail

The spec above hinges on the translation table that the two networks agree on. The table maps capabilities, pact terms, and trust signals between the two networks. Building a good translation table is the hardest part of setting up a federation, and it is where most federation efforts stall.

The table has three parts. The first is capability mapping: foreign capability X corresponds to local capability Y. Some mappings are direct (book-flight in the airline network maps to book-flight in the freight network). Some are partial (search-availability in the airline network has more parameters than search-capacity in the freight network; the unsupported parameters are dropped or flagged). Some have no mapping (the airline network's manage-loyalty-program has no freight equivalent; calls requesting it fail).

The second part is pact term mapping: foreign pact terms map to local pact terms. This is harder because pacts are richer than capabilities. A foreign pact that requires 24-hour notice for cancellation maps to the local equivalent if there is one; if there is no local equivalent, the federation either omits the term (and the foreign agent's protections are weaker on the local side) or rejects the federation for that pact.

The third part is trust signal mapping: foreign trust signals (composite score, certification tier) map to local equivalents. This is the loosest mapping because the two networks may use different scoring formulas. The convention is to map by certification tier (foreign Tier 1 to local Tier 1) and to disclose the underlying score for transparency. Local agents can apply their own thresholds to the disclosed score; the certification tier is a coarse summary that helps with quick decisions.

Building the table requires both networks to be honest about what they enforce and what they do not. A network that claims its pacts cover something they actually do not should not have that claim accepted in the translation table. The translation table is therefore also a forcing function for honesty: networks that want to federate have to clarify their own enforcement.

The table evolves over time. As capabilities and pact terms change in either network, the table needs to be updated. The convention is to version the table and to require both networks to ratify each version before it goes live. Old versions are kept for transcript verification; new versions apply to new calls.

A federation with a well-maintained translation table is an asset that grows in value over time. Calls work, disputes are rare, and the operational cost of the federation is low. A federation with a stale table accumulates edge cases, fails calls that should succeed, and erodes confidence on both sides. The translation table is not a one-time setup; it is a maintained artifact.

Why The Bridge Cannot Just Be A Proxy

A tempting simplification is to make the bridge a transparent proxy: the foreign agent's call is forwarded as-is, the local agent responds as if to a local peer, and the bridge does not interpret or translate. This is wrong, and the reasons are worth being explicit about.

The first reason is that the foreign agent does not satisfy local pacts. The local agent's pact compliance check expects a counterparty that has accepted local pacts. The foreign agent has not. If the bridge proxies transparently, the local agent either fails the pact check (and the call is rejected for the wrong reason) or has its pact check disabled (and the local network's pact regime is undermined). Translation is required to map the foreign agent's pact compliance into something the local check understands.

The second reason is that trust signals are not portable. The foreign agent's composite score is computed against the foreign network's formula, which weights dimensions differently from the local formula. Forwarding the score directly would give the local agent misleading information. The translation expresses the foreign trust posture in local terms (Tier 1, Tier 2, Tier 3) plus the underlying disclosure, so the local agent can make a calibrated decision.

The third reason is that disputes need both networks' cooperation. If the bridge is a transparent proxy, a dispute can only be resolved by appealing to the foreign network's governance. The local network has no leverage. A bridge that translates and signs creates a record that both networks can act on, because both networks can verify the bridge's signature and the bridge is registered in both.

The fourth reason is that auditability requires evidence. A transparent proxy leaves no evidence beyond the underlying request and response. A bridge that mediates produces an evidence transcript: who said what to whom in what order, signed at every step. The transcript is the basis for forensics, dispute resolution, and post-incident review. Without it, federation is a black box.

The transparent-proxy pattern is appealing because it requires less code. It is also a recipe for operational chaos. The translating bridge is more work upfront but pays for itself the first time a federated call goes wrong, which it will.

How To Bootstrap A Federation

Federations do not start with two networks deciding to federate. They start with one cross-network use case that needs to work, plus the willingness on both sides to invest in the protocol. The bootstrap path has a predictable shape.

Step one is identifying the use case and the agents involved. Concrete is better than abstract: a single call type that needs to work, with named agents on both sides, is enough to start. The use case defines the minimum capability mapping that the translation table needs.

Step two is provisioning bridges on both sides. Each network registers a bridge agent in its registry, governed by pacts that constrain the bridge's behavior. The bridges are provisioned with the keys to sign attestations and with access to their networks' trust oracles. The bridges are not yet federated; they are just registered.

Step three is the translation table. The two networks agree on the mapping for the initial use case: capabilities, pact terms, and trust signals. The table is signed by both bridges and distributed to both networks. The table starts narrow and grows as more use cases are added.

Step four is the first federated call. A foreign agent makes a call that requires the federation. The bridges mediate. The transcript is produced and stored. Both sides review the transcript and confirm it matches their expectations. If it does, the federation is operational for this use case.

Step five is operationalization. The bridges are monitored. Calls are tracked. Disputes are reviewed. The translation table is extended as additional use cases come online. The pacts governing the bridges are tuned based on observed behavior. After some time, the federation has a track record, and the trust between the two networks deepens.

The bootstrap is the hard part because it requires alignment between two organizations that have different priorities. The thing that makes it tractable is starting small. Federations that try to map all capabilities upfront stall in negotiations. Federations that map one capability and ship usually find that the next capability is easier, because the protocol is in place and the translation table just needs to be extended.

Multilateral Federations: When Three Or More Networks Need To Cooperate

The spec above describes bilateral federation: two networks, two bridges, one translation table. Real-world A2A often involves more than two networks, and the spec generalizes but with subtleties.

In a multilateral federation, each pair of networks has a bridge pair and a translation table. With N networks, there are N*(N-1)/2 bridge pairs and translation tables. This is workable for small N (3-5 networks) and quickly becomes unmanageable for large N. At scale, the alternative is a hub-and-spoke topology: each network has a bridge to a central federation hub, and the hub maintains the translation tables. The hub is itself a network, registered in each of the spokes, with its own governance.

The hub pattern reduces the N-squared problem to N translation tables but introduces a single point of trust: the hub. The hub's governance becomes the implicit shared standard. Networks that trust the hub get easy multilateral federation; networks that do not trust the hub stay bilateral.

Both patterns coexist in real federations. Closely allied networks federate bilaterally; loosely allied networks federate via a shared hub. The choice depends on the strength of the trust relationship and the volume of cross-network calls.

Multilateral federations also have a path-length problem. A call from agent A in network 1 to agent B in network 3 might pass through a bridge to network 2 if there is no direct federation between 1 and 3. Each hop adds latency, attestation work, and translation. Operators usually cap the path length at two hops; longer paths are either disallowed or routed through a hub.

The transcripts in multilateral federations are correspondingly longer. Each hop adds to the evidence trail. The hops are signed independently, so the transcript can be verified leg by leg. This is more storage and more verification work, but it is also more auditability: a multilateral call has more checkpoints, which is helpful when disputes span multiple networks.

Counter-Argument: Just Use A Single Global Network

The alternative to federation is a single global network that everyone joins. The argument is that federation is a transition state, and the long-run equilibrium is one network with shared governance, shared trust signals, and a single registry. Federation is bridge-building between islands; the eventual outcome is one continent.

This argument is wrong on two grounds. The first is empirical: every networking transition that promised eventual unification has produced federation instead. Email is federated. The web is federated. Telephony is federated. The internet itself is federated. The technical pressure toward unification keeps producing federation as the resilient endpoint, because federation respects the operational, regulatory, and governance autonomy of the constituent networks.

The second is structural: agent networks are tied to organizational boundaries that are not going away. Airlines and freight forwarders have different regulators, different liability regimes, and different operational priorities. They cooperate through federation because they cannot merge. The same is true for healthcare networks and insurance networks, for financial networks and supply networks, for any pair of industries that need to interact but cannot legally or practically combine.

Federation is therefore not a transitional state. It is the steady state. The investment in federation protocols, translation tables, and bridge agents is not throwaway work that gets retired when everyone joins one network. It is the permanent infrastructure of cross-organizational A2A.

The one place the unification argument has merit is within a single organization that has multiple agent networks for historical reasons. There, consolidation is tractable and federation is overhead. The signal that you have an internal-network problem rather than a federation problem is that the two networks have the same governance, the same operator, and no regulatory or legal reason to stay separate. In that case, merge them. In every other case, federate.

Pricing And Liability In Federations

Federations do not just exchange technical signals. They also exchange economic flows: federated calls produce value for both sides, and that value has to be priced. The pricing model is part of the federation, even if it is not part of the spec.

The simplest pricing model is per-call settlement. The foreign agent pays the local agent for the call, with the bridges optionally taking a fee. The settlement happens on-chain (the spec assumes USDC on Base L2 or equivalent), with the call's evidence transcript serving as the basis for the invoice. If the foreign agent does not pay, the local agent escalates through the federation's dispute path.

A more complex model is subscription. Networks negotiate a subscription that covers some volume of cross-network calls; the bridges enforce the subscription terms and meter the usage. Overage is billed at a per-call rate. This model reduces the per-call settlement cost and is appropriate when the call volume is high and predictable.

Liability is the harder question. When a federated call produces a bad outcome, who is liable? The foreign agent that requested the work? The local agent that performed it? The bridge that mediated? The networks that hosted the bridges?

The convention is that liability flows along the trust chain: the local agent is liable to the local bridge for honoring the call; the local bridge is liable to the home bridge for accurate translation; the home bridge is liable to the foreign agent for accurate forwarding. Each link in the chain has its own contract, and disputes are resolved at the appropriate link. This avoids the impossible task of inter-network liability and keeps each network's governance in charge of its own disputes.

The transcripts are the evidence that makes this liability flow possible. Without them, every dispute becomes a he-said-she-said. With them, the liability question is usually answered by reading the transcript: the misbehavior is identifiable, the responsible party is signed onto the action, and the resolution follows the chain.

What Armalo Does

Armalo's trust oracle and pact protocol are designed with federation in mind. The composite score is published in a canonical form that other networks can verify, and the certification tiers are intentionally coarse so they translate cleanly across networks with different scoring formulas. Pacts are structured artifacts with versioned terms, which makes building translation tables tractable.

The trust oracle (/api/v1/trust/) supports cross-network attestation queries: a bridge in another network can query Armalo's oracle to verify that an Armalo-registered agent has the claimed score and pacts, with the response signed by Armalo's oracle. This signed-response semantics is what makes Armalo agents portable into federations: foreign bridges can verify Armalo attestations without trusting any party other than the oracle's signing key.

The multi-LLM jury that produces score updates trims the top and bottom 20 percent of judgments before averaging, which means the score is robust to adversarial juries; foreign networks consuming the score can rely on it without independently re-running the evaluations.

Armalo does not ship a bridge agent reference implementation, but it ships the primitives that make building one straightforward: signed attestations, versioned pacts, on-chain settlement, and dispute escalation through pact compliance.

FAQ

Q: How do I prevent a foreign agent from causing damage in my network? The local pact compliance check is the gate. The bridge translates the foreign agent's capabilities into local terms; the local agent's pact check confirms the request fits within those capabilities. Rate limits and behavioral monitoring apply to foreign agents the same way they apply to local agents. If a foreign agent misbehaves, the local network can revoke its federation access.

Q: What if the foreign network has weaker governance than mine? Reflect that in the trust signal mapping. A foreign agent from a weaker network gets a lower local trust tier than its foreign tier would suggest. The translation table can encode network-specific discounts, so calls from weak-governance networks face higher verification thresholds.

Q: Can I federate with a network that does not support pacts? Not meaningfully. Pacts are the substrate that makes federation auditable. A network without pacts can be a consumer of your network (its agents call yours under your pacts) but cannot be a peer in federation (your agents calling its agents have no governance to rely on).

Q: How big should a translation table be at launch? As small as possible. Three to five capabilities, the corresponding pact terms, and the trust tier mapping. Adding more is easy; removing capabilities once they are in production is hard.

Q: What if the bridges disagree about a transcript? You have a serious problem. The bridges should produce identical transcripts for any given call; disagreement means one of them is misbehaving or compromised. The dispute escalates to both networks' governance, and the misbehaving bridge's federation participation is suspended.

Q: How do I handle key rotation across the federation? The bridges publish key rotation events to each other through the federation channel. The new key is signed by the old key (or by an out-of-band trust anchor), so the receiving side can trust the rotation. Active sessions continue using the old key until they end; new sessions use the new key.

Q: Can a bridge handle multiple foreign networks? Yes, and at scale it usually does. A bridge in network X can be configured to mediate calls to networks Y, Z, and W, with separate translation tables for each peer. This is the multilateral pattern.

Bottom Line

Federation is how agent networks cooperate without merging. It is the steady state, not the transition. The bridge agent is the central piece, and the bridge's job is translation, not proxying. The translation table is the artifact that captures what the federation actually means in operational terms. The transcripts are the evidence that makes disputes resolvable. Done well, federation lets two networks with different governance regimes interact reliably, with clear liability and clear audit trails. Done badly, it is a backdoor that lets untrusted agents into trusted networks. The spec in this post is the difference between the two.