My AI fills the cart. I tap checkout.

An earlier post described the contract for my metal-casting project: the assistant researches, messages and negotiates; money stays with me, cash, in person. Until this week the assistant could look at a shop but never touch it. It produced carts as lists of links, and I clicked through them myself.

This week it got hands. I gave the assistant access to my logged-in shopping sessions and granted a new contract tier: it fills carts and verifies live prices and stock. Checkout stays mine. It loads the cart; I tap buy.

The guard is code, not a prompt

The obvious objection: you gave an AI a logged-in shopping session. What stops it from buying things?

Not a system prompt. A prompt saying “don’t check out” is a request, and requests get misread, forgotten, or reasoned around. The guard here lives in the automation layer itself: the tool that drives the browser cannot navigate to checkout or payment surfaces. Not instructed not to: it cannot. Those routes are unreachable in the code, the same way the messaging bridges enforce disclosure in the adapter itself.

The model’s judgment is what you’re renting; the boundaries are what you build.

First run

The assistant attached to the logged-in session and loaded the cart with the purchases already decided from the morning’s research: casting supplies, nothing exotic. The interesting part was what it found while doing it.

Two prices had drifted overnight. One item was up 8% on what the research recorded. Another was up 18%, but back in stock, which mattered more, because the earlier survey had flagged it as nearly gone. The research those decisions rested on was hours old and already wrong in two places out of one cart’s worth of items.

That’s the point I hadn’t fully appreciated before: verification belongs at action time, not decision time. An agent that re-checks at the moment of action catches the drift for free. A carefully researched list of links is a photograph of prices that no longer exist.

The ladder

Zoom out and this is a rung on a ladder:

1. Read-only research. The agent looks, I act on everything.
2. Messaging: the agent speaks, disclosed, on my own channels, with money fenced off behind a queue.
3. Cart and verify, where the agent handles commerce surfaces up to the point of payment.
4. Not yet: a card with a tight limit and per-order approval, where the agent pays inside an envelope and I confirm each order.

The messaging tier has enforced disclosure and a proposal queue. The cart tier has a checkout wall in code. The card tier, when it comes, is the negotiation envelope applied to payments.

Nothing about the model changed between rungs. What changed is that I built a boundary I could verify, then granted the autonomy the boundary made safe. Capability was never the bottleneck. The bottleneck is always the same question: what is the worst this rung can do, and is that bounded by something sturdier than a promise.

Where it stands

The cart sits filled. I haven’t tapped yet; life intervened, as it does. The delay makes the point better than punctuality would have: by the time I do tap, those verified prices will be days old. So the contract’s newest clause covers exactly this: the assistant re-verifies at the moment of my tap, not the moment of its research. There’s now a written runbook for my one thumb-press, covering drift tolerances, stock-risk order and substitution rules, prepared by the same agent that can’t press the button itself.

That earlier post ended with the observation that the agent does the thinking and I do the showing up. Still true. The machine holds the cart steady, keeps the prices honest, and waits for the one input it structurally cannot supply.