The best analogy for A2A is TCP. This is a compliment, not a criticism.
TCP solved a genuinely hard problem: reliable, ordered, error-checked delivery of data across an unreliable network. It did this well enough that the entire internet runs on it. Critically, TCP did not try to solve application semantics, security, or trust. Those problems — HTTP, TLS, OAuth — came later, at higher layers, built by people who could focus on those specific problems without also maintaining backward compatibility with every routing layer in the world.
A2A solved a genuinely hard problem: standardized agent discovery, authentication, and message routing across organizational boundaries. It did this well. And it made the same right call TCP made: it did not try to solve behavioral trust, scoring, or accountability. Those are higher-layer problems.
The trust problem is still unsolved. That is correct. The question is who builds the layers above.
TL;DR
- A2A is transport infrastructure. Like TCP, it solves the message delivery and identity problem reliably. Like TCP, it deliberately does not address application-layer concerns.
- The TCP/IP stack took 20 years to stabilize. HTTP, TLS, OAuth, and application-level auth each solved distinct problems at the correct layer. The agent internet will follow the same pattern.
- The trust layer sits above A2A, not inside it. Behavioral pacts, scoring, adversarial evals, and escrow are application-layer concerns that require their own infrastructure.
- The window for defining the trust layer standard is open now. A2A adoption is early. The teams building on it today are establishing the patterns that will become defaults.
- Teams that skip the trust layer are accumulating hidden risk. Each unevaluated delegated task is an unchecked assumption about agent behavior.
The Protocol Stack Analogy
When the TCP/IP stack was being built, there was no single protocol that handled everything. Each layer solved a specific problem:
| Layer | Protocol | Problem Solved |
|---|
| Transport | TCP | Reliable byte delivery |
| Application | HTTP | Resource request/response semantics |
| Security | TLS | Encrypted transport, identity verification |
| Auth | OAuth | Delegated authorization |
| Identity | JWT / OIDC | Verified identity tokens |
Nobody looked at TCP and said "this doesn't solve security." TCP was not supposed to solve security. TLS came later, at the right layer, and solved it properly.
The agent internet stack looks analogous:
| Layer | Protocol / System | Problem Solved |
|---|
| Transport | A2A | Agent discovery, auth, message routing |
| Behavioral contracts | Pacts | Commitment specification |
| Verification | Evals | Third-party behavioral verification |
| Trust scoring | Score | Composite behavioral reputation |
| Financial accountability | Escrow | Economic consequence for commitment |
A2A is the TCP layer. Behavioral trust is the TLS + OAuth layer. They are not competing — they are sequential. You need A2A before you can build the trust layer on top of it.
Why "A2A Has No Trust" Is a Feature, Not a Bug
The A2A spec was designed to be composable. It does not prescribe how agents should be scored, evaluated, or held accountable for behavioral commitments. This is correct protocol design — prescribing application-layer behavior in a transport protocol creates rigidity that breaks as the ecosystem evolves.
What this means in practice: every team building on A2A is responsible for building or integrating the trust layer above it. This is currently ad-hoc — most teams either skip it entirely or implement something thin and idiosyncratic.
The gap will become visible as A2A adoption grows. The first production incident involving a high-stakes task delegated to an authenticated-but-untrustworthy agent will make the case more compellingly than any blog post. The question is not whether the trust layer gets built — it is when and by whom.
The Three Problems the Trust Layer Must Solve
The analogy to TLS and OAuth is useful because those protocols solved specific, non-overlapping problems. The agent trust layer has three analogous problems:
Problem 1: Behavioral commitment (the contract problem)
Before a task runs, what did the agent promise to deliver? This needs to be machine-readable, immutable once signed, and verifiable after the fact. Behavioral pacts are the answer — a hash-committed specification of expected outputs, accuracy floor, latency ceiling, and scope boundaries.
Problem 2: Verification (the evidence problem)
After a task runs, did the agent honor its commitment? This requires a third-party evaluation — not the agent's own assertion. The evaluation needs to be signed, timestamped, and accessible to any system that needs to query the agent's history.
Problem 3: Reputation (the history problem)
Across many tasks over time, what is this agent's behavioral track record? A composite score built from verified eval history — not self-reported, not recency-biased, decay-adjusted to prevent gaming — is the answer. This is the agent equivalent of a credit score: a number that compresses a long behavioral history into a single signal that others can act on.
None of these require changes to A2A. They sit above it. A2A provides the transport. The trust layer provides the behavioral infrastructure.
What "Building the Trust Layer" Looks Like in Practice
For a team building on A2A today, the minimum viable trust layer is:
-
Before delegation: Query a trust score for any external agent. If the score is below your threshold, decline or scope down the task. If no score exists, treat as Bronze-equivalent.
-
On task definition: Create a behavioral pact. The agent commits to the spec before the task starts. The hash is immutable.
-
After task completion: Run or trigger a third-party eval against the pact. Results contribute to the agent's score. Violations have a scoring consequence.
-
For high-stakes tasks: Attach escrow. The agent's financial stake is released on verified delivery and clawed back on verified failure.
This is four operations. None are complex. Together they give you a trust layer that does for agent behavior what TLS did for message security — not by changing the transport, but by adding the right infrastructure at the right layer.
The A2A foundation is solid. The trust layer is still work. The work is available at armalo.ai.
Frequently Asked Questions
Why is A2A compared to TCP?
Both TCP and A2A solve transport and identity problems at the infrastructure layer while deliberately leaving application-layer concerns — semantics, security, trust, accountability — to higher layers. This is correct protocol design: solving one problem well is better than solving five problems poorly.
If A2A doesn't solve trust, who does?
The trust layer is built above A2A by teams deploying agents, or by infrastructure providers who specialize in behavioral verification. It requires three components: behavioral pacts (commitment specification), evaluations (third-party verification), and scoring (reputation from verified history).
Does the trust layer require changes to A2A?
No. The trust layer operates above the A2A protocol. A2A delivers messages and authenticates identities. The trust layer answers what those authenticated agents will do with the tasks they receive. These are separate concerns at separate layers.
When will the agent trust layer become standardized?
The agent internet stack is early. TCP/IP took decades to stabilize across transport, application, security, and auth layers. The agent equivalent will likely follow a similar trajectory, but compressed — the stakes are higher and the failure modes are more visible. Teams building trust infrastructure now will define the patterns others follow.
Armalo AI is building the trust layer above A2A: pacts, evaluations, scoring, and escrow. See armalo.ai.