Every automation you ship has a second cost that nobody writes into the proposal: the cost of keeping it working. The build is the visible part. The maintenance is the part that shows up nine months later as a Slack message that says “this stopped working, did we change something?” Nobody changed anything. The world changed underneath it.
Why things that worked stop working
Automations break for reasons that have nothing to do with your code. A model provider deprecates an endpoint or quietly changes how it formats output, and your parser starts choking on responses it used to handle fine. A source system you scrape or poll adds a field, renames one, or nests a value one level deeper, and your mapping logic points at nothing. A vendor rotates their auth flow. None of this is a bug you wrote. It is drift, and drift is constant in any system that depends on other people’s systems.
The reason this surprises people is that the failure mode is silent, not loud. A workflow does not usually throw a dramatic error and page someone. It degrades: it starts returning empty fields, or subtly wrong classifications, or duplicate records, and it keeps running that way for weeks because nothing crashed. By the time someone notices, the bad output has already gone into a report, a CRM, or a customer email.
What 20-30% actually buys
Budgeting 20-30% of the original build cost per year is not a guess pulled from nowhere, it is a rough match to what ordinary software maintenance costs across an equivalent lifespan, and agentic workflows have more moving external parts than most software, not fewer. That money should go to three things: monitoring that catches silent failures instead of loud ones, scheduled re-validation after any model or API version bump, and a standing block of time to actually fix what monitoring finds.
Concretely this looks like a monthly check where someone runs the workflow against a fixed test set and diffs the output against last month’s, a changelog watch on every API and model the system depends on, and a small retainer of engineering hours that exists whether or not anything is currently broken. If you skip that last part, the fixes get triaged against everything else on someone’s plate and lose, every time, until the workflow has been quietly wrong for a quarter.
Who underestimates this
Teams who built the automation once and moved on. If nobody owns a workflow after launch, it has no maintenance budget by definition, because nobody is asking for one. This is the most common failure pattern in shops that treat automation as a project with an end date rather than a system with a lifespan. The workflows that survive past year one are the ones with a named owner and a recurring calendar slot for review, not the ones with the cleverest initial architecture.
It also catches teams who chose the cheapest model available at build time and never revisited that choice. Pricing and capability both move fast enough that a model selection made a year ago is worth re-checking, not out of curiosity but because providers deprecate old versions on their own schedule, not yours.
What this changes about how you scope work
If you are quoting or scoping an automation project, the honest version includes the maintenance line from day one, not as an upsell after something breaks. I put this in every proposal I write through services: a fixed percentage of build cost, invoiced as a recurring retainer, described up front as insurance against drift rather than as extra hours you might not need. Clients who skip it almost always come back after the first silent failure asking for exactly that arrangement, just later and angrier.
The uncomfortable part is that this maintenance cost does not shrink over time in proportion to how well the thing was built. A well-architected workflow still depends on external APIs it does not control. Good architecture reduces the blast radius of drift and makes it easier to detect, it does not eliminate the underlying instability of the ecosystem the workflow sits inside.
The honest number, stated plainly
Twenty to thirty percent of build cost, every year, for as long as the automation stays in production. If a workflow has been running three years with zero maintenance spend, either it is trivially simple, it touches nothing that changes, or it is already broken and nobody has looked. Those are the only three explanations, and the third one is the most common.