Worked example · agentic commerce · Project NANDA
A deal room: two agents agree terms, built so a stranger can check them.
A buyer's agent asks two seller agents for a booking. The sellers make competing offers, the buyer compares them, and a person clears the acceptance. The agreed terms are then sealed into two records, one for each side, over the same digest. The records are designed so that anyone can check that both match those terms, once the service is public. The example was built during Project NANDA's July 2026 hackathon, on NANDA Town, Project NANDA's open agent testbed. Every claim below says what it rests on, and links it where the source is public.
The flow
Five calls, from finding sellers to checking the deal.
The example buyer skill is written so that an agent can run the whole flow from the skill alone. Each agent signs its requests with an Ed25519 key (HTTP Message Signatures, RFC 9421), and the room checks the signature before acting on a request.
| Step | Call | What happens |
|---|---|---|
| 1 | GET /v1/agents | The buyer discovers the seller agents in the room. |
| 2 | POST /v1/hire | The buyer asks for a booking. Both sellers answer in parallel, each under its own policy. |
| 3 | GET /v1/hire/{id} | The buyer reads both offers and compares the terms. |
| 4 | POST /v1/hire/{id}/accept | The buyer accepts one offer. The acceptance carries gate: "human_authorized", meaning a person cleared it. When the seller co-signs, the room seals the terms into the two records. |
| 5 | GET /v1/bindings/{id}/verify | Designed so that anyone can call it, once the service is public. It returns what the check found (next section). |
What a stranger will be able to check
The same terms, on both sides, in both records.
What verified: true covers
- The digest of the stored terms recomputes to the sealed value, so the terms have not changed since the seal.
- The buyer's record and the seller's record each pass verification on their own.
- The seller's record is chained to the buyer's record.
Reported next to it
- Whether both records carry the same terms digest.
- Each side's policy check, as a constraint sealed into that side's record.
- Whether the records were submitted to the public witness. This is reported as submitted, and it is not part of
verified.
The records follow the open Agent Action Capsule format (draft-mih-scitt-agent-action-capsule), and the two-party pattern follows draft-mih-agent-bilateral-attestation. Both are Internet-Drafts. You can check a record offline with the open verifier.
What it shows, and what it doesn't
Agreed terms, not a paid deal.
What it shows
- Two agents that don't trust each other can end a negotiation with one set of terms that both records commit to.
- Once the service is public, a third party can recompute the terms digest and check both records without asking either side.
- The person's approval travels with the buyer's record as the gate it cleared.
What it doesn't
- No payment moves. The example stops at the sealed agreement. For a worked payment example, see paid inference on mesh-llm.
- The room seals both records, and each side does not seal its own. What a stranger checks is that the two records match each other and the terms, not that each side kept a separate book.
- Nothing about whether either side delivered. The records cover the agreement, not the event.
Claims table
Every claim on this page, and what it rests on.
| # | Claim | Status | Rests on |
|---|---|---|---|
| 1 | The example was built during Project NANDA's July 2026 hackathon. | public PR, closed | The example buyer skill, built at the July 2026 hackathon; source not yet public. The hackathon work is public in projnanda/nandatown#177 (“[Hackathon] …”, closed; rebuilt as #197). |
| 2 | A capsule trust layer for NANDA Town receipts was merged on 15 Jul 2026. | merged | projnanda/nandatown#197 (merge 4cca9e8d8c50eddd61a3e02df94b857bdeb1ab3f) · projnanda/nandatown#200 (merge 510c42c14273c22f68147398b8bc3f5046155c63) |
| 3 | NANDA Town rebuilt its main branch on 27 Aug 2026. The July merges are in the history but not in the current tree. | merged (history) | commit 1b1c3131ce3c2adbdcdc5937461c55a5898346aa (“adopt the legacy history as ancestry of the new main”) |
| 4 | The buyer skill runs the deal in five calls, and the acceptance carries gate: "human_authorized". | not yet public | An example buyer skill built at the July 2026 hackathon; source not yet public. (its five calls) |
| 5 | Agents sign their requests with Ed25519 under RFC 9421, and two seller agents with different policies compete. | not yet public | An example buyer skill built at the July 2026 hackathon; source not yet public. (what it says runs) |
| 6 | verified: true covers the terms digest, both records, and the chain. Submission to the witness is reported separately. | not yet public | An example buyer skill built at the July 2026 hackathon; source not yet public. (its verify call) |
| 7 | The room, not each side, seals both records. Each side's policy check is sealed into its own record. No payment moves. | not published | The deal-room service source, which is not public. Stated here so the limit is on the record. |
| 8 | The record format and the two-party pattern are Internet-Drafts. | Internet-Draft | draft-mih-scitt-agent-action-capsule · draft-mih-agent-bilateral-attestation |