True story: an SME I know connected an AI agent to their CRM to "automate follow-ups." It automated follow-ups. It also automated 11,000 API calls in six hours, because nobody told it when to stop.
Everyone's worried about AI leaking their data. Fair enough. That's Book 1 of this series. But the quieter risk is the one hitting the P&L: the API token economy, and how fast a "smart" workflow turns into an open tab nobody's watching.
For decades, business owners have been conditioned by the predictable economics of Software-as-a-Service: a fixed number of seats, a flat monthly fee, an invoice you already knew the size of. Agentic AI shatters that predictability. The moment a workflow moves from a chatbot waiting for a human to type the next prompt to an autonomous agent executing its own multi-step plan, the financial model flips from flat-rate to consumption-based token billing. And nothing about that shift asks your finance director for a purchase order first.
An AI model doesn't read whole words. It chops everything into fragments called tokens, roughly four characters each. You're billed for input tokens (everything you send: the prompt, the attached document, the conversation history) and output tokens (everything it generates back). Vendor pricing looks negligible at a glance: fractions of a penny per million tokens. That's exactly where the trap is set.
A simple follow-up question can cost ten times more to process than the initial prompt, quietly running up an open tab on your corporate billing account without a single new asset being introduced.
The reason is the context window. In a multi-turn conversation, the system doesn't process just your new message. To maintain continuity, it resends the entire document plus the full history of every prior exchange, every single turn. A workflow costing pennies per isolated prompt can cost hundreds of pounds per run once that expansion, plus recursive error-handling, plus multi-document ingestion are factored in. Real workflows run 10 to 20 turns minimum. If your cost model assumes a single prompt, it's already wrong.
A chatbot is passive: a human types, reads, types again, and that human is a natural financial brake on token consumption. An agent is not. Given a high-level goal, it breaks the objective into sub-tasks, writes its own internal prompts, queries databases and APIs, and loops back to correct its own mistakes, all without anyone watching. It runs at machine speed, twenty-four hours a day, until stopped or capped.
Here's how the recursive loop trap actually forms: the agent hits an obstacle (a corrupted date field, a missing value in an API response) and rather than stopping to flag it, does exactly what it was built to do: it tries to fix the problem itself. New internal prompt, same error, new attempt, same error, repeated hundreds of times a minute, because the agent evaluates each retry as a fresh attempt rather than recognising a pattern of failure.
Monday morning: an unexpected five-figure invoice. No human saw a warning.
This is exactly what happened to a 40-person online retailer whose agent hit a legacy date format it couldn't parse, retried autonomously, and ran 14,000 API calls over a single Saturday night before anyone noticed. A six-person consultancy hit the same wall from the other direction: a regulatory database returning a null value the agent interpreted as an incomplete task, looping back to check the same source, receiving the same null, repeating indefinitely against a corporate API key with no spending ceiling configured. In both cases the agent's actual goal was sound. The problem was the complete absence of airbrakes.
Most SMEs evaluate an AI project purely on the vendor's advertised token price: the equivalent of buying a car based on the sticker price alone, ignoring fuel, insurance, and maintenance. A defensible Total Cost of Ownership has to include four layers most pricing pages never mention: the labour of cleaning and standardising your data before an agent can touch it reliably, token costs projected at realistic multi-turn depth rather than single-prompt, the human verification time every trustworthy workflow still requires, and the ongoing maintenance cost as vendors change their models and pricing underneath you.
True AI TCO = Data Preparation Labour + Projected Token Volume (at realistic turn depth) + Human Verification Time + API Maintenance and Drift. If that number exceeds the cost of the manual process it replaces, the automation is currently inefficient, so don't deploy until the formula balances.
None of this requires an enterprise budget or a platform engineering team. Three non-technical guardrails are the minimum standard for any business that connects a corporate payment method to an AI API account:
Hard spending ceilings at console level. Every major provider, OpenAI, Anthropic, Google Cloud, Azure, lets you set a soft alert threshold and a hard cutoff ceiling directly in the developer dashboard. Ten minutes to configure, free to set up. Not doing it isn't a time problem, it's a governance gap.
Model routing. Not every task needs your most expensive flagship model. Route routine, high-volume tasks (email classification, data tagging) to lightweight models, and reserve the frontier model for the final, client-facing output. Done consistently, this alone can cut total token spend by 60–75% with no perceptible quality loss where it matters.
Human-in-the-loop tripwires. A hard constraint coded into the agent's logic: after a defined number of consecutive failed attempts (ten is a reasonable default), the system stops, alerts a human, and waits. It converts an open-ended financial liability into a bounded, manageable pause.
Once a business masters this, technology spend stops looking like an unpredictable utility bill and starts looking like a competitive lever. Competitors racing to automate without guardrails are running flagship models on every task, letting context windows balloon unchecked, and absorbing recursive-loop costs they then have to pass downstream in higher fees. A FinOps-disciplined firm can undercut them on price while running at superior margins, or hold price parity and reinvest the difference into client quality. And the same procurement teams asking AI governance questions are increasingly asking financial governance questions too: a documented FinOps framework reads as a trust signal, not just an internal saving.
What's been genuinely good is the feedback coming back from readers, not just "nice book," but people telling me exactly what they need next. It's sharpening what goes into Book 5 (running this at team scale, 5–10 people) and Book 6 (built for freelancers and solo operators navigating client-side AI governance). If you've had your own "open tab" moment, or you're staring down one right now, I'd like to hear it. It might end up in Book 5 or 6.