# Why agentic products break your cost model Teams building AI features usually cost models cost a simple assumption. One user sends one request and the model generates one response. You multiply that by your daily active users, add some margin, and call it your infrastructure budget. That model works fine for features to an extent, but It breaks completely for agents or agentic workflows. ### What changes? A plain feature is usually a single inference event. A user clicks generate, the model responds, done. The cost is predictable, bounded, and scales linearly with usage. An agent is a loop. It receives a task, reasons about it, takes an action, observes the result, reasons again, takes another action, and keeps going until the task is done or something breaks. Each step in that loop is an inference event. Each inference event costs tokens. And unlike a feature, you don't always know how many steps the loop will take before it starts. ![](https://cdn.hashnode.com/uploads/covers/5fd4714295130967e09927bf/524b802f-c503-4336-b697-80d4cec4dc01.png align="center") ### Three things happen in agentic systems that don't happen in features. **Context accumulates:** Every step in an agent loop adds to the context window; tool outputs, intermediate reasoning, observations from previous actions. A task that takes twenty steps has a context window that grows with each one. The twentieth step is more expensive than the first because it's processing everything that came before it. You're likely not paying for one request. You're paying for the sum of all requests, weighted by the growing context at each step. **Errors multiply cost:** A feature that fails costs you one inference. An agent that goes down the wrong path costs you every inference it took to get there before it either recovers or gives up. A well-designed agent has error handling. A poorly designed one runs in circles until it hits a token limit or a timeout both of which cost more than the task was worth. **Tool calls compound:** Agents use tools e.g search, code execution, API calls, file reads. Each tool call triggers another round of inference to process the result. A task that looks like ten steps might involve thirty inference events by the time tool outputs are processed. The cost you modelled for the task and the cost you actually paid are different numbers. ### Inference cost becomes a product problem in three specific ways. **Pricing:** If you're building a product where users pay per task or per outcome, your cost model needs to account for the variable number of inference events per task. A task that completes in three steps and a task that takes fifteen steps have the same surface-level appearance to the user. Your pricing needs to handle both. **Guardrails:** Without hard limits on steps, context length, and tool calls per task, a single runaway agent can cost as much as a thousand normal feature requests. Setting those limits is a product decision, how long is too long, what's the maximum cost per task you're willing to absorb, when do you surface an error to the user versus let the agent retry. **Model routing:** Not every step in an agent loop needs a frontier model. Intermediate reasoning steps, tool selection, simple observations, these can often be handled by a smaller, cheaper model. Reserving the frontier model for steps that genuinely need it is the cost lever most agentic products haven't pulled yet. ### This is where it gets commercially uncomfortable. Most SaaS pricing was built for a world where the cost of serving a customer was predictable. Seat-based pricing works when your cost per seat is stable. Usage-based pricing works when you know what a unit of usage costs before you price it. Outcome-based pricing sounds like the obvious answer for agentic products i.e charge for the resolution, not the compute, until you realise that the cost of a resolution varies wildly depending on how complex the task was, how many times the agent had to retry, and how long the context grew before it finished. The teams struggling most right now are the ones who added agentic AI features to an existing SaaS product without revisiting their pricing model. They priced the feature like a standard AI add-on, a flat monthly fee or a usage cap, and then discovered that one power user running complex multi-step workflows costs as much to serve as a hundred light users. The unit economics that worked at feature level may stop working at agent level. There's no clean answer to this yet and the teams getting closest are doing things differently. They're setting hard compute budgets per task and surfacing them transparently to users e.g "this task will use approximately X credits." They're tiering by task complexity rather than by seat or by raw usage; simple tasks are cheap, complex multi-step tasks cost more, and the pricing reflects that. And they're investing in the model routing and guardrail work that keeps their cost per task predictable enough to price against in the first place. ### Considerations before shipping any agentic feature What is the maximum number of inference events this task could trigger, what is the maximum context length at each step, and what does that cost at the volume we're targeting, and is that number something we can price against? If the answer is "we don't know," that's the answer you need to fix before you ship. Not after the infrastructure bill arrives and definitely not after you've already told customers what it costs. Agentic products don't break cost models by accident. They break them because the cost model was built for something simpler than what got shipped.