Jul 28, 2026 · 7 min read

Agent Commerce implementation checklist: from zero to paid in production

The checklist we hand to teams going live with paid agents. Twelve items, in order, with the failure mode each one prevents. Skip one and that's the one that bites you.

  • #checklist
  • #production
  • #compliance
  • #budget

This is the same checklist we walk every team through before flipping a paid agent to production. Twelve items, in the order they bite you if you skip one.

Identity & keys

  1. Agent has its own wallet. Not a shared hot wallet. The agent’s keys live in a KMS or HSM, never in source. If the agent goes rogue, you rotate one wallet, not the company’s.

  2. Every agent has a stable agentId. It’s the join key for budgets, audits, and dispute resolution. Don’t derive it from a session — derivation breaks the audit trail when the session rotates.

Money ceilings

  1. perCall.usdMax is set, defaults sane. USDC’s 6-decimal bug is the #1 cause of overcharges we see. Cap at $0.05 unless your route genuinely costs more. See the risk cases post for why.

  2. perEndpoint cap exists. Without it, the agent that finds a useful tool will call it 40,000 times over a weekend. The cap is what turns “runaway” into “stop at $1.”

  3. perAgent daily cap exists. This is the backstop the CFO will ask about. The number itself matters less than that it exists and that someone gets paged when it crosses 80%.

Verification

  1. Settlement is verified onchain, not by the facilitator. Facilitator reports are optimistic. Chain is the truth. The after-settlement hook in @harpd/observe does this by default; if you’re not using the SDK, run your own check.

  2. Divergence fires an alert, not a retry. If facilitator and chain disagree, halt and notify — don’t retry. Retrying on a pending chain state is how you pay twice for one resource.

Idempotency

  1. Every payment carries an idempotency key. The key should be derived from (agentId, intentId, endpoint), not Math.random(). The collector dedupes on this — without it, retries become charges.

  2. The paid endpoint honors idempotency. If you control the server, return the cached result for a duplicate idempotency key. If you don’t, the agent’s local dedupe layer (in @harpd/observe) covers it.

Observability & audit

  1. Every payment emits before- and after-events. Not just after. The before event is your intent log — it’s what tells you, three weeks later, why the agent tried to pay $50 for a weather lookup.

  2. Events go to an immutable store. D1, Postgres with append-only triggers, S3 with object lock — something the agent itself cannot rewrite. Harpd’s collector uses Cloudflare D1 with write-once event rows. Auditability is a feature, not a side effect.

  3. There’s a reporting export a CFO can read. CSV or PDF, monthly, with per-agent totals and per-endpoint breakdowns. If your audit story starts with “let me run a query,” it won’t pass an audit. Harpd generates this export from the events table — schedule it, don’t build it.

The thirteen-th item you can’t skip

Have a kill switch. Somewhere in your agent’s control plane, there is a single flag that turns “spend money” into “refuse to spend money” across every agent, instantly. Not a budget tweak — a hard stop. You will need this at least once. Make sure you know where it is before you need it.

In Harpd, it’s the tenant-level paymentsPaused flag in the dashboard. Flip it once and every before-payment hook returns allowed: false until you flip it back. No code deploy, no agent restart.

What’s intentionally NOT here

  • No “predict spend.” We’ve never seen a model that predicts agent spend within an order of magnitude. Ceilings and alerts, not forecasts.
  • No “session-based billing.” Agents don’t have the kind of sessions that map to billable units. Per-call + per-agent cap is the right grain.
  • No “auto-recharge the agent wallet.” That removes the human from the loop entirely. The whole point of the audit layer is that a human reviews before more money enters the system.

Next