# We gave our AI a card with a hard limit

Canonical: https://flusterduck.com/blog/we-gave-our-ai-a-card-with-a-hard-limit
Published: 2026-08-06 · The Flusterduck team

Before our detection agent ever ran unsupervised, we built it an accounting system. Notes on the least interesting thing we've shipped and why it is load-bearing.

The scary part of running an autonomous agent is not that it might be wrong. We verify its claims before anything gets filed; wrong is survivable. The scary part is that it spends actual dollars, on a metered API, from a loop that decides for itself how much work a night deserves, while every person who could stop it is asleep.

So before the agent ever ran unsupervised, we built it an accounting system. It is the least interesting thing we have ever shipped. I would rebuild it before I rebuilt anything else we own.

## Reserve first, call later

Every AI feature we run spends from a monthly pool, and the rule is identical everywhere: reserve the estimated cost before making the call, reconcile against the provider's actual numbers after. No reservation, no call.

The ordering is the whole design. The tempting version is call first, record after. Simpler, and the numbers are exact. But that version only keeps honest books when things go well, and the crash between the API call and the bookkeeping is exactly where you lose the plot. A limit that stops holding when the process dies is not a limit. It's a suggestion. Reserving first means the worst crash leaves us having spent less than the books claim, never more.

Second rule: everything fails closed. If the ledger cannot be read, the AI does not run that night. We eat the occasional quiet night we didn't intend, and in exchange there is no such thing as a loud month we didn't authorize. I will take that trade every time it is offered.

## The agent doesn't know money exists

One decision I'd defend anywhere: the budget lives entirely outside the model. No prompt tells the agent what's left in the pool. Nothing asks it to be frugal.

We tried the alternative early, briefly. A model that knows it should save money starts skipping the deep dive that would have confirmed the bug, and afterwards you cannot tell which conclusions were evidence-driven and which were thrift-driven. That ambiguity poisons everything downstream of it. So the agent investigates like compute is free, and the ledger cuts it off from outside when the month runs dry. Judgment in one system, spending authority in another. The same way you'd set it up for a person.

And when a pool does run dry mid-month, the product says so and falls back to simpler detection until the first. Degrading loudly beat both alternatives we considered, which were stopping silently and overspending silently.

## We're on the ledger too

Here's the part that gets a laugh when I explain it: our own company org runs under the same ledger, with a pinned budget. We dogfood everything, and internal testing is precisely the workload that drains a shared API account by accident. The month we capped ourselves, we caught two internal jobs spending several times what anyone believed. Both working exactly as designed. Nothing builds faith in your own limits like getting caught by them.

There is a bigger claim buried in this plumbing, and it is old. The public conversation about agents is capability, evals, alignment, safety. All of it matters, and I don't dismiss any of it. But the precondition for running one commercially, against a flat price, is that your books balance even when the process dies mid-transaction. Double-entry bookkeeping, applied to tokens. Centuries old. Still undefeated.

Our customers see none of it. No usage meter, no dollar anxiety in the dashboard, because the entire point of a flat price is that the anxiety is ours. The ledger is what makes that promise one we can keep.