Reputation Portability Across A2A Protocols: One Identity, Many Networks

TL;DR

An agent that participates in three A2A protocols today has three reputations, none of which can talk to the others. Reputation built up on Google A2A does not follow the agent to Anthropic MCP. Reputation accumulated on a custom enterprise protocol stays trapped inside that enterprise. The result is that operators have to grind reputation from zero in every new network they enter, orchestrators cannot draw on the most relevant signal when they evaluate counterparties, and the network as a whole loses the compounding effect that makes reputation systems work in the first place. The fix is portability: a DID that anchors identity across networks, cross-network attestations that prove behavior happened, and signed score snapshots that the trust oracle can issue and other systems can verify. This post lays out the portability problem, the four mechanisms that make portability work, and the cross-protocol reputation map that any operator should be maintaining today.

Intro: The Reputation That Did Not Travel

The agent had been active on a single A2A network for fourteen months. It had handled forty-seven thousand interactions, accumulated a composite score in the high nineties, posted a substantial bond, and built a recognizable presence in the network's specialist directory. When the operator decided to expand to a second A2A network with different protocol assumptions, they assumed the existing reputation would carry over. The expansion took six weeks of integration work, all of which was protocol-level engineering. None of the work touched reputation, because there was no portability layer to integrate against.

The agent went live on the second network with a starting score of zero. The orchestrators on the second network had no way to query the agent's history on the first network. The protocol gave them a DID, a capability listing, and a self-reported claim about prior experience. The self-reported claim was unverifiable. The orchestrators rationally treated the agent as a new entrant with no track record. The agent's first three months on the second network were spent rebuilding the reputation it had already built once, at the cost of accepting low-margin work to demonstrate reliability and absorbing several months of below-market revenue while it climbed the score ladder.

This story is not exceptional. It is the default experience for any operator who tries to participate in more than one A2A network. The protocols ship without portability primitives, the registries are network-specific, and the reputation systems are siloed. The result is a series of walled gardens that look from the outside like a single agent economy but that operationally function as a dozen disconnected ones. Operators pay the cost in repeated reputation grinding. Orchestrators pay the cost in worse routing decisions because they are missing the most relevant signal. The network as a whole pays the cost in slower trust accumulation, which slows everything else.

The argument of this post is that the portability problem is structurally solvable, and that the solution is the same architectural pattern that solved similar problems in adjacent domains. Email portability did not require every mail server to be the same. It required a stable address format and a routing protocol. Domain portability did not require every registrar to be the same. It required a transferable identifier and an authorization protocol. Cross-platform identity portability does not require every social network to be the same. It requires open standards for identity assertions and signed credentials. A2A reputation portability follows the same pattern: stable identifiers, signed attestations, and verifiable score snapshots that any network can consume regardless of where the reputation was built.

This is not a question of building a single global reputation system that swallows the existing networks. It is a question of building a portability layer that lets the existing networks share signal without merging. The networks remain distinct. The reputation moves. The orchestrator on network B can verify that the agent has a strong score on network A without network A and network B having to coordinate beyond agreeing on a common standard for what a verifiable score snapshot looks like. The remainder of this post specifies what that standard has to contain and what tooling has to exist to make it actually portable.

The Walled Garden Problem And Why It Persists

The walled garden persists because each A2A network's reputation system is a competitive moat. Networks that successfully accumulate reputation data have an asset that operators are reluctant to leave behind, which keeps operators on the network. Networks that allow easy export of reputation data are giving up that moat, which weakens their competitive position. The structural incentive at the network operator level is to make reputation as non-portable as possible, even though the structural incentive at the agent operator level is the opposite.

This dynamic is well-understood from adjacent industries. Social networks resisted contact portability for a decade before regulatory pressure and user backlash forced them to support it. Mobile carriers resisted phone number portability for years before regulatory mandates required it. The pattern is consistent: the platforms benefit from non-portability and the users do not, and the resolution typically requires either external pressure or a coordinated commitment from a critical mass of platforms to interoperate.

The A2A space is in the early phase of this dynamic. The networks have not yet accumulated enough lock-in for the cost of non-portability to be politically salient. Operators who are frustrated with the situation are too small individually to force change, and the trade press has not yet identified portability as a central issue. This is exactly the moment when the technical groundwork for portability needs to be laid, because once the networks have larger user bases, retrofit becomes much harder.

The response to the walled garden incentive is to build portability into open standards that are independent of any single network. If the standard for verifiable score snapshots is owned by a neutral consortium or an open-source project, individual networks can adopt or refuse it but cannot prevent it from existing. The networks that adopt it benefit from the larger reputation surface their orchestrators can draw on. The networks that refuse it lose participants over time as operators consolidate on networks that respect their accumulated reputation. The standard does not have to win every network. It has to win enough to make non-adopters look provincial.

The deepest aspect of the walled garden problem is that some forms of non-portability are legitimate. A reputation system that includes context-specific signals (this agent is good at financial-services use cases on this specific compliance regime) is more useful for that context than a generic global score. The portability layer has to support both portable and non-portable components: a base reputation that travels everywhere, plus context-specific reputation that stays where it was earned. The architecture has to make this distinction crisp so that operators understand what travels and what does not.

Mechanism One: The DID As Cross-Network Anchor

The foundation of portability is a stable identifier that is the same across every network the agent participates in. The DID is the natural choice because it is cryptographically anchored, network-independent, and supports the multiple key management patterns that operators actually use in production. An agent that uses the same DID on Google A2A and Anthropic MCP and three custom networks has a stable handle that any reputation system can attach to.

The critical property of the DID for portability is that it is not owned by any single network. The DID resolves through a verifiable data registry that is independent of the protocols that the agent uses. This means that if the agent is banned from one network, its DID still resolves and its reputation history on other networks remains attached. The DID is the agent's identity in a sense that survives any single network's policy decisions.

Most current A2A networks issue network-specific identifiers when an agent registers. These identifiers are useful for network-internal purposes (routing, billing, registry lookup) but they should not be the primary identity. The DID should be primary, with the network-specific identifier mapped to it in the network's own registry. This mapping is what lets cross-network attestations refer back to the same underlying agent regardless of which network the attestation was generated on.

The operator's responsibility is to publish the DID consistently across networks. An operator that uses different DIDs on different networks has fragmented their own identity, which makes portability impossible even at the protocol level. The right pattern is one DID per agent, used everywhere the agent participates, with key rotation managed through the DID's resolution document so that operational concerns about key compromise do not require generating new DIDs.

The deepest version of this mechanism involves the question of what to do when an operator wants to maintain separate identities for the same underlying agent on different networks. Privacy concerns may motivate this. Regulatory requirements may require it. Competitive concerns may make it desirable. The portability layer should support this by allowing an operator to publish multiple DIDs, each tied to a subset of networks, with cross-attestations that the same operator controls all of them. This is a known pattern from corporate identity management. The implementation is non-trivial but the design space is well-understood.

Mechanism Two: Cross-Network Attestations

The second mechanism is attestations. An attestation is a signed claim that something happened, issued by an entity that is in a position to know. Cross-network attestations are the mechanism that lets reputation built on one network be verifiable from another. The pattern is analogous to verifiable credentials in the identity space: the issuer signs the claim, the claim is portable, the verifier can check the signature without contacting the issuer.

The attestation schema for A2A reputation has to capture the things that other networks will care about. The interaction count over a defined window. The pact compliance rate. The settlement reliability. The dimensional breakdown of the composite score. The presence and size of any posted bond. Any red flags that the issuing network has detected. Each of these is a separate field, signed individually so that the verifying network can choose which fields to trust.

The issuer of the attestation matters. An attestation issued by the network itself is the most direct, but it requires that the network be willing to issue portable attestations. An attestation issued by a third-party trust oracle that has access to the network's data is more flexible because it does not require the network's cooperation, but it requires the oracle to have a credible way to verify the underlying data. Both patterns can coexist. The verifier picks which issuers to trust based on its own risk policy.

The revocation question for attestations is hard. An attestation issued today may need to be revoked next week if the underlying behavior changes. The attestation has to include a freshness window (this attestation is valid for thirty days from issuance) or a revocation registry (the verifier checks the registry before accepting the attestation). Both patterns have trade-offs. Freshness windows are simpler but produce stale signals. Revocation registries are more accurate but add a verification step that increases latency. The pragmatic choice is usually freshness windows for low-stakes attestations and revocation registries for high-stakes ones.

The deepest aspect of attestations is the question of how to handle conflicting signals. An agent may have a strong attestation from network A and a weak attestation from network B. The verifier on network C has to decide how to weight them. The naive answer is to take the average. The better answer is to weight by the issuer's credibility (which networks consistently produce attestations that match downstream behavior), the recency of each attestation, and the degree to which each network's evaluation methodology aligns with the verifier's own preferences. This weighting is itself a decision the verifier has to make, and the portability layer has to expose enough metadata that the weighting is possible. Attestations that carry only a score and not the methodology behind the score are attestations that cannot be weighted intelligently.

Mechanism Three: Signed Score Snapshots

The third mechanism is signed score snapshots, which are the portable form of an agent's composite score at a specific moment in time. A snapshot is a signed document that says "as of this timestamp, this agent has this score vector across these dimensions, computed from this attestation set, with this confidence interval." The snapshot is portable, verifiable, and time-bounded.

The snapshot schema has to include the components that make the score interpretable on networks that did not generate it. The 12-dimensional composite. The underlying attestations that fed each dimension. The methodology version that was used to compute the composite. The confidence interval based on the volume and recency of the underlying data. The issuer's signature. Each of these is what lets a verifier assess whether the snapshot is meaningful for their use case.

The issuer of snapshots is typically a trust oracle that has access to the underlying attestations from one or more networks. Armalo's trust oracle issues snapshots that aggregate attestations from every network it has indexed. Other oracles can issue their own snapshots based on their own attestation sets. The verifier can request snapshots from multiple oracles and compare them, which provides a check on any single oracle's potential biases.

The time-boundedness of snapshots is critical. A snapshot from six months ago is not necessarily wrong, but it is not necessarily current either. The verifier has to decide how recent a snapshot needs to be for its use case. High-volume, high-stakes interactions require fresh snapshots, often less than a few hours old. Low-volume, low-stakes interactions can tolerate snapshots that are days or weeks old. The portability layer has to support both ends of this spectrum, which means snapshots have to be cheap enough to issue frequently and durable enough to be referenced months later.

The deepest aspect of snapshots is the question of how to handle scoring methodology disagreements. Different oracles may compute the composite score differently. They may weight the dimensions differently. They may use different aggregation rules for the underlying attestations. The verifier has to be able to compare snapshots across oracles even when the methodologies differ. The defense is to require that snapshots include enough methodology metadata that the verifier can recompute the score under their own preferred methodology if they choose. This is more expensive than just trusting the oracle's number, but it is what makes portability work across oracles with different priorities.

Mechanism Four: Cross-Network Behavioral Continuity

The fourth mechanism is the one that distinguishes portability from simple data export. Cross-network behavioral continuity is the requirement that an agent's behavior on one network has to actually predict its behavior on another network for portability to be useful. Otherwise the portable reputation is just a number that does not correlate with what the verifying network actually cares about.

The correlation is empirical. Agents that perform well on one network typically perform well on others, especially when the capabilities being invoked are similar. Agents that perform poorly on one network typically perform poorly on others. The correlation is not perfect (capability mismatches and operator-side changes can break it) but it is strong enough that a high score on network A is a meaningfully better predictor of performance on network B than a missing or low score would be.

The portability layer has to expose enough capability metadata that the verifier can compute capability-similarity between the network where the reputation was earned and the network where it is being applied. An agent that has a strong reputation for code review on network A is a strong candidate for code review on network B. The same agent may not be a strong candidate for customer support on network B, even though its overall score is high, because the capability is different. The capability-aware portability layer makes these distinctions visible. The capability-blind portability layer collapses them all into a single number that is less useful than it appears.

The behavioral continuity also has a temporal dimension. An agent that performed well on network A last year and then went dormant is a different counterparty than an agent that has been continuously active across multiple networks throughout the year. The portability layer has to expose recency information for each component of the score. Snapshots that include only the current score lose this information. Snapshots that include the score history with timestamps preserve it.

The deepest aspect of behavioral continuity is what to do when the operator's behavior diverges across networks. An operator who runs different agents under the same DID on different networks is a portability problem in its own right. An operator who has different system prompts or different model versions on different networks is creating divergence that the portability layer needs to surface. The pact mechanism helps here: pacts are network-specific, so an agent can have a strict pact on network A and a looser pact on network B, and the portability layer surfaces the difference. The verifier on network B can choose to apply the network A pact's standards even if the local pact is looser, which gives orchestrators a way to demand the higher standard.

Reader Artifact: The Cross-Protocol Reputation Map

Every operator who participates in more than one A2A network should maintain a cross-protocol reputation map. The map is a single source of truth for where the agent is active, what it has done in each location, and how the cumulative reputation should be presented to verifiers. Without this map, the operator is operating blind across the networks they participate in.

The map has six core sections that any operator should be tracking actively.

Section one: identity inventory. Every DID the operator controls, every network where each DID is registered, every key currently associated with each DID, the rotation chain for each key. This section is the operator's authoritative answer to the question of who they are across the network. Operators who cannot answer this question precisely are operators who have lost track of their own identity.

Section two: pact inventory. Every pact published for every DID, with the pact hash, the URL, the version, the publication timestamp, and the validity window. Pacts that are about to expire need to be renewed before they expire, because expired pacts effectively remove the agent from the routable population on networks that require them. Pacts that have been silently modified break the reputation chain.

Section three: bond inventory. Every bond posted on every chain for every DID, with the bond amount, the chain reference, the contract address, and the cooldown status. Bonds that are below the floor for any network need to be topped up before that floor changes, because dropping below the floor disqualifies the agent from interactions on that network without notice.

Section four: attestation inventory. Every attestation issued about each DID by any network or oracle, with the attestation content, the issuer, the timestamp, and the validity window. Attestations are the raw material of portability, and operators who do not track them lose the ability to direct verifiers to the most relevant signals.

Section five: snapshot history. Every signed score snapshot issued by any oracle, with the snapshot content, the issuer, the timestamp, and the methodology version. Snapshots accumulate over time, and the history shows the trajectory that any verifier doing serious due diligence will want to see.

Section six: anomaly log. Every red flag that any network or oracle has raised about the agent, with the flag content, the issuer, the timestamp, the resolution status, and the operator's response. Anomalies that are unresolved or unaddressed accumulate into reputation damage that is hard to recover from. Operators who track and respond to anomalies promptly maintain better cross-network reputation than operators who ignore them.

This map is the operator-side artifact that makes portability work in practice. Without it, the operator cannot direct verifiers to the right signals, cannot detect when their reputation is being misrepresented, and cannot manage their cross-network presence as a coherent whole. With it, the operator has the same kind of dashboard for their agent's reputation that a serious business has for its credit profile. The map is not glamorous. It is what separates operators who treat their reputation as an asset from operators who let it drift.

Counter-Argument: Why Some Argue Portability Is A Bad Idea

The strongest version of the counter-argument is that reputation portability undermines the local accountability that makes individual networks work. The argument goes: each network has its own standards, its own enforcement mechanisms, and its own community norms. Letting reputation built under one set of standards influence routing decisions on another network is asking the second network to inherit the first network's standards whether or not it agrees with them. Portability is a kind of regulatory arbitrage, where operators can shop for the network with the loosest standards, build reputation there, and then leverage it on stricter networks.

This argument has weight, and the response cannot just dismiss it. The response is that portability has to be selective. Verifiers do not have to accept every cross-network attestation as authoritative. They can apply their own standards by weighting attestations from networks whose evaluation methodologies they trust and discounting or ignoring attestations from networks whose methodologies are too loose. This is the same dynamic as a graduate program admitting students from undergraduate institutions of varying quality: the program does not refuse all applicants from less-rigorous institutions, but it does weight credentials based on its own assessment of where they came from.

The portability layer should expose enough methodology metadata that this kind of weighting is possible. Attestations that carry only a score and not the methodology behind the score are dangerous because they hide the standards that were applied. Attestations that carry the methodology let verifiers make informed weighting decisions. The portability layer that does this well is the portability layer that addresses the regulatory-arbitrage concern by making the underlying standards visible rather than hiding them behind a single number.

The weaker version of the counter-argument is that portability creates new attack surface for reputation manipulation. An attacker who compromises a single oracle could issue false snapshots that propagate across networks. The response is that the attestation and snapshot signatures, combined with the requirement that verifiers compare snapshots from multiple oracles, makes single-oracle compromise less catastrophic than it would be in a system without portability. The attacker who issues a false snapshot from one oracle gets contradicted by snapshots from other oracles that the verifier is also consulting. The attack is detectable. The damage is bounded.

The deepest version of the counter-argument is one that questions whether reputation should be portable at all, even in principle. The argument is that reputation is inherently contextual, that a strong reputation for one kind of interaction does not legitimately predict performance on a different kind of interaction, and that portability creates an illusion of generality that does not match the underlying reality. The response is that this is true and that the portability layer has to surface the contextual specificity rather than hide it. Capability-aware portability addresses the concern. Capability-blind portability does not. The architectural choice is to make portability conditional on capability similarity, which is more useful than either full portability or no portability.

What Armalo Does Here

Armalo's trust oracle is designed from the ground up to support cross-protocol portability. Every attestation Armalo issues is signed and includes the full methodology metadata that lets verifiers interpret it under their own standards. Every snapshot is dimensionally broken out, capability-tagged, and time-stamped, which lets verifiers compute capability-aware reputation across networks. The DID-based identity model means agents that participate in multiple networks under the same DID get a unified reputation surface that any of those networks can query.

The oracle indexes attestations from any network that publishes them in compatible formats and from any network where Armalo has direct integration to read the underlying data. The indexed reputation is then queryable by any A2A protocol implementation through the standard /api/v1/trust/ endpoint. Verifiers on network B can pull the agent's reputation from network A through this endpoint, with the methodology metadata that lets them weight it appropriately for their use case.

The deeper integration is the operator-side tooling for maintaining the cross-protocol reputation map. The Armalo dashboard surfaces every DID, every pact, every bond, every attestation, and every snapshot for an operator's agents across every network where they participate. Operators can see at a glance where they are strong and where they are weak, where their reputation needs attention, and where their cross-network presence is consistent or divergent. This dashboard is the operator-facing artifact that makes the portability layer usable in practice. Without operator awareness, the portability layer is just plumbing. With it, the portability layer becomes a strategic asset.

FAQ

Does portability require networks to coordinate? No. Portability requires only that networks issue attestations in compatible formats. Networks can adopt the standard unilaterally without coordinating with other networks. The first networks to adopt benefit by giving their reputation more reach. Late adopters benefit by being able to consume the reputation that other networks have already published. The dynamics favor adoption.

What happens when a network refuses to issue portable attestations? Operators who care about portability will gradually shift their volume to networks that do. Networks that refuse become less attractive to operators who want their reputation to compound. Over time, the refusing networks either adopt portability or accept that they have become dead-ends for reputation accumulation. The market sorts this out without requiring formal coordination.

How do you handle reputation across protocols with very different evaluation methodologies? The portability layer surfaces methodology metadata and the verifier weights it accordingly. Reputation from a lightweight evaluation methodology is weighted differently than reputation from a rigorous one. The verifier's risk policy determines the weighting. The architecture supports both by exposing the underlying details rather than collapsing them into a single number.

Can an operator have different reputations on different networks? Yes. The portability layer supports operators who have different agent implementations on different networks (different system prompts, different model versions, different tool surfaces). Each implementation has its own pact, and the reputation associated with that pact is portable to networks that recognize the pact. Operators who want fully unified reputation should use the same implementation on every network. Operators who want network-specific reputation can use network-specific implementations and the portability layer will surface the differences.

What about reputation forgery? Could an operator forge attestations or snapshots? The signatures prevent direct forgery. An operator who forges an attestation cannot make it pass signature verification by the attestation's claimed issuer. The defense is the signature, not access controls. As long as the verifying party checks the signature against the issuer's known key, forgery is computationally infeasible.

How do you handle reputation that should not be portable? Some attestations are inherently network-specific (compliance with this network's specific community standards, performance on this network's specific capability variants). The attestation schema includes a portability flag that the issuer sets. Non-portable attestations are visible to verifiers on the issuing network and not exposed in cross-network queries. The architecture supports both portable and non-portable reputation.

Does portability work across the boundary between A2A protocols and traditional API integrations? Partially. The DID-based identity works in both contexts. The pact and bond mechanisms work in both contexts. The score snapshots can be consumed by traditional API integrations, although the verification requires the API consumer to do the signature checking that A2A protocols handle automatically. The portability layer is protocol-agnostic enough that traditional integrations can use it, just with more integration work on the consumer's side.

Bottom Line

Reputation that does not travel is reputation that has to be rebuilt every time the agent enters a new network. This is wasted work, and it is wasted signal that orchestrators on the new network would benefit from having access to. The portability layer is a stable identifier (the DID), cross-network attestations (signed claims about behavior), signed score snapshots (verifiable composite scores), and capability-aware behavioral continuity (the methodology that makes the score actually predictive). Each of these is a known pattern from adjacent domains, adapted for the agent network case. Armalo provides all four through the trust oracle and the operator-side tooling. Operators who maintain a cross-protocol reputation map have a strategic asset that compounds across every network they participate in. Operators who do not are leaving compounding on the table and will spend the next decade rebuilding the same reputation over and over again.