Laxmikant Sharma

[writing]

When Agents Hire Agents: PACT, the Missing Layer 4 of the Agentic Web

A2A moves tasks without prices, x402 moves money unconditionally, AP2 authorizes without verifying. PACT adds the missing object: the Verifiable Task Contract.

[agents][protocols][agentic-web][pact]

Part 3 of the agentic-web series. Part 1 and Part 2 mapped what already exists. This one proposes something new. Part 4 continues with the retry nobody owns.

Picture a thousand agents assembling around a single job. A sealed-bid auction resolves in one round-trip. A tree of subcontracts forms underneath it. Work streams through payment channels with payouts landing as it arrives, one fraud proof slashes a subcontractor that cut corners, and every participant’s reputation updates the moment escrow closes. Paid in seconds. Final in an hour, once the last challenge window closes clean. Humans involved: zero. Every hop provable, forever.

Nothing in today’s stack can run that scene. I spent two posts mapping the protocols and the trust machinery underneath them, and when I lined it all up, one hole stood out.

The stack has an OSI problem

Transport ships. Messaging ships, in the form of MCP tools and A2A tasks. Trust ships too: signed cards, DIDs, act-chains, mandates. But watch what happens when an agent actually tries to hire another agent. A2A moves tasks, except they carry no price. x402 moves money, but unconditionally. AP2 authorizes payments without ever verifying the work. Nowhere in the 2026 stack is there an object that binds work to money to proof. Agent-to-agent commerce today is pay a stranger and hope.

The agent stack’s missing Layer 4, commerce

There is even a 45-year-old blueprint for the missing piece. R.G. Smith’s Contract Net Protocol (1980) described almost exactly this: task announcement, bidding, awarding. It got built, too, but only inside closed and mutually trusting systems. FIPA standardized it in 2002 and factories ran it on JADE. What never existed was the substrate for running it among strangers, meaning identity, money, and verification between parties with no reason to trust each other. That substrate exists now. PACT is Contract Net with teeth.

PACT: Propose, Agree, Complete, Trust

One job through PACT, the wire-level lifecycle

Propose. The buyer broadcasts a call-for-bids carrying the task spec, a deadline, a maximum price, and the verification tier the work will be judged by. Sellers answer with sealed bids plus a staked bond. The award goes to the best bid at the second-best price, which is to say a Vickrey auction.

But what does the broadcast actually say? The spec inside it is a layered TaskSpec, and each layer has a different reader:

{
  "description": "Dedupe 2.1M customer rows",
  "skill": "data-cleaning/dedupe",
  "inputs": {
    "sample_uri": "…/sample-10k.csv",
    "size_hint": { "rows": 2100000 }
  },
  "deliverable": { "format": "csv" },
  "acceptance": {
    "tier": "T0-reexec",
    "harness_uri": "…/acceptance-tests.tar",
    "thresholds": { "dup_rate_max": 0.001 }
  },
  "constraints": {
    "tools_prohibited": ["external-APIs"]
  }
}

Inside the call-for-bids: the TaskSpec layer by layer, and which layer is the contract

The seller’s LLM reads description to understand the job. The schemas and the sample let it price the effort, and the acceptance harness lets it price the risk, since what it is really estimating is its probability of passing against a bond it could lose. Which surfaces PACT’s quiet precedence rule: where prose and tests disagree, the acceptance instrument governs. Settlement is gated on verification, so the only economically real definition of “done” is the one the verifier applies. Prose is intent. The harness is the contract. (Confidential work? Publish the call-for-bids with the spec behind an authenticated fetch. The hash commitment stops any bait-and-switch.)

Why an auction rather than letting the agents haggle? Because negotiation between LLMs is an attack surface. Persuasion exploits, prompt-injecting your counterparty, strategic hallucination, none of it patchable with guardrails. Under a sealed-bid second-price award, truthful bidding is the dominant strategy, so game theory removes the incentive to manipulate instead of asking you to detect manipulation afterwards. Two details matter for safety. Bids are cryptographic commitments, so the buyer can’t peek, and can’t quietly insert a fake price-setting second bid either. And awards cover one task per auction, because Yokoo’s classic result says single-item second-price survives fake-identity bidding while bundle auctions don’t.

Agree. Both parties co-sign a Verifiable Task Contract: one typed JSON object, canonicalized (RFC 8785), signed (JWS), binding everything the stack currently leaves loose.

{
  "pact": "0.1",
  "type": "VerifiableTaskContract",
  "id": "vtc_9f2c",
  "parties": {
    "buyer":  "did:web:acme.ai:buyer-7",
    "seller": "did:web:dataforge.io:etl-3"
  },
  "task": {
    "spec_hash": "sha256:4be1…",
    "deadline": "2026-08-01T00:00:00Z"
  },
  "price": {
    "amount": "180.00",
    "currency": "USDC",
    "settlement": "pact-escrow",
    "channel": "ch_88a1"
  },
  "verification": {
    "tier": "T1-tee",
    "criteria_hash": "sha256:77d0…",
    "arbiter": "did:web:arbiter.example"
  },
  "liability": {
    "seller_bond": "18.00",
    "parent": "vtc_31aa"
  },
  "challenge": { "window_seconds": 3600 },
  "signatures": [
    { "kid": "buyer#k1",  "sig": "MEQCIA…" },
    { "kid": "seller#k1", "sig": "MEUCIQ…" }
  ]
}

A note on those hashes, because they are doing quiet work. spec_hash is a commitment, not a pointer. The full spec travels with the call-for-bids, either inline or at a spec_uri, and every party verifies it against the hash before signing and keeps the preimage through the dispute window. So in any later argument, presenting content that matches the co-signed hash proves exactly what was agreed. RFC 6920, “naming things with hashes,” gives the format.

The price locks in escrow through a proposed pact-escrow x402 payment scheme, and the word choice there is deliberate. In x402 v2’s taxonomy, anything that changes settlement semantics is a scheme, alongside exact and upto, while “extensions” are non-payment add-ons. The landing zone is well prepared. Cloudflare has proposed a deferred scheme with an escrow deposit up front, off-chain vouchers per request, and batch redemption, and there is an open PR in the x402 repo for a usage-based escrow scheme. What none of them provide is release gated on verified work, with bonds and challenge windows. That last step is what pact-escrow adds. Meanwhile the buyer’s authority arrives as an act-chain token from Part 2. Keep an eye on that parent field, it matters shortly.

Complete. Work streams in hash-committed checkpoints, and payment releases optimistically, which is the rollup pattern applied to labor. The seller gets paid at delivery. A challenge window follows, during which anyone can submit a fraud proof that reverts the payment and slashes the bond. A valid challenger is then paid out of that slashed bond: costs reimbursed plus a capped bounty, with the remainder going to a neutral sink. That clause isn’t generosity, it’s game theory. The rollup literature proved that unpaid watchmen stop watching, which is the verifier’s dilemma, and deployed systems like Arbitrum’s BoLD pay defenders a capped bounty for exactly this reason. Verification cost moves off the critical path, the same trick optimistic rollups pulled for Ethereum. What counts as a valid fraud proof depends on the tier the contract named up front:

The verification ladder: proof of work product, graded by stakes

I want to stress that this ladder is not speculative, but let me give you the honest numbers rather than the marketing ones. Lagrange’s DeepProve proves full GPT-2 inference at roughly 174 tokens per minute with about 1.2-second verification. Polyhedra’s zkPyTorch has pushed the ceiling to Llama-3 8B at around 150 seconds per token, which is provable but not yet economical, and NANOZK-style layerwise proofs (43 s proving, 23 ms verification at GPT-2 scale) point at how T2 eventually gets practical. Meanwhile TEE-attested inference is the production tier today: NVIDIA’s confidential-computing mode costs 2 to 8% throughput with a one-time attestation of a second or three, and the attestation itself now has a stable IETF format in EAT, RFC 9711. Re-execution covers code and data work, TEE covers provenance, zkML covers high stakes, and staked juries handle the subjective residue.

Trust. Escrow settles and both parties receive a co-signed Work Attestation. Here is the part I find genuinely satisfying: reputation becomes the exhaust of settlement. Every rating system ever built eventually drowns in Sybils and fake reviews. An attestation that exists only because escrowed money moved through a bonded contract is a different animal, because fabricating a work history means actually funding it, contract by contract, fee by fee. Collusion doesn’t come free either, since wash-trading your own reputation costs facilitator fees and locked bonds on every fake job. The agent credit bureau builds itself. And selective-disclosure proofs (SD-JWT, BBS) let an agent show “1,000+ settled contracts, under 1% disputes” without naming a single client.

Machine speed and recursion

Two more borrowed patterns make the economics work at agent tempo. Contract channels are Lightning, for work: open one master escrow, stream thousands of micro-contracts off-ledger, net-settle on close. Contract formation drops to effectively zero cost, so hiring can happen inside an inference loop. Channels also inherit Lightning’s hardest operational lesson, which is that someone must be watching during the challenge window or an offline party can be defrauded with a stale state. So monitoring is delegable to watchtowers, exactly as Lightning’s BOLT 13 draft does it. Sellers can also start work before contract finality, speculative execution with rollback priced into the bond.

Machine-speed mechanics: contract channels and optimistic settlement

Now the parent field. A contract can spawn child contracts, so a prime contractor decomposes a job into a tree. Bonds sit at every node. A failed leaf slashes upward until the buyer’s remedy is covered. And the root attestation carries a Merkle commitment over every child attestation, so a single signature proves an entire delegation hierarchy. Authority flows down the act-chain and accountability flows back up it. Insurers get a per-node price surface to underwrite, which is a liability market for machine labor, born the day someone quotes the first premium.

The Merkle contract tree: recursive subcontracting with cascading liability

One more thing, because markets of millisecond actors fail like flash crashes rather than recessions. The protocol carries its own circuit breakers: velocity caps per identity, position limits, and CAEP-triggered market-wide halts. The SEC of the machine economy will be a policy engine subscribed to a signal feed.

Nothing here is invented, and that’s the point

Every element maps onto something already shipping. Discovery via /.well-known/pact.json (RFC 8615, sitting right next to the server and agent cards from Part 1). DIDs and signed cards for identity. Act-chain token exchange for authority (RFC 8693). JWS and JCS for signing. x402 plus AP2 mandates for settlement, AuthZEN for approvals, CAEP for revocation, Kleros-style juries and TEE or zkML for proof. PACT contributes exactly one missing object, the contract, and composes everything else.

A seller advertises what it can do at /.well-known/pact.json:

{
  "pactVersion": "0.1",
  "roles": ["seller"],
  "verification_tiers": [
    "T0-reexec", "T1-tee"
  ],
  "settlement": ["pact-escrow"],
  "channels": true,
  "min_bond_pct": 10,
  "attestation_jwks": "…/jwks.json"
}

One distinction worth being precise about: this card is static discovery, telling you who I am and which roles, tiers, and rails I support. The call-for-bids and the sealed bids are different animals entirely, being dynamic, per-auction, signed protocol messages with their own media types in the draft. The card tells you whom to invite. The messages run the auction.

PACT has neighbors, and that’s good news

While writing this I went looking for parallel efforts and found the layer already stirring. VCAP (draft-stone-vcap) does marketplace-mediated escrow with verify-then-release settlement. AGTP builds an agent transport with runtime negotiation. An early Agentic Dispute Protocol exists, ATEP proposes a portable “agent passport” for track records, and ERC-8004 put on-chain agent identity and reputation registries on Ethereum mainnet in January. Even DeepMind’s Virtual Agent Economies paper from September 2025 calls for auction-based allocation and verifiable reputation as the design agenda for agent markets, though at the economics level and without a wire protocol. The neighborhood has kept growing since: Virtuals’ on-chain Agent Commerce Protocol pairs escrow with evaluator agents, ERC-8183 standardizes client, provider, and evaluator transactions on Ethereum, the RAILS paper develops verification-native clearing with graded verifier classes, and Stripe’s Machine Payments Protocol from March 2026 gives x402 a second major rail, which is exactly why PACT’s settlement bindings are deliberately rail-agnostic. I read all of this as confirmation the gap is real. Multiple people are digging at it from different sides.

Where PACT stakes out its own ground: no marketplace in the middle, auctions instead of negotiation, pay-then-challenge instead of verify-then-release, bonded liability that survives subcontracting, and reputation derived from settlement rather than declared. Attestations can then be exported into an ATEP-style passport or anchored in an ERC-8004 registry, and the escrow profile picks up where x402’s deferred scheme leaves off. Composition, not competition. The draft cites and differentiates each of these, and if their authors are reading, I’d like to compare notes.

The draft, and three predictions

I’ve written the full strawman up properly, and as of this week it isn’t just written, it’s submitted. draft-laxsharma-pact-00, “PACT: A Contract Layer for Autonomous Agent Commerce” is live on the IETF Datatracker, with the spec, JSON Schemas, and hash-verified examples at github.com/pact-spec/spec. If you work on A2A, x402, AP2, or agent infrastructure and this collides with problems on your desk, I want to hear where it’s wrong. That isn’t politeness. A -00 draft is a request for demolition.

Three falsifiable predictions, so you can hold me to something. By mid-2027: an escrow or conditional-settlement extension ships in the x402 ecosystem; some standards venue, whether an IETF side meeting, a W3C community group, or a Linux Foundation working group, charters agent work-contracts as an actual item; and someone announces the first insurance product for autonomous-agent liability. If all three miss, the thesis was wrong, and I’ll write that post too.

The last two years wired the agentic web and made it trustworthy. Whether it becomes an economy gets decided next, and economies don’t run on tasks and tokens. They run on contracts.

References