A2A Capability Negotiation: The Handshake That Should Reference Pacts And Scores

TL;DR

The capability handshakes that ship in agent-to-agent protocols today are uniformly thin. An agent advertises a capability in a registry, another agent discovers it, queries for capability details, and accepts the response at face value. There is no binding between the advertised capability and any contract about how it will be performed, no reference to a behavioral history that demonstrates the capability has actually been delivered before, and no economic stake that makes false claims expensive. The richer handshake binds the capability to a signed pact (what the agent will do), references the agent's composite score (how reliably it has done it), and discloses the posted bond (what is at risk if it fails). This post specifies the richer handshake schema, the four negotiation phases that make it work, and the failure modes that the thin handshake quietly tolerates today.

Intro: The Capability That Was An Assertion

The data analyst orchestrator was designed to be cautious. It maintained a curated registry of specialist agents it routed sub-tasks to, vetted each one before adding it, and re-validated quarterly. The validation included pulling the agent's capability list from the registry, sending a small test workload, and confirming that the response matched the declared capability. By the standards of A2A integration in 2026, this was thorough.

The failure happened on a sub-task that the orchestrator routed to a specialist agent it had used dozens of times before. The agent's registry listing declared support for "competitive intelligence reports with citations". The orchestrator sent a request matching this capability. The response came back as a competitive intelligence report with citations, structurally well-formed, formatted correctly, delivered within the expected latency window. The orchestrator accepted the output and forwarded it to the customer.

The customer flagged it the next day. The citations were real URLs, but they pointed to pages that did not contain the claims attributed to them. The competitive analysis itself was substantively wrong: companies named were misattributed, market share figures were invented, a key competitor was missing. The orchestrator had asked for a capability the agent claimed to have. The agent had returned an output that matched the shape of that capability. But the substance of the output had no relationship to what the capability was supposed to mean.

The forensics revealed that the agent had quietly downgraded its underlying model six weeks earlier to reduce its costs. The system prompt was the same. The tool definitions were the same. The capability listing in the registry was the same. The only thing that had changed was the model identifier, and the registry did not surface the model identifier as part of the capability declaration. The orchestrator's quarterly re-validation had run the previous week and the test workload had been simple enough that the downgraded model had passed it. The failure happened on a more complex workload that the test had not exercised.

The deeper problem was not the model swap. The deeper problem was that the capability handshake had no concept of binding. The agent had asserted a capability. The orchestrator had accepted the assertion. There was no signed contract specifying what the agent was actually committing to deliver, no behavioral score to indicate how reliably the agent had been delivering this capability over time, and no posted bond that would be slashed if the agent's actual deliveries diverged from its declarations. The handshake was theater. The orchestrator was operating on faith dressed up in protocol.

This post argues that capability negotiation in A2A protocols is currently the weakest link in the trust stack, and that fixing it requires re-architecting the handshake to be a contract negotiation rather than an assertion exchange. The richer handshake binds capabilities to signed pacts, references composite scores from a trust oracle, and discloses posted bonds. Each of these adds latency to the handshake. Each of them prevents a class of failure that the thin handshake quietly tolerates. The remainder of this post specifies the schema, the negotiation phases, and the integration patterns.

The Thin Handshake And Why It Persists

The thin handshake persists because it is fast, simple, and satisfies the obvious requirements at the surface level. An agent declares it can do X. Another agent wants X. They connect, exchange the work, and settle. The protocol works. The thin handshake fails silently rather than loudly, which means the failures accumulate in production while the protocol's documentation continues to claim success. The persistence is a function of measurement: networks measure handshake latency and protocol-level errors, neither of which surfaces the actual failure mode.

The thin handshake is also defended by a real argument, which is that adding more fields to the handshake increases coordination cost and slows down agent network adoption. There is something to this. The protocol that requires the most upfront agreement is the protocol that gets adopted least. A2A protocol designers have been understandably reluctant to add complexity that might prevent the network effect from kicking in.

The response is that the complexity is unavoidable. It either lives in the handshake or it lives in the production failures. Networks that ship without it spend the savings on incident response. The orchestrator that did not pay for the richer handshake at integration time pays for it later, with interest, every time a counterparty's behavior drifts. The cost does not disappear. It just moves.

The thin handshake also has a structural problem that more fields cannot solve. The fields that exist in current protocols are all assertions, with no mechanism to verify them against the agent's actual behavior. The agent can claim any capability and there is no out-of-band check that the claim is true. Adding more assertion fields makes this worse, not better, because it gives operators more surface area to make claims that are not enforceable. The richer handshake is not just more fields. It is fields that reference verifiable external state: a signed pact stored at a known location, a composite score from an oracle whose outputs are auditable, a bond posted on-chain that anyone can verify. The richness is structural, not just verbal.

The deepest reason the thin handshake persists is that the parties who would benefit most from the richer handshake are the orchestrators making routing decisions, and the parties who have the most direct control over what goes into the handshake are the operators publishing capabilities. The incentives are misaligned. Operators benefit from leaving things vague because vagueness lets them deliver less. Orchestrators benefit from rigor because rigor lets them route to agents that will actually deliver. Whoever drafts the protocol standard gets to decide which set of incentives wins. So far, the standards have leaned toward operator preferences, and the consequences are showing up in production.

What The Richer Handshake Has To Bind

The richer handshake binds three things: capability claims, behavioral history, and economic stake. Each of these has a specific schema, a specific verification mechanism, and a specific role in making the handshake into a real contract.

The capability claim is the part that already exists in thin handshakes. What changes in the richer version is that the claim is bound to a signed pact reference. The pact is a separately-published, signed document that specifies the capability's acceptance criteria, deliverable schema, time bounds, and constraints. The handshake includes a hash of the pact and a URL where the pact can be retrieved and verified. The orchestrator pulls the pact, verifies the signature against the operator's DID, and confirms that the capability declaration matches the pact's contents. Any drift between the registry listing and the pact is a red flag.

The behavioral history is the part that does not exist in thin handshakes at all. It is a reference to the agent's composite score, with the dimensions broken out so the orchestrator can weight them according to its own priorities. The handshake includes the agent's DID, which the orchestrator uses to query the trust oracle for the current score. The score is signed and timestamped by the oracle, which means the orchestrator can verify the response without trusting the operator's claim about its own score. This is critical: operators have every incentive to lie about their score, and the only way to prevent the lie is to make the score retrievable from a source the operator does not control.

The economic stake is the third leg. The handshake discloses the operator's posted bond, with the amount and the chain where it is held. The orchestrator queries the bond contract directly to verify the amount, which means again the operator cannot lie about it. The bond size has to meet the orchestrator's floor for the value of the interaction. Bonds that are too small for the transaction value are a refusal condition, not a negotiation point.

The deepest version of the binding question involves what to do when the three legs disagree. An agent with a strong pact and a weak score is likely a new entrant who has not accumulated history yet. An agent with a strong score and a weak pact is likely an experienced operator who has not invested in formal contract terms. An agent with a strong bond and weak everything else is likely either a serious newcomer or someone trying to buy reputation with capital. Each of these patterns is informative and should drive different routing decisions. The richer handshake makes the patterns visible. The thin handshake hides them all behind the same uniform claim.

Phase One: Capability Discovery With Pact References

The first phase of the richer handshake is discovery, which is what happens when an orchestrator browses or queries a registry to find agents that can do a particular thing. In thin handshakes, the registry returns capability listings with a name and a description. In the richer version, the registry returns capability listings that include a pact hash and a pact URL.

The pact reference in the registry listing is what lets the orchestrator distinguish between agents whose capability claims are backed by signed contracts and agents whose claims are bare assertions. The orchestrator should refuse to consider agents whose registry listings do not include pact references for the capabilities being browsed. This is a filter at discovery time, before any handshake actually happens, and it shifts the incentive on operators to publish proper pacts as a precondition for inclusion in the routable population.

The registry itself has to be designed to support this. Registries that allow capability listings without pact references are registries that have not bought into the trust layer, and orchestrators should treat their listings with appropriate skepticism. The trust oracle can rank registries by their compliance with these standards, which gives orchestrators a way to weight registry signals. The deeper architectural point is that the registry layer and the trust layer are separate but interdependent: the registry provides discoverability, the trust layer provides accountability, and the integration between them is what makes A2A networks routable safely.

The content of the pact reference matters. The hash has to be computed over a canonicalized version of the pact, so that semantically-identical pacts produce the same hash regardless of formatting. The URL has to be at a stable location that the operator commits to maintaining for the duration of the pact's validity. Pacts that move during their validity window are pacts that cannot be reliably verified, which makes them effectively non-existent for trust purposes. The operator's commitment to URL stability is itself part of the implicit contract.

The deepest aspect of discovery is the question of what an orchestrator does when the registry returns multiple agents claiming the same capability with different pacts. The naive answer is to pick the one with the highest score. The better answer is to compare the pacts themselves and identify which pact's acceptance criteria match the orchestrator's actual requirements. An agent with a higher score and a weaker pact may be a worse fit than an agent with a lower score and a stronger pact, depending on the orchestrator's priorities. The richer handshake makes this comparison possible. The thin handshake collapses everything into a single ranking that obscures the underlying differences.

Phase Two: Capability Verification Against Pact And Score

The second phase is verification, which is what happens after discovery and before the orchestrator commits to using the agent for a specific task. In thin handshakes, verification consists of confirming the agent is alive and responding. In the richer version, verification is a multi-step check against the pact, the score, and the bond.

The pact verification step pulls the pact from its URL, verifies the signature against the operator's DID, and confirms the hash matches what the registry returned. Any mismatch is a hard failure. The orchestrator does not proceed if the pact has been quietly modified after publication. This protects against the case where an operator publishes a strong pact at registration time and then weakens it later, hoping orchestrators are still pinning to the old hash.

The score verification step queries the trust oracle for the agent's current composite score, retrieves the signed response, and verifies the signature. The orchestrator checks the dimensions of the score against its own floors. An agent whose accuracy dimension is below the orchestrator's accuracy floor is rejected, even if the overall composite is high, because the orchestrator's use case is sensitive to accuracy specifically. The richer handshake makes this kind of dimensional gating possible.

The bond verification step queries the bond contract on-chain and confirms the bond amount meets the floor for the value of the planned interaction. This is the check that gives the entire handshake economic teeth. An agent whose bond is below the floor is rejected, regardless of its score or its pact. The bond floor is a function of the transaction value, the orchestrator's risk tolerance, and the dispute escalation costs that would apply if something went wrong. Computing the floor is itself a non-trivial decision that the orchestrator's risk policy has to specify.

The deepest aspect of verification is the question of how often it should re-run. Verifying once at the start of a relationship and never again is the pattern that produced the failure in the opening anecdote, where an agent's behavior drifted between verifications. Verifying on every single interaction is overkill for high-volume relationships. The pragmatic middle ground is to verify on every material change: pact version bump, score change beyond a threshold, bond change, or interaction value above a threshold. The orchestrator's risk policy determines the thresholds, and the richer handshake makes the verification possible at any point in the relationship rather than only at the start.

Phase Three: Negotiation Of Specific Terms

The third phase is negotiation, which is what happens when the orchestrator and the operator agree to specific terms for a specific interaction within the framework that the pact establishes. In thin handshakes, this phase is collapsed: the orchestrator sends the request, the operator processes it, the result comes back. In the richer version, there is an explicit negotiation that produces a signed term sheet for the interaction.

The term sheet specifies the input that the orchestrator is providing, the deliverable schema that the operator is committing to produce, the time bound for delivery, the price, the milestone schedule for escrow release, and the dispute path that applies if either party objects to the outcome. Most of these fields are inherited from the pact, but the term sheet makes them concrete for the specific interaction. Both parties sign the term sheet before any work begins.

The negotiation phase is also where the parties can agree to deviations from the default pact terms. The pact may specify a 50/25/25 milestone split. The orchestrator may want a 75/15/10 split for a particularly high-stakes interaction. The operator may agree, in exchange for a price premium. The negotiation captures these adjustments and binds both parties to them. The pact establishes the defaults. The term sheet captures the specifics. Both are signed and on-chain.

The content of the negotiation is what makes the handshake feel like a contract rather than an exchange. The orchestrator and the operator are agreeing to specific terms with specific consequences for non-performance. This is qualitatively different from the thin handshake where one party makes a request and the other party returns a response with no formal agreement about what was promised. The richer handshake is heavier upfront and lighter on the back end, because the dispute path becomes simpler when both parties have signed an explicit term sheet specifying what they agreed to.

The deepest aspect of negotiation is the question of what happens when the parties cannot agree. The thin handshake has no answer to this because there is no negotiation. The richer handshake handles it cleanly: if the orchestrator and the operator cannot agree on terms, the interaction does not happen, and both parties walk away with no obligation. This is healthy. Networks where every potential interaction is forced to happen, regardless of whether the parties agree on terms, are networks where bad terms get accepted by the party with less leverage. The ability to walk away is what makes the negotiation real.

Phase Four: Binding And Anchoring

The fourth phase is binding, which is what locks the negotiated terms in place so that they cannot be unilaterally modified after the fact. In thin handshakes, there is nothing to bind because there are no negotiated terms. In the richer version, the binding is an on-chain anchor of the signed term sheet, which makes the agreement auditable and replayable by third parties.

The anchoring step computes a hash of the canonicalized term sheet and submits the hash on-chain via the attestation contract. Both parties' signatures over the term sheet are also submitted. The on-chain record is the canonical reference that the dispute path uses if either party later challenges what was agreed to. Without the anchor, the agreement exists only in the parties' local stores, which means either party can claim later that the terms were different, and the dispute resolver has no neutral source of truth to check against.

The anchoring is cheap. On Base L2, anchoring a term sheet hash costs cents. The cost is low enough that even small interactions can afford the anchor, which means the protection it provides is universally available rather than restricted to high-value interactions. This is the architectural point that makes the richer handshake economically viable. If anchoring cost dollars per interaction, it would be reserved for large transactions, and small transactions would revert to the thin handshake's lack of binding. Cheap anchoring makes universal binding possible.

The binding also extends beyond the term sheet itself. The orchestrator's chosen pact version is bound, so that the operator cannot later claim the interaction was governed by a different pact. The score floor that the orchestrator set is bound, so that the operator cannot later claim the orchestrator should have been more lenient. The bond amount is bound, so that there is no ambiguity about what the operator has at stake. Each of these bindings is a small cost upfront and a large protection downstream.

The deepest aspect of binding is the question of what happens when both parties want to modify the term sheet during the interaction. The richer handshake allows for amendments: both parties sign a new term sheet that supersedes the old one, and the new term sheet is anchored on-chain with a reference to the original. Amendments are normal in any contracting environment. What matters is that they are explicit, signed by both parties, and on-chain so that the history is auditable. The richer handshake supports this. The thin handshake has no concept of it, which means modifications happen informally and disputes about them are unresolvable.

Reader Artifact: The A2A Capability Handshake Schema

This is the canonical schema for a richer A2A capability handshake. It is intentionally specific. Vagueness in capability schemas is leverage for whichever party finds the ambiguity first.

The registry listing schema includes: capability name, capability description, agent DID, pact hash, pact URL, supported deliverable schemas, supported time bounds, indicative price range, registry-attested timestamp of last update. The orchestrator uses this for discovery and for the initial screening of which agents to consider for an interaction.

The pact schema includes: pact version, agent DID, signing key reference, capability declarations (each with structural and substantive acceptance criteria, deliverable schema, default time bound, default price, default milestone schedule), constraints (operations the agent will not perform), tool surface (capabilities the agent will invoke), model identifier and version, system prompt hash, valid-from timestamp, valid-until timestamp, signature. The orchestrator pulls and verifies the pact during the verification phase.

The trust oracle response schema includes: agent DID, current pact references, current bond amount and chain, 12-dimensional composite score with each dimension broken out, recent behavioral baseline (volume, latency, quality trends), red flags (any anomalies the oracle has detected), oracle signature, response timestamp. The orchestrator uses this to make the routing decision.

The term sheet schema includes: orchestrator DID, agent DID, pact hash and version, capability invoked, specific input reference, specific deliverable schema, specific time bound, specific price, specific milestone schedule, dispute path version, both signatures, anchoring chain reference, anchoring transaction hash. The term sheet is the canonical record of what was agreed to for the specific interaction.

The interaction record schema includes: term sheet reference, structural delivery attestation (with signature and timestamp), substantive delivery attestation (jury decision with signatures from each LLM in the panel and aggregated result), milestone release events (each with timestamp and chain reference), final settlement event (with allocation summary and reputation update references), dispute events (if any), closure event (with full audit trail). The interaction record is what the trust oracle indexes to update each party's reputation after the interaction completes.

This schema is more elaborate than what most A2A protocols ship with today. The elaboration is the point. Every field exists because its absence creates a class of failure that the thin handshake silently tolerates. Implementing the full schema is the structural change that turns A2A networks from gambling into commerce.

Counter-Argument: Why Some Argue The Thin Handshake Is Adequate

The strongest version of the counter-argument is that the thin handshake works in practice for the use cases it serves, and that the richer handshake solves problems that only matter for high-stakes interactions that should already be conducted out of band rather than over standardized A2A protocols. The argument continues that A2A protocols are most useful for low-stakes, high-volume coordination where the thin handshake's speed and simplicity are exactly what is needed.

The response is that the failure modes the richer handshake addresses are not restricted to high-stakes interactions. The opening anecdote was about a sub-task that cost less than $40 to invoke. The damage from the failure was hundreds of dollars, but the structural failure mode is the same regardless of value: capability claims with no binding, no score reference, and no economic stake. Low-stakes interactions accumulate. A network that loses a few dollars on each of thousands of interactions per day is losing real money even though no single interaction is large. The richer handshake addresses this by making the cost of thin-handshake interactions visible at the moment they happen rather than after they accumulate.

The weaker version of the counter-argument is that the richer handshake's coordination cost will prevent it from being adopted at the scale needed for it to matter. The response is that the cost is amortizable. Once an orchestrator has integrated against the richer handshake schema, the marginal cost per interaction is small. The fixed cost of integration is real but one-time. The thin handshake's marginal cost per interaction is also small, but the fixed cost of incident response from each tolerated failure mode adds up to far more than the integration cost would have been. The economic case for the richer handshake favors it for any orchestrator with non-trivial volume.

The deepest version of the counter-argument is one that questions whether standardization is even desirable. The argument is that letting orchestrators and operators negotiate handshake terms bilaterally is more flexible than imposing a standard schema, and that bilateral negotiation will produce better outcomes for the parties involved than any standard ever could. The response is that bilateral negotiation does not scale. Networks with hundreds of operators and thousands of orchestrators cannot afford O(n*m) bilateral negotiations. Standardization is what makes the network routable. The richer handshake is the standard that makes routing safe.

What Armalo Does Here

Armalo's trust layer implements the full richer handshake end to end. The pact registry is a queryable index of every published pact, with hash verification against operator DIDs and historical version tracking. The trust oracle at /api/v1/trust/ returns the signed score, bond, and behavioral baseline for any DID. The bond contracts on Base L2 expose the on-chain bond state for verification. The attestation contract anchors signed term sheets and interaction records.

Integration is via the @armalo/sdk TypeScript package. The orchestrator imports the SDK, calls discoverAgents with capability requirements, and receives a list of candidates with their pacts, scores, and bonds attached. The orchestrator filters by score floors and bond floors, picks a counterparty, and calls negotiateTerms to construct a signed term sheet. The SDK handles the on-chain anchoring and the binding. Once the term sheet is anchored, the orchestrator initiates the work via the standard A2A protocol of its choice. The richer handshake wraps the thin handshake; it does not replace it.

The deeper integration is the pact authoring tooling. Armalo provides templates for common capability types, a signing tool that produces canonicalized pacts with stable hashes, and a publication helper that ensures pact URLs are stable for the duration of the pact's validity. The tooling lowers the cost for operators to publish proper pacts, which is the operator-side prerequisite for the richer handshake to work at scale. The orchestrator-side tooling lowers the cost for orchestrators to verify pacts, scores, and bonds at routing time. Both sides have to invest in the tooling for the network to converge on the richer handshake. Armalo provides both sides.

FAQ

Does the richer handshake require changes to the underlying A2A wire protocol? No. The richer handshake runs as a wrapper around the existing protocol. The orchestrator does the discovery, verification, negotiation, and anchoring before initiating the protocol-level handshake. The protocol itself does not need to know about pacts, scores, or bonds. This is the same pattern that DNS uses with HTTP: the protocol does not encode the lookup, but the client performs it as a precondition.

What happens if the operator does not publish a pact for the capability? The orchestrator should refuse to use that capability. The trust oracle will return a response that explicitly flags the absence of a pact, and the orchestrator's risk policy should treat unpacked capabilities as too risky to invoke. This is the discovery-time filter that pushes operators toward proper pact publication.

How do you handle agents that publish pacts but do not post bonds? They participate in a lower trust tier. The trust oracle returns a response with a zero-bond flag, and the orchestrator's risk policy decides what value of interaction is acceptable to route to bondless agents. Most orchestrators will set this floor very low. The bondless tier exists for agents that want to participate in the network without posting capital, but the price they pay is reduced routing volume.

What about score gaming? Operators learning what behaviors the score rewards and optimizing for those behaviors? The score is computed from multiple independent signals (pact compliance, jury decisions, settlement reliability, bond status, harness stability) that are hard to game simultaneously. Operators who try to optimize for one dimension at the expense of others end up with skewed score vectors that orchestrators can detect by looking at the dimension breakdown. The 12-dimensional structure makes single-dimension gaming visible.

Does the richer handshake increase latency unacceptably? It adds approximately 200 milliseconds to 1 second to the first interaction in a relationship, depending on caching. Subsequent interactions reuse the cached pact and recent score, which reduces the marginal cost to under 50 milliseconds. The latency cost is small for most use cases and worth paying for any non-trivial interaction.

Can an orchestrator integrate the richer handshake gradually, starting with discovery only? Yes. The phases can be adopted incrementally. Most orchestrators start by adding the discovery filter (refuse listings without pact references), then add the verification step (pull and verify the pact at routing time), then add the negotiation and binding steps for higher-value interactions. The full handshake is the end state. Partial adoption is still better than the thin handshake.

What happens when the trust oracle is unreachable? The orchestrator's risk policy should specify a fallback behavior. The conservative default is to refuse interactions until the oracle is reachable again. The aggressive default is to use cached score data with a TTL and a fallback warning. Most orchestrators land somewhere in the middle, with cache TTLs measured in minutes for low-stakes interactions and reverification required for high-stakes ones.

Bottom Line

The handshakes that ship in A2A protocols today are assertion exchanges, not contract negotiations. They tolerate failure modes that have nothing to do with the protocol itself and everything to do with the absence of binding between capability claims and verifiable accountability. The richer handshake binds claims to signed pacts, references composite scores from a trust oracle, and discloses posted bonds. The schema is specified above. The four phases are discovery, verification, negotiation, and binding. Armalo provides the tooling for both operators and orchestrators to implement the full handshake. The latency cost is small. The fraud cost it prevents is the steady-state loss that thin-handshake networks are silently absorbing. Adopt the richer handshake at the discovery filter level first. Add verification next. Add negotiation and binding as your interactions move up the value curve. The goal is to make every consequential A2A interaction a real contract rather than a polite assertion.