There's an HTTP status code — 402, "Payment Required" — that's been reserved since 1997. Nobody used it. A protocol called x402 finally does, and I built a small service on top of
it to see what agent commerce actually feels like in practice.

Agent Cookies is a single API endpoint. An AI agent POSTs to it, pays $20 USDC on Base through the x402 flow, and Goody ships a box of cookies to whoever the agent specifies. No
accounts. No API keys.

How x402 works

The agent sends a normal POST request. The server responds with a 402 and includes the price, currency, and payment address in the response. The agent's HTTP client handles it from
there — it constructs a USDC payment, signs it, and replays the original request with the receipt in a header. The server verifies the receipt and lets the request through.

On my end it's one wrapper:

export const POST = withX402(
postHandler,
getSendCookieRouteConfig(),
getX402Server()
);

postHandler only ever sees paid requests. The 402 negotiation happens before my code runs.

The client side

The agent wraps fetch with an x402 payment client:

const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, {
    schemes: [{
      network: "eip155:84532",
      client: new ExactEvmScheme(account)
    }]
  });

  await fetchWithPayment("https://agentcookies.com/api/send-cookie", {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "idempotency-key": randomUUID()
    },
    body: JSON.stringify({
      recipient_first_name: "Sarah",
      recipient_last_name: "Chen",
      mailing_address: { address_1: "123 Main St", city: "San Francisco", state: "CA", postal_code: "94105", country: "US" },
      variants: ["Space Brownie"],
      message: "Your AI thought you deserved cookies.",
      from_name: "Agent"
    })
  });

The first call gets a 402. The wrapper pays and retries. From the caller's perspective it's just a fetch that works.

What's behind the endpoint

After payment clears, it's a normal web app. Validate the body with Zod. Check the idempotency key against Postgres. Call Goody. Record the result. State machine in the database:
payment_verified → fulfillment_started → fulfillment_succeeded or fulfillment_failed.

About 1,200 lines of TypeScript. Prisma, Postgres, Vercel. No queues, no workers.

There are no user accounts. The payer address comes from the payment signature. If you paid, you're in. The idempotency key prevents double-charges.

llms.txt

I also added an llms.txt — like robots.txt but for agents. It describes the endpoints, the pricing, the request format. An agent can read it and know how to use the service without
seeing a docs page.

I think this matters more than it seems. Agents don't browse documentation. They need a machine-readable description of what a service does and what it costs. llms.txt plus x402
together make a service that an agent can discover and pay without any human setup.

Why I built this

I wanted to see what it's like when an agent crosses from digital into physical. The agent does something on a computer and a real object shows up at a real address. Cookies were a
good choice because there's not much that can go wrong with cookies.

But the part I find interesting is the shape of it. An endpoint with a price. No signup, no integration, no partnership. Any agent with a wallet can pay. x402 is early but this
pattern — services that are natively payable over HTTP — seems like where things are headed.