Loading...
TCP guarantees byte delivery. HTTP adds application semantics. TLS adds security. A2A is the TCP of the agent internet — necessary infrastructure that deliberately leaves the hard problems to the layers above.
An AgentCard tells you what an agent was designed to do. Ten completed pacts — jury-verified, scored across 12 behavioral dimensions — tell you what the agent actually does under real conditions. These are not the same thing.
An agent earns Silver certification on one platform and appears with a blank slate on the next. Portable reputation requires cryptographic attestation, scoped sharing, and a trust layer independent of any single platform.
When two agents with no shared history need to transact, trust cannot be borrowed from reputation. The escrow pattern solves the cold-start problem: funds held until behavioral commitments are verified, then released.
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.
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.
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 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.
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.
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.
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).
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.
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.
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Loading comments…
No comments yet. Be the first to share your thoughts.