The Number in the Proposal Is Not the Number

Most enterprise AI agent projects get approved on a build cost. Someone puts together a proposal — internal team estimate, vendor quote, or agency scope — and a number lands in front of the budget committee. It gets approved. Work starts. And then, somewhere between six and eighteen months after go-live, the total spend looks nothing like that original number.

This happens consistently. Not because vendors are dishonest or because engineering teams are sloppy. It happens because the build cost and the operational cost of an AI agent are two fundamentally different things, and most organizations plan for the first while discovering the second.

This post is about what actually shows up in the budget after deployment. Not hourly rates or project scopes — those vary too much to generalize. The categories that almost nobody budgets for at kick-off, and why they tend to be bigger than expected.

Inference Costs Compound in Ways That Surprise Everyone

Token costs are the most common budget surprise. A team estimates usage based on demo traffic or early beta data, and then production load arrives. The two numbers are rarely close.

An agent handling a narrow, well-scoped task might run 2,000 to 10,000 tokens per session in a demo. The same agent in production, with real users sending longer inputs, triggering multi-step reasoning, running tool calls that feed back into the context window, and retrying on failure, can run 50,000 to 200,000 tokens per session. Multiply that by user volume and you get numbers that were not in the original model.

On top of base inference, agentic architectures make additional model calls that do not appear in simple calculator estimates: planning calls, reflection calls, tool-selection calls, validation passes. A multi-agent system with four specialized agents coordinating with each other is not doing four times the LLM calls of a single agent. It is often doing ten to twenty times, because each handoff generates coordination overhead.

A practical benchmark: analysis of enterprise support agents places ongoing inference at $2,000 to $8,000 per month for agents processing meaningful support volume. That is before infrastructure and engineering. Deloitte's review of agentic AI in banking notes that autonomous decision-making in production introduces cost structures that scale non-linearly with task complexity, which is a careful way of saying the meter runs faster than you think.

The mitigation is real: prompt caching, model routing, response caching for repeated queries. But implementing these correctly is engineering work that itself costs time and money, and it belongs in the budget from day one, not as a retrofit six months after launch when the inference bill arrives.

Integration Maintenance Is a Permanent Line Item

An AI agent that does something useful in production is almost always connected to external systems. CRM, ERP, internal APIs, third-party data sources, communication platforms. Each of those connections is a dependency that changes on its own schedule, independent of your agent.

Salesforce pushes an API update. Your cloud data warehouse changes a schema. A vendor deprecates a field your agent relies on for decision logic. A compliance requirement changes what data you are allowed to pass through a third-party endpoint. Each of these events breaks something in the agent's behavior, usually at a bad time.

The original integration build is one-time work. Integration maintenance is ongoing. Teams that ship AI agents without a maintenance budget discover this when something breaks in production and there is no owner, no budget, and no clear process to fix it fast.

A conservative estimate for a moderately complex agent with five to eight integrations: 15 to 25 percent of original development cost per year just for integration maintenance, security patching, and dependency updates. That number goes up if any of the connected systems are particularly volatile (internal microservices being the worst offenders) or if the agent operates in a regulated environment where audit trails and access controls need active maintenance.

Human Review and Escalation Costs Are Rarely Modeled

No production AI agent runs fully autonomously on its first day. Most should not run fully autonomously even after a year. The responsible way to deploy an agent that takes real action in the world, whether approving transactions, sending customer communications, or triggering workflows in core systems, is with a defined escalation path that routes low-confidence decisions to a human for review.

This is correct behavior. It is also a cost. Someone has to review those escalations. Someone has to maintain the thresholds that determine what gets escalated. Someone has to monitor the queue and respond within an acceptable latency window, because an AI agent that escalates and then waits six hours for human review is not actually solving the problem it was built to solve.

The size of this cost depends heavily on the agent's confidence distribution in production. If the agent handles 80 percent of cases with high confidence and escalates 20 percent, you need real human capacity. If your users are creative with edge cases (and they always are), that 20 percent can drift upward over time as new input patterns emerge that the agent was not trained to handle.

Most organizations model the agent as if it will handle everything. The actual production split should be modeled explicitly before go-live, and human review capacity should be budgeted as part of the AI system cost, not as a separate operational overhead that surfaces later as an unplanned headcount request.

Model Updates Break Things You Did Not Know Were Fragile

LLM providers update their models. Sometimes it is a minor patch. Sometimes it is a version bump that changes output formatting, reasoning style, or confidence behavior in ways that ripple through your agent's logic unexpectedly.

Prompts that worked reliably on one model version may produce different structured outputs on a later version. An agent that used to return clean JSON for a downstream parser now returns slightly different formatting and the parser breaks. A classifier that worked at a specific temperature now needs recalibration. These are not hypothetical scenarios. They are documented patterns that anyone running models in production has dealt with.

Managing model version upgrades requires testing infrastructure: evaluation suites, regression tests, golden datasets for comparison. Building that infrastructure costs time. Running it continuously costs engineering hours. Without it, every model update is a potential incident with no clear owner and no obvious fix timeline.

The pattern is consistent enough that Gartner has documented AI projects requiring significantly more ongoing maintenance than traditional software, a gap that reflects real costs accumulating in production rather than in pre-launch planning.

Observability Infrastructure Is Not Optional, and It Is Not Free

A production AI agent is a system that makes decisions. If you cannot see why it made a specific decision, you cannot debug failures, you cannot audit behavior for compliance, and you cannot improve the system over time. Observability is not a nice-to-have. It is the minimum viable condition for operating an agent responsibly in production.

Building proper observability for an agentic system means more than plugging in a logging library. It means tracing multi-step reasoning chains, capturing tool call inputs and outputs, recording confidence scores, tagging outcomes for future evaluation, and surfacing behavioral anomalies over time. That is a non-trivial engineering effort even with the best available tooling.

Off-the-shelf observability platforms for AI agents exist and are improving. But they require integration work, they carry their own licensing costs, and they do not eliminate the need for custom instrumentation in complex architectures. Budget somewhere in the range of $5,000 to $25,000 in initial setup, plus ongoing platform costs and engineering time for maintenance, depending on system complexity.

For regulated industries, observability is not just operational hygiene. It is the paper trail that satisfies audit requirements from the SEC, FINRA, or whichever body has jurisdiction over the decisions your agent is influencing. The cost of inadequate logging in those contexts is not an operational problem. It is a compliance liability that can dwarf the entire build cost.

What the Two-Year Number Actually Looks Like

Take a moderately complex enterprise agent as a reference: a multi-step system with several integrations, handling meaningful volume of real decisions, deployed with appropriate safeguards. Build cost in the $150,000 to $300,000 range, which is consistent with published estimates for that complexity tier.

What does year two actually cost, separate from the build?

• Inference: $24,000 to $96,000 annually, volume and model dependent

• Integration maintenance and dependency management: $25,000 to $60,000

• Engineering time for model updates, prompt tuning, and regression testing: $40,000 to $80,000

• Human review capacity, partial FTE or equivalent: $30,000 to $70,000

• Observability infrastructure and tooling: $10,000 to $30,000

• Security, compliance, and audit-related work: $15,000 to $40,000

That is $144,000 to $376,000 per year in ongoing costs, against a one-time build that was probably the only number in the original budget request. The build cost and first year of operations can easily total $300,000 to $600,000 for a single agent. A portfolio of three to five agents, which is where many organizations land within 18 months of their first deployment, can run $1M to $2M per year in fully-loaded operational costs.

None of this means AI agents are not worth it. The ROI case for well-scoped agents is real. But worth it requires an honest baseline, and the honest baseline includes operational costs, not just build costs.

Questions That Actually Matter Before You Approve the Budget

The questions worth asking before signing off on an AI agent project are not about the build scope. They are about the operating model.

Who owns this system after launch? Not the project, the system. There should be a named team or function with a budget and responsibility for keeping it running, maintaining integrations, handling model updates, and responding to production incidents.

What is the escalation rate, and what happens to those escalations? If nobody has modeled the expected volume of cases that fall outside the agent's confidence threshold, the human review cost is an unknown. That unknown will surface as unplanned headcount or degraded service quality, usually at the worst possible time.

What is the model update policy? If the LLM provider updates the underlying model, who is responsible for testing the agent against the new version before it reaches production? What is the rollback plan if the update degrades behavior?

What compliance obligations attach to this agent's decisions? If the agent touches data or makes decisions in a regulated domain, the observability, audit trail, and governance requirements need to be scoped before the build begins, not retrofitted after a compliance review flags the gap.

How are inference costs modeled at 3x expected volume? Token costs scale with usage, and usage almost always grows faster than projected. The budget should model at least one stress scenario that reflects real growth.

The Build Is the Starting Line

Organizations that end up with successful AI agents in production two years after launch are not the ones that got the lowest build quote. They are the ones that modeled operating costs honestly, built with production requirements in mind from day one, and staffed ownership of the system as a real function rather than an afterthought.

The build is the starting line. The finish line is a system that keeps working as the world around it changes, without hemorrhaging budget or requiring constant crisis intervention. Getting from one to the other requires planning for costs that do not appear in any vendor proposal.

If you are working through this math for an upcoming project and want to pressure-test the numbers against what we have seen in production, we are happy to compare notes.