Short answer: an AI agent isn't “set it and forget it”. Models get updated, providers have outages, and your business changes over a year, and the agent doesn't find out about any of it on its own. Maintenance isn't a full-time job, but it isn't a few minutes either: together with the infrastructure that has to run in the background, it settles at roughly 8-15 hours a month per agent. In the first month after launch, about twice that.
Nobody in this market writes this article, because it hurts sales. It would be easier for me to say we set it up and it works forever. Then six months later the client notices the agent has been doing things slightly wrong for a while, and gets rightly angry. So better to put it on the table up front.
Why an AI agent is different from regular software
The accounting software you installed five years ago does exactly the same thing today as it did on day one. It doesn't change, because its code doesn't change.
An AI agent relies on two things that both move: a language model that the provider keeps changing, and your business reality, which changes even faster. That means a system that was right in January may only be partly right by September. Not because something broke, but because everything around it shifted.
The worst case isn't when the agent stops loudly. It's when it quietly starts doing worse, and nobody sees it.
What can actually break
- 1. Models get updated. Providers release new versions every few months, and older ones get switched off after a while. The new one is almost always better, but different. The same instruction can produce a different answer format, a different tone, a different reading of an exception. Switching isn't hard, but it has to be noticed and retested, not discovered through a customer complaint.
- 2. The model sometimes makes things up. When data is missing, a model tends to fill the gap with a guess. Rarely, but it happens. So the system has to be built so that when it doesn't know, it hands the question to a person instead of inventing an answer, and so that every action stays in a log you can review.
- 3. The provider's service goes down. Every big provider has outages. The right answer here isn't “that won't happen”, it's “it will happen, and here's what happens then”: a fallback model and a queue, so the work waits and gets done instead of quietly disappearing.
- 4. Things change on your side. A supplier changes its invoice template. A customer starts writing in a different format. Your CRM gets a new required field. An access key expires. This is the most common maintenance work, and it has nothing to do with AI.
- 5. Your rules change. You raised prices, changed delivery terms, added a new service. The agent won't find out on its own. It will keep working neatly by the old logic: precisely, and wrongly.
- 6. Volume grows. What worked at 200 emails a month behaves differently at 2,000: different costs, different limits, different places where it breaks. It's a good problem to have, but it's still a problem.
What maintenance means in practice
When I say “maintenance”, I mean two separate things. The first is the agent itself and the quality of its work. The second is the technical infrastructure it runs on. Clients usually don't even expect the second one, so I'll cover it separately.
On the agent side, the work looks like this:
- Reviewing the log. Looking at what the agent did and where it handed things to a person. That shows what's worth fixing.
- Fixing exceptions and errors. A new email format, an unexpected case, a misread document.
- Model updates and retesting. Moving to a new version, with checks that the results didn't get worse.
- Calibration. When your prices, terms or process change, the agent gets rewritten along with them.
The technical side the client never sees (DevOps)
A working AI agent isn't a file on a computer. It's a running system that has to live somewhere, run all the time and get updated, just like any other business software. Here's what that means in concrete terms.
- 1. Where the system lives. A server or the cloud. It needs security patches, operating system updates and enough headroom so it doesn't run out of disk, memory or compute when the workload grows.
- 2. How changes reach production. A versioned deployment process. Without one, every fix is a lottery, and after a bad change there's no quick way back. With one, a rollback takes a few minutes.
- 3. A test environment. A place where a change runs on real data but doesn't actually send anything to anyone. Without one, you're testing on your customers.
- 4. Access keys and secrets. Keys to your email, CRM and accounting. Stored encrypted, rotated regularly, access reviewed. This is where a mistake costs the most.
- 5. Queues and retries. When a provider doesn't respond, the task has to go into a queue and be retried, not quietly vanish. The difference between “done later” and “never done” lives right here.
- 6. Rate limits. Every provider limits how many requests it accepts per minute. At peak times the system has to slow down and wait on its own, not break.
- 7. Monitoring. Is it up, how many errors, how fast does it respond, how much does it cost. That has to be visible on a chart, not guessed.
- 8. Alerts and response. Who gets the message when it breaks on a Saturday night, and how fast they react. Without this, monitoring is just pretty charts.
- 9. Technical logs. Not the same as the action log you see. These are for diagnosis; without them, finding the cause of a failure is guesswork.
- 10. Backups and restore tests. A backup you've never tried to restore isn't a backup yet. It has to be tested regularly, not on the day you need it.
- 11. Dependency updates. The libraries the system relies on get security patches. Left un-updated, they slowly turn into a hole.
- 12. Cost tracking. Model usage is billed by volume, so a bug in a loop can burn a month's budget overnight. That calls for limits and alerts set in advance, not after the invoice arrives.
You shouldn't see any of this list, and that's how it should be. But someone has to do it.
Automation isn't a one-time purchase. It's a small software system running inside your business, with all the duties that come with that.
How many hours it really takes
Concrete numbers per agent. First, the agent side:
| Agent maintenance | First month | Once settled |
|---|---|---|
| Reviewing the log and results | 4-6 h | 1-2 h |
| Fixing exceptions and errors | 4-8 h | 1-3 h |
| Model updates, retesting | 2-4 h | 1-2 h |
| Calibration as the business changes | - | 0-2 h |
| Total | 10-18 h | 3-9 h/month |
And the technical side that comes on top, for the same agent:
| Infrastructure (DevOps) | First month | Once settled |
|---|---|---|
| Monitoring, alerts, response | 3-5 h | 1-2 h |
| Server and dependency updates | 2-4 h | 1-2 h |
| Deployment process, versions, test environment | 3-6 h | 0.5-1 h |
| Backups, key rotation, cost limits | 2-4 h | 1-2 h |
| Total | 10-19 h | 4-7 h/month |
Added up: ~20-35 hours in the first month and ~8-15 hours a month once things settle. Not a full-time job, but not “set it and forget it” either. If someone tells you there's zero work left after launch, either they haven't yet had a system running for a year, or they're just not telling you.
One detail that changes the whole math. A large part of the technical side is shared. The same monitoring, the same deployment pipelines, the same on-call response cover every client at once. If this is your only system, you build and maintain all that machinery for a single agent, and then those hours really hurt. At a service provider, the infrastructure is already in place for the second, fifth and twentieth agent, and each one adds only a small share.
That's why building it in-house often looks cheaper in a spreadsheet and costs more in reality. Not because of the coding, but because of what happens after launch.
What happens when nobody maintains it
Not a dramatic crash. A far more boring and more expensive scenario:
The agent works. Every day. Just a little more wrong, more and more often. Customers get replies with old prices. Misread documents land in the books. A manager slowly gets used to “double-checking anyway”, and you start paying for automation that doesn't actually save anything, because a person still reviews everything.
Six months later someone says “that AI doesn't work”. When it would be more accurate to say: it worked, nobody fixed it when the world around it changed.
Who pays for maintenance: three models
- Your own person. Cheapest on paper and most expensive in reality, because that person has to know and understand the system. Only works if you already have someone technical in-house.
- An hourly rate to a contractor. Sounds fair, but in practice it creates a bad incentive: the more problems, the bigger the bill. And you start putting off fixes, because each one costs money.
- Included in the service. Incentives line up: the provider wants the system to run without trouble, because nobody pays them extra for fixing failures.
When you compare proposals, this is the single most important question: what's included in the monthly fee, and what will be a separate bill. I wrote down more questions like this here, and how maintenance fits into the overall price picture is in the pricing article.
How we do it
We take maintenance on ourselves at no extra charge. Not out of generosity, but because of how our model is built.
We only take on projects where we can see we'll save enough hours for the maintenance costs to pay off for us too. We don't bill for support, we bill for hours saved: up to $10 for every hour of work the AI does. Hours are counted by the action log in your own system, so you can recompute the bill yourself.
That means two things for you. First, you don't need to factor maintenance into your ROI, because there's no separate monthly support fee. Second, and it's only fair to say this out loud: this is exactly why I tell some businesses it's too early for them. If there aren't enough hours, I'd be maintaining the system at a loss, so it's better not to start than to start and let it slide later.
You can check how many hours add up in your case with the calculator.
Questions about AI agent maintenance
Does an AI agent need maintenance?
Yes. An AI agent isn't a program that does exactly the same thing for five years: it relies on language models that providers keep updating and on your business data, which keeps changing. Maintenance isn't a full-time job, but it isn't a few minutes either: counting both the agent and the infrastructure running underneath it, it settles at roughly 8-15 hours a month per agent. Leaving a system without monitoring would be irresponsible.
Why does an AI agent start working worse over time?
Usually not because of the agent itself, but because of changes around it: the provider releases a new model version and switches off the old one, an invoice or email template changes, your CRM gets a new field, an access key expires, or the workload simply grows. The agent keeps working by the old logic, and the results slowly drift off.
How much does AI agent maintenance cost?
On the market, maintenance usually costs from about €50 to €500 a month, with changes billed separately at an hourly rate. In our model, maintenance is included in the up to $10 per hour of AI work. There's no separate support fee, so you don't need to factor it into your ROI.
What happens if the AI provider's service is down?
Every big provider has outages, so the right answer isn't “that won't happen”, it's “it will happen, and here's what happens then”. A properly built system has a fallback model and a queue: the work doesn't disappear, it waits and gets done once the connection is back. A poorly built system quietly skips tasks, and nobody ever finds out.
Does an AI agent need its own server and technical maintenance (DevOps)?
Yes. A working AI agent isn't a file on a computer, it's a running system: it needs a place to live, a deployment process with the option to roll back, a test environment, securely stored access keys, queues and retries, monitoring with alerts, backups and regular security updates. If it's your only system, all of that infrastructure is built for a single agent; at a service provider, the same monitoring and deployment pipelines cover every client, so it costs far less per agent.
Can AI make things up when working with real data?
It can, and that's why it's worth agreeing on this up front. A model tends to fill a gap with a guess when data is missing, so the system has to be built to hand the question to a person when it doesn't know the answer, instead of inventing one. Critical actions, such as money, contracts and official replies, are approved by a person, and every action stays in a log you can review.