Never Click Pay: The One Rule That Let an Agent Work in Production

Back in August I let an AI agent drive live third-party web systems inside real production accounts — the same accounts that hold real production data — across several days. It filled in forms. It walked checkout flows to the exact screen where money changes hands. It screenshotted that screen and stopped.

Total submissions completed: zero. Total charged: zero. Total records belonging to anyone else touched: zero.

The whole thing worked because of one rule, and the rule was not "be careful."

Why the agent had to touch the real thing

One of my businesses depends on my team working through a long list of separate external systems, each one a different vintage of web software, each with its own quirks, required fields, and traps. Our internal runbooks for those systems had drifted out of date. I wanted them rebuilt accurately.

The obvious approach is desk research: read the published documentation, read the pages that describe what each step costs, write it down. I tried that. It produced confident, well-organized documents that were wrong in the places that mattered — an amount listed on a public page that isn't what the cart actually charges, a form that asks for something the documentation never mentions, a flow with a step that only appears if you picked a certain option three screens back.

Those are not exotic edge cases. They are the difference between a submission that goes through and one that comes back rejected, with someone waiting on it the whole time.

There is only one place the truth lives on a system like this, and it's the checkout screen. So the agent had to go there. Not to a sandbox — these systems don't have sandboxes — but into the live account, with a real session, all the way down.

That's an uncomfortable place to put an agent. One bad click commits an irreversible submission, or charges a card, or disturbs something belonging to a counterparty. Submissions on these systems are not undo-able. Neither are payments.

So before any of it started, I wrote down the boundary.

Four rules that never bent

The agent worked under exactly four standing rules, and they applied identically in every session:

• It may reach the final Submit, Pay, or Checkout screen and capture it. It may never click it. Not once, not under any circumstance, not if the screen looks harmless.
• It never enters login credentials. A login page is a full stop; it hands the session back to me.
• It never solves a CAPTCHA. Same handling — stop and wait for a human.
• All test data is obviously fake. A fixed placeholder name and address pattern, the kind nobody could mistake for a genuine record at a glance.

Notice what's missing: judgment. There is no rule that says "use discretion near payment." The agent is not asked to evaluate whether a particular Pay button is safe to press this time. The button is categorically off-limits, the way a guard over a saw blade is off-limits — it's a physical fact about the machine, not a sticker reminding you to be attentive.

That distinction is what made the rest of the week uneventful. A best-effort caution guideline gets re-interpreted on every screen, and it only has to be re-interpreted generously once. A mechanical stop-gate gets interpreted zero times.

I've written before about giving agents zero credentials of their own and putting narrow sub-agents in front of each external system. This is the same instinct pointed at a different target: not who holds the keys, but which specific physical action is never taken, by anything, ever.

The rule got tested by accident

I didn't stress-test the guardrails. The week did it for me.

Halfway through a payment-adjacent flow, the browser connection dropped. The agent came back to a session it could no longer reason about with confidence: a short form partly complete, an unknown amount of state sitting on the server, and a system that imposes its own session timer and had likely killed the session anyway.

There's a tempting move there, which is to resume — work out where you probably are and continue from the middle. The agent didn't, because the rules don't leave room for probably. It abandoned the flow and redid the form from scratch.

That cost a few minutes. The alternative cost is a completed submission nobody wanted.

That's the real payoff of a mechanical boundary, and it's easy to miss: it decides in advance what your worst day looks like. With one bright line, a disconnect degrades into a redo. Without it, the same disconnect is an incident with real money and somebody else's record attached. The failure mode was safe by construction, not by luck — the same principle behind building automation that survives contact with reality.

The same logic covers credentials and CAPTCHAs. Both route back to me as an explicit stop-and-wait, and the handoff is cheap — a few seconds of my attention, a handful of times a day. I could have automated around either one. Automating around them means the agent gets better at operating unsupervised in exactly the places where supervision is the entire point.

Cleanup is part of the contract

Reaching a payment screen and stopping leaves debris: items sitting in a cart, half-finished drafts parked in an account. Leaving that behind is how the next person gets confused, and confusion in a production account is how accidents happen.

So every walkthrough ended with the agent emptying its carts and deleting the drafts it had created.

Its own drafts. Only its own.

Anything that already existed in the account when the session started was left strictly untouched, no matter how abandoned or stale it looked. A shared production account can hold real, irreplaceable work belonging to someone else, and deletion on these systems is permanent. "It was probably nothing" is not a standard you can apply to something you can't get back.

That's a second mechanical rule sitting underneath the first: don't delete what you didn't create. Between the two of them, the agent could operate at full speed for days and the worst thing it could leave behind was a screenshot.

The wall no amount of cleverness got through

One legacy system beat it outright.

The flow ran through an old form wizard with a text field that masked its own display and silently rejected anything that wasn't a genuine human keystroke. Typed text, JavaScript setting the value directly, finding and setting the hidden field underneath that stored the real unmasked value, firing a synthetic blur event to trigger the site's own validation check — every approach failed in a new way. Poisoned asterisks. Doubled text. A stale session locking the value. The Next button just refused to advance and displayed no error at all.

Roughly three hours went into that one field across two sittings. In the middle of it the browser extension disconnected, the site's own thirty-minute wizard timer expired, and the whole thing had to be restarted from the first screen. It took a second day before the field came unstuck.

What unstuck it: I typed two fields by hand and clicked Next. It worked immediately, and the agent drove the rest of the wizard — every remaining field and confirmation step — without a complaint.

That wasn't a bug in the tooling. It was a site built specifically to detect and reject automation, and it was doing its job. The mature response to a wall like that is a fast human-handoff protocol, not open-ended debugging. Budget for the fact that any browser-automation project will hit one.

The trap went straight into the shared playbook: on this system, don't fight that field, ask a human for ten seconds of typing. Every new failure mode found that week went into the same playbook, which is why each run was faster than the one before it. The expensive part of this work is not the clicking. It's discovering the trap the first time.

The ledger

Across the whole run — every system in scope, several distinct flow types walked end to end inside live production accounts:

• Zero submissions completed.
• Zero charges made.
• Zero records belonging to anyone else touched.
• Zero occasions where the boundary had to be argued about, including during multi-hour sessions and repeated tool failures.

The runbooks were rebuilt from what those systems actually do rather than what they claim to do. That was the deliverable, and none of it required the agent to complete a single transaction.

The transferable rule

If you're putting an agent inside a live system with financial or legal consequences — a payment console, a bank portal, a CRM full of real customer records, a vendor account with a card on file — do not hand it a list of cautions. Pick the single irreversible action and make it mechanically untouchable. One specific button. One specific field. Something the agent cannot decide is fine today.

The agent can then do the tedious 95% autonomously and hand back control at the one moment consequence arrives. That isn't a limitation of the technology; that's the shape of a system you'd let near production at all. When you're evaluating an AI agent for operational work, that shape is the thing to look for, and its absence is the thing to walk away from. The overnight counterpart — an agent with a short, explicit rule list working unattended while I slept — is what fifteen hours of autonomous QA looked like.

I let an agent inside real production accounts for days, and the whole thing was uneventful because one button was untouchable. For companies in Dubai and across the UAE this lands on a live nerve: the obvious places to put an agent are finance operations, procurement, HR and customer support, and every one of them contains a handful of clicks — releasing a payment, issuing a refund, approving a purchase order — where "we told the AI to be careful" is not an answer anyone wants to give afterwards. Working out where the bright lines belong in your own systems before you let an agent near them is a consulting day's work. Book a consulting day or send me an inquiry first if you'd rather talk before booking.