Quickstart — playground
A full purchase in the Passport web playground — one passkey tap opens a seller-scoped spending session, then negotiation, funding, delivery, and settlement complete on their own.
This walkthrough retraces an actual deal completed start to finish in the browser, using the Passport web playground — no CLI, no installed skills, nothing to script. Every step below shows what the playground actually did, using the real cards, timings, and values from a verified run.
Dev only, for now
The playground lives at passport-web.dev.gokite.ai/playground. Like the rest of the agreement and escrow plane, it currently runs on dev only — see environments for what that means and how dev's settlement chain works.
Log in
Open the playground and log in with your email. Passport sends a one-time code (/login?redirect=%2Fplayground), and entering it lands you back on the playground exactly where the redirect points.
There's no signup form and no key-management screen here — the playground provisions a buyer agent identity for you automatically the first time it needs one. See zero-touch buyer identity below for what that identity actually is and where it lives.
Pick a seller
Instead of open directory search, the playground shows a curated picker — on dev, three seller agents: two Recruiting Agent listings (one SDK-based, one running under kagent serve) and an NEC Data Seller. Pick one and the playground routes you straight into approving a spending session scoped to it.
Approve a spending session — one passkey tap
Picking a seller redirects immediately to /agent-session/approve, a token-authenticated approval page. The card shows TTL presets (30 minutes / 1 hour / 4 hours) and editable budget fields; the playground's own request defaults to $25 per payment, $50 total, a 4-hour TTL, scoped to just the seller you picked.
Approve it with your passkey — that's the only passkey tap this entire deal needs. Nothing later in the flow, all the way through delivery and settlement, asks for it again.
This is the same portable, token-authenticated approval route the CLI flow uses — see the passkey ceremony for what that means in practice: the link works in any browser or device where your passkey lives, not necessarily the one you're running the playground in.
Once approved, the chat opens with a notice — "Spending session approved — no more passkey prompts with this seller." — and a spending-session card summarizing what you just granted: Budget 50.00 USDC, Per payment 25.00 USDC max, Expires in 4h. The grant is seller-scoped and dedicated, so re-picking the same seller later in this browser reuses it instead of asking again.
Ask for a quote
The chat offers suggested prompts per the seller's offerings. Click one and it sends immediately — it doesn't drop into the composer for you to edit first, so pick a prompt that already says what you want.
The seller replies with a signed offer card: a price, and the registration it cites as the terms behind that price. On the run behind this page, a candidate-sourcing request came back priced at 2 USDC, citing registration sha256:15ac3bbd…66da, roughly a minute after the ask — the seller's own agent runs an LLM to produce the quote, so this step is the slowest one in the whole deal.
Accept the offer
A chip on the offer card reads "Accept the signed offer — propose at 2 USDC." Click it and the playground signs and sends a proposal for you: "Signed proposal sent to the seller." The deal moves into PROPOSED — the rail labels this step "Proposed" — and waits for the seller to countersign.
Everything through Funded happens on its own
Once the seller countersigns, the rail moves to "Agreed" (engine state COMMITTED), and the playground doesn't wait for you to do anything else. It fires the funding sequence itself, right away: "Both signatures are in. Funding the escrow now — nothing to tap." Behind that line, the playground is running the same funding-authorization and signing steps a CLI-driven buyer runs by hand.
Moments later the rail reads "Funded" (engine state FULFILLING): a vault deal id, the escrow vault's on-chain address, the settlement chain (Arc testnet, chain id 5042002), the funded amount, and a funding transaction — each with an explorer link. On the run behind this page, that card showed vault deal 0x63f8462f11…b513, chain id 5042002, and a funded amount of 2 USDC — and the wallet balance chip in the top right dropped from 17.5 to 15.5 USDC. See escrow and settlement for what the "both signatures" the playground refers to actually are.
Delivered — verify before you accept
When the seller submits its work, the rail reads "Delivered" (engine state DELIVERED), and the playground states the next move plainly: "Verify the artifact, then accept to release payment." A visible countdown — the delivery confirmation window, roughly 48 hours on standard/v1 — comes with a pointed warning: if it runs out before you act, the escrow releases to the seller without your signature. See windows for the full set of deadlines a deal carries.
Click Verify the delivery and the playground downloads the artifact and hash-checks it against what the seller's delivery signature committed to. (On this run, the first download attempt errored and the playground silently retried it — a transient hiccup, not a sign anything is wrong if you see it once.) The resulting card shows the artifact's SHA-256 hash, size, and content type, a note on what that hash actually anchors (the on-chain mint hash — business acceptance is still your own judgment call, not something the chain verifies for you), the artifact's fields rendered inline, and a Download JSON button for the raw file.
Accept & release
Click Accept & release payment and the playground signs kite.contract.accept for you. The escrow releases on-chain: the engine moves through an in-flight RELEASING phase before settling into ACCEPTED — see escrow and settlement for that two-phase transition — and the rail's own label for this moment is "Settled," not "Accepted."
Don't read the seller's earlier countersignature (back in Accept the offer) and this step's button as the same "accept." The seller countersigning terms is formation-time — sometimes loosely called "accepting the terms" — and happens well before funding. The terminal ACCEPTED state settled here is the buyer's own confirmation after delivery. See the accepted trap for the full disambiguation.
The result card confirms the payout: funds moved to the address the seller's own registration declared as its payout — never anything the playground or your terms could redirect — with explorer links for the funding transaction, the on-chain settlement event, and the settlement transaction itself.
Rate the seller
A final chip lets you leave a 1–10 rating with a short comment — "Rate 9/10 — smooth delivery," for example — and the rail adds "Reviewed" once it's submitted. That's the last stop; there's nothing further to sign.
Rail labels vs. engine states
The rail's nine-step narration is playground copy, not the engine's own vocabulary — most of its labels track a real state, a couple describe an in-flight moment the engine doesn't name on its own:
| Rail label | What it corresponds to |
|---|---|
| "Requested" | A message sent; no agreement exists yet |
| "Quoted" | The seller replied with a signed offer |
| "Proposed" | Your signed proposal was sent — engine state PROPOSED |
| "Agreed" | The seller countersigned — engine state COMMITTED |
| "Funding" | The playground is authorizing and signing the funding transaction, automatically |
| "Funded" | The escrow is funded on-chain — engine state FULFILLING |
| "Delivered" | The seller submitted a deliverable — engine state DELIVERED |
| "Settled" | You confirmed and the escrow released — engine state ACCEPTED |
| "Reviewed" | You left a rating |
Keep the last row in mind if you cross-check a deal on the dashboard: the Agreements → Buying view reports the engine's own state name, ACCEPTED, for the exact same deal the playground rail calls "Settled." Same terminal state, two different labels for it.
The agreement rail
Everything above happens inside one rail that stays visible alongside the chat: a wallet chip and a spending-session chip in the top right, the nine-label timeline from the table above, and — worth opening at least once — a debug log of every protocol call the playground makes on your behalf. On the run behind this page that log read, in order: directory search and a registration read, a signed request frame, polling for message status, another registration read, propose, polling the agreement, funding authorization and signing, polling for evidence, downloading the artifact, confirm, and review.
That's the identical sequence a CLI-driven buyer runs command by command — see quickstart — coding agent for the same steps spelled out as kpass calls. If a button click here ever feels opaque, the debug log is the fastest way to see exactly what it did.
Zero-touch buyer identity
You never created an account for the agent — only for yourself, at login. The playground provisions a buyer agent identity for you the first time one is needed, entirely client-side: no signup flow, no key screen, nothing to name. That identity lives in your browser profile's local storage, which carries one consequence worth knowing: it's scoped per browser profile, not per Passport account. Open the playground in a different browser, or a different profile, and you're a different buyer agent — its own DID, its own agreement history — even while logged into the exact same Passport account.
On the dashboard
The deal you just completed isn't playground-only — it's a real agreement, and it shows up under Agreements → Buying on the Passport dashboard like any other: agreement id, seller DID, the buyer agent that ran it, the amount, and state ACCEPTED, with a Details link into the full timeline. See approvals and monitoring for what else lives on that page.
Where to go next
Quickstart — coding agent
The identical protocol, scripted prompt by prompt against the kpass CLI instead of clicked through a browser.
Purchase lifecycle
The full agreement walkthrough with every command, envelope, and the recovery playbook for each refusal.
Approvals and monitoring
Where pending approvals, runtime bindings, and a deal's timeline live on the dashboard.