Why Your Automation Needs a Hard Spending Limit, Not Just an Alert

A client once told me about a lead enrichment tool that looped on a bad record for six hours overnight. Every pass hit a paid API. By the time anyone noticed, the bill was in the hundreds of pounds for work that found nothing new. Nobody had done anything wrong. The automation just didn't know when to stop.

That's the problem with most automation and AI agent setups I see. They have monitoring. They have alerts. Someone gets a Slack message or an email if something looks off. But an alert only tells you after the spend has already happened. By the time you've read it, the money's gone and the only thing left to do is apologise to whoever owns the budget.

Where the spend actually comes from

Most business automation touches at least one thing that costs money per use. It's easy to miss because the individual cost looks tiny:

• SMS and WhatsApp reminders, usually a few pence each
• Email sending through a transactional provider, often billed per thousand
• AI model calls, priced per token and easy to underestimate
• Third-party data lookups (address validation, company checks, enrichment)
• Cloud compute that scales with usage, like queue workers or serverless functions

None of these feel dangerous at normal volume. The risk shows up when something loops, duplicates, or gets triggered far more often than intended. A webhook that retries without a limit. A scheduled job that doesn't check whether it already ran. An AI agent that keeps calling a tool because the task wasn't marked as finished. Small costs multiplied by an uncontrolled loop stop being small very quickly.

Why alerts alone don't help

An alert is a notification, not a brake. It tells you something happened, but the automation keeps running while you're reading the message, working out what it means, and deciding what to do. If the loop is fast (and with AI tool calls or API retries, it usually is) you could burn through a meaningful budget in the time it takes to open your laptop.

I've written before about giving automation a watchdog that checks its behaviour is sane. A spending cap is a specific, financial version of that idea. It's not about whether the automation is doing the right thing logically. It's about whether it's allowed to keep spending money, full stop, regardless of whether the logic looks correct.

What a real cap looks like

A spending cap needs to be enforced in the code path that actually makes the paid call, not somewhere upstream that can be skipped or miscounted. A few things I build in as standard when an automation touches anything billed:

• A per-run limit. If one job or one agent run is about to make its fiftieth API call when it normally makes five, that's a sign something's wrong, and it should stop itself rather than carry on.
• A rolling daily or monthly ceiling. Track actual spend against a number you've decided in advance, and refuse new calls once it's hit, rather than finding out at the end of the billing cycle.
• A kill switch that's easy to use under pressure. If you do need to stop everything at 11pm because something's gone wrong, that should be one action, not a hunt through several dashboards and config files.
• Separate limits for separate things. SMS spend, AI token spend and cloud compute spend should each have their own cap. Lumping them into one number hides which part is actually the problem when it trips.

None of this is complicated to build. It's a counter, a comparison, and a condition that stops execution. The reason it's often missing isn't technical difficulty, it's that nobody thought to ask for it when the automation was first scoped. Cost control gets treated as an afterthought, something you'll "keep an eye on," right up until the month it isn't.

AI agents make this more urgent, not less

This matters more as AI agents get handed real tasks: looking things up, calling tools, chaining several steps together to finish a job. An agent deciding on its own how many times to retry, or how many sources to check before giving an answer, doesn't have a natural sense of "this is costing too much." It has a goal and keeps working towards it. Without an explicit cap, "keep trying until it works" and "keep spending until it works" are the same instruction.

If you're building or buying anything that lets an AI agent make its own tool calls, the spending cap question is worth asking before launch, not after the first invoice surprises someone. Who sets the limit? What happens when it's reached, does the task fail safely or does it just stop silently? Can you see what it was about to do when it got cut off?

Building this in from the start

I design cost limits into the automations and integrations I build rather than treating them as a monitoring layer bolted on afterwards. It's a small amount of extra logic at build time, and it means the difference between a loop that costs you a few pounds and one that costs you a few hundred before anyone's awake to notice. If you've got a process running unattended right now, whether it's a scheduled job, a webhook, or an early AI agent, it's worth checking what actually stops it from spending without limit. If the honest answer is "nothing, we'd just see it on the bill," that's worth fixing before it's tested for real.