How to catch a runaway AI agent before the bill does

First, know what boring looks like

You cannot detect an anomaly without a baseline, and almost nobody running an agent fleet has one. Before you configure a single alert, go pull two weeks of your agents' outbound transfers and write down four numbers: transfers per hour on a normal day, median amount, distinct recipients, and total spend over the fortnight. Four numbers. Ten minutes of work.

Do it per agent, not per fleet. A fleet-level average launders exactly the signal you want — one agent tripling its rate barely moves a number that six other agents are also contributing to. This is the same reason we attribute per wallet and keep saying one wallet per agent until people get bored of hearing it.

Now you have a baseline, and everything below becomes a comparison instead of a guess.

Three signals, fastest first

Rate. Transfers per minute against your baseline. This is the earliest and the sharpest, because a runaway loop's defining trait is frequency, not size. A 10x rate spike is visible within a minute or two of the loop starting, long before the total is interesting. If you only build one thing, build this.

Recipient concentration. Normal fleet traffic spreads across endpoints. A stuck agent hammers exactly one. Distinct-recipients-over-last-N-transfers collapsing toward 1 is a strong tell, and it's cheap to compute. It's also the signal that distinguishes "busy day" from "stuck in a loop," which rate alone sometimes can't.

Trailing total against a ceiling. This is the slowest of the three and the one everyone builds first. It's still necessary — it's the one that catches the slow bleed, the agent that's been 20% over its intended spend for three weeks without ever spiking. But treat it as the backstop, not the smoke detector. By the time a total crosses a ceiling, the total has crossed the ceiling.

Rolling windows, not calendar months

Use a trailing window — last 30 days, always ending now — rather than a calendar month. Calendar budgets have a structural flaw that's obvious once you see it: they reset. An agent that burns its entire month on the 28th gets a clean slate on the 1st and does it again, and your alerting agreed with it both times.

The rolling version has its own sharp edge, and we hit it ourselves: a 30-day trailing window includes spend from before you created the budget. So you can set a ceiling and be over it instantly, on a budget you made ten seconds ago. That feels like a bug and isn't one. The money was spent, the window is honest, and the alternative — quietly starting your window at creation time — would mean our number disagrees with the number you'd get by adding up your own transfers, which is worse. We show it as over, we tell you how much of it predates the budget, and we let you decide.

Pick the window to match your loop, not the calendar. If you top up a wallet weekly, a 7-day window tracks reality better than 30.

What you can build yourself in an afternoon

All of this is public chain data, and I want to be straightforward that you don't need us for the basic version. Point a script at an RPC endpoint, filter USDC Transfer logs where `from` is your agent's address, bucket by hour, compare against your baseline, POST to a Slack webhook when the count triples. On Base that's a modest amount of viem and a cron. On Solana you'll be parsing token transfers out of the transaction stream instead, which is more annoying but not hard.

What you'll spend your time on afterward is the unglamorous part: RPC rate limits, reorg handling, cursor state so a restart doesn't re-alert on everything it already saw, per-wallet catch-up when your job was down for six hours. That's most of the actual work, and it's the part we've already eaten. But the detection logic itself is a weekend, and if your fleet is two wallets, a weekend may genuinely be the right call.

If you build it, please put the cursor state somewhere durable and per-wallet. Ask me how I know.

What this means for your fleet

Order of operations, if you do nothing else: baseline four numbers per agent, alert on rate first, set a trailing-window ceiling as your backstop, and make sure the alert reaches somewhere you'll actually look at 3am rather than a dashboard you open on Tuesdays.

And know what this class of tooling does not do. Every signal above is observational — it fires after the transfer has settled on chain. Nothing here refuses a payment. If your requirement is that the spend cannot happen, you're shopping for an enforcement layer that sits in your agent's request path, and you should go do that instead of layering alerts on top of a hole. Visibility is the right tool when the failure mode is "I didn't know," which, in every story I've read, it usually is.