How Much Should You Budget for AI Agent Maintenance After Launch?

Quick answer

Most teams budget for two costs — build and inference — and miss the third: ongoing maintenance, which is primarily people time, not compute. A reasonable starting benchmark is 15-25% of the original build cost per year in maintenance effort (eval review, prompt iteration, incident response, and periodic re-validation against model updates), separate from and usually larger than the token bill for a mid-volume agent. Treat this as a planning line item from the start, not a cost you discover six months post-launch when quality has already started drifting.

Three separate costs get conflated into one number, and that's the mistake

Build cost, inference cost, and maintenance cost behave completely differently over time — build cost is a one-time investment, inference cost scales roughly with usage, and maintenance cost is a recurring people-time cost that doesn't automatically scale down even if usage is flat. Budgeting for "AI cost" as one number instead of three is why maintenance is so often underfunded — it gets absorbed into whatever's left after the more visible build and token costs are accounted for.

Maintenance is mostly people time, not infrastructure spend

Unlike traditional software where maintenance often means server costs and occasional bug fixes, agent maintenance is dominated by an ongoing, active process: reviewing production failures, updating prompts, expanding the golden evaluation dataset to cover new edge cases, and re-validating quality after every underlying model update. This is the recurring work behind what team and roles you need to run an AI agent in production long-term — the maintenance budget is largely the cost of those people's time, not a line item on a cloud bill.

Model provider updates force unplanned maintenance work

Providers update underlying models — sometimes with advance notice, sometimes silently — and those updates can shift agent behavior in ways that degrade quality on your specific use case even though the model "improved" on general benchmarks. Budget explicit time for re-running evals and re-tuning prompts after every provider-side model update, not just for planned migrations covered in migrating an AI agent between LLM providers. This is unplanned by nature, which is exactly why it needs a standing budget allocation rather than being requested ad hoc each time it happens.

Inference cost and maintenance cost don't move together

A high-volume agent with a stable, well-tuned prompt can have high inference cost but relatively low maintenance cost — the token bill at scale is the dominant number. A lower-volume agent in a fast-changing domain (frequent policy changes, new product lines, evolving compliance requirements) can have the opposite profile: low token cost, high maintenance cost, because the underlying knowledge and edge cases keep shifting. Budget each independently based on your actual usage pattern and domain volatility, not as a fixed ratio.

Skipping maintenance budget doesn't remove the cost — it defers and compounds it

Teams that don't allocate ongoing maintenance time don't avoid the cost; they pay it later, usually as an emergency fix after a visible quality problem, at a worse unit cost than planned, proactive maintenance would have been. This mirrors the logic in calculating AI agent ROI before greenlighting a project — an ROI calculation that only accounts for build and inference cost, and omits maintenance, will overstate the agent's return once the first year of real operation is accounted for.

Revisit the maintenance budget at usage milestones, not just annually

As conversation volume, the number of supported use cases, or the domain's rate of change increases, maintenance needs typically increase too — a fixed annual maintenance budget set at launch will undershoot for a fast-growing agent. Tie budget reviews to usage and scope milestones, the same way team sizing decisions should scale with actual usage rather than being set once and left alone.

FAQ

What percentage of build cost is a reasonable maintenance budget? 15-25% of build cost per year is a reasonable starting benchmark for a moderately complex agent, adjusted up for fast-changing domains and down for narrow, stable use cases.

Does maintenance cost go down over time as the agent matures? Often, yes, once the prompt and eval set stabilize — but it rarely goes to zero, because model updates and shifting user behavior create ongoing work indefinitely.

Is maintenance cost mostly engineering time or product/PM time? Both, but the split shifts over time — early maintenance leans more on ML/engineering, while mature agents lean more on the AI PM function reviewing quality and prioritizing fixes.

Should maintenance budget be a fixed headcount allocation or a flexible pool? A flexible pool tied to usage and incident volume is generally more efficient than a fixed headcount allocation, especially for teams running multiple agents that don't all need attention at the same time.

Accelate scopes a maintenance budget alongside the build estimate for every agent engagement, so the real total cost of ownership is visible before launch, not after.