Why the build price is not the full price
Ask most vendors for a quote and you'll get a number for the build: discovery, design, development, testing, launch. That number is real, and our guide to custom AI agent cost walks through what drives it. But a build price answers "what does it cost to make this exist." It doesn't answer "what does it cost to keep this working," and that second question matters just as much, because a system that isn't maintained doesn't stay as good as it was on launch day. It gets worse, quietly, while everyone assumes it's still doing what it was built to do.
This isn't a sales angle for padding an invoice. It's a structural fact about how these systems work. A traditional piece of software, once shipped, mostly keeps doing what it was coded to do until someone changes the code. An AI system is different because so much of what makes it work — the data it sees, the model behind it, the process it's plugged into — belongs to things outside the build itself, and every one of those things keeps moving after launch. That's why we treat running a system as its own stage of work rather than an afterthought; our process page covers how Discover, Design, and Build lead into a fourth stage, Run, that doesn't have an end date.
What actually breaks over time
Nothing about a well-built AI system is fragile on day one. What changes is everything around it. A handful of patterns account for almost every case where a system that worked well at launch starts working less well six months later.
A system it depends on changes its API or its fields. Your AI agent reads from a CRM, a booking tool, or a billing platform, and one day that platform renames a field, changes what a status code means, or ships a new version of its API. Nothing about your agent changed. What it's reading did, and unless someone is watching for that, the agent keeps acting on data that no longer means what it used to.
The business changes a process and nobody tells the system. You add a new pricing tier, change your refund policy, open a new service area, or restructure how a request gets routed internally. A person picks that up from a team meeting or a memo. A system only knows what it was built to know, and if the change never gets fed back into it, it keeps following the old rule confidently and incorrectly.
The model provider deprecates or updates a model and behaviour shifts subtly. The language model or speech model underneath the system isn't static — providers retire versions and ship new ones on their own schedule. A new version can be better on average and still handle one of your specific edge cases differently than before. That's rarely a dramatic break. It's a subtle shift in tone, judgement, or accuracy that nobody notices until enough small cases add up.
A new edge case shows up that nobody anticipated. Every system is built and tested against the cases that were known at the time. Real usage eventually produces a case nobody thought to test — an unusual request, an unexpected combination of inputs, a customer who describes a normal situation in a way the system has never seen. That's not a failure of the original build. It's what happens when a system meets the real world for long enough.
Volume grows past what the original design assumed. A system scoped for a modest, steady volume can behave differently once usage climbs — response times change, rare edge cases that showed up once a year start showing up weekly, and load exposes gaps that never mattered at low volume. Growth is a good problem, but it's still a problem the system needs re-checking against.
None of these are signs of a bad build. They're what happens to any system that sits inside a business that keeps operating, staffed by people who keep changing how they work, connected to other software that keeps shipping updates. The question isn't whether these things happen. It's whether anyone is watching for them.
What running a system actually involves
"Maintenance" sounds vague, so it's worth being specific about what the work actually is once a system is live.
Monitoring that surfaces degradation before a customer does. This means having visibility into what the system is doing — what it handled, what it escalated, where it hesitated — so a drop in quality shows up as a signal someone can act on, not as a pattern of complaints that takes weeks to notice and trace back to a cause.
Reviewing escalations and low-confidence cases to find patterns. Every system hands some cases to a person, either because it wasn't confident or because the case was designed to require sign-off. Looking at those cases individually is useful. Looking at them as a set is where the real signal is — if the same type of case keeps getting escalated, that's not random noise, it's a gap in the system that's worth closing.
Periodic evaluation against real, recent cases rather than the original test set. A system was tested against the cases that existed before launch. Those cases age. Evaluating it periodically against what's actually coming through now — not the demo dataset from six months ago — is the only way to know whether it's still performing the way it was on day one, or whether it has quietly drifted.
Updating the system when the business changes. New product, new policy, new team structure, new edge case worth handling explicitly — each of these is a small, deliberate change to how the system behaves, made on purpose rather than discovered by accident. This is routine work, not a sign that something went wrong with the original build; it's the same discipline behind what actually drives voice AI cost once a line is live and real call volume starts revealing what the original scope didn't anticipate.
The three cost components of running an AI system
Once a system is live, three separate things drive what it costs to keep running, and buyers routinely forget the third one.
| Component | What it covers | Why it moves |
|---|---|---|
| Usage costs | Model and API calls, and for voice systems, telephony minutes | Scales directly with how much volume runs through the system |
| Hosting | Wherever the system and its supporting infrastructure run | Fairly stable, but grows with volume and with how many systems it touches |
| Human time | Watching what the system does, reviewing escalations, evaluating it, and updating it | The one people forget to budget — and often the largest line over a system's life |
Usage costs and hosting are the two components most people plan for, because they show up on an invoice somewhere and scale in a way that's straightforward to reason about: more volume, more usage, more cost. Human time is different. It doesn't arrive as a bill from a provider, so it's easy to leave out of a budget entirely — until the system has been live for a few months, nobody has been watching it closely, and it becomes clear that the quiet degradation described above has been happening the whole time. Budgeting for the person-hours behind monitoring, review, and tuning is not optional overhead. It's the part of maintenance that actually keeps the other two costs under control, because a system that's watched and tuned uses its usage budget more efficiently than one left to drift.
We don't put a number on any of this in the abstract, for the same reason we don't quote a build price before understanding your systems: usage cost depends on your volume, hosting depends on what the system touches, and the human-time component depends on how much oversight the workflow actually needs. What we do instead is size all three with you before launch, the same way we scope everything else — a clear price, reasoned and agreed before the work starts, not a number pulled from a rate card. Our pricing page covers how that scoping works across a build and its running cost together, and our AI strategy work is where that sizing gets tied back to what the system is actually worth to your business.
Who should own this inside your business
Even when a studio operates the day-to-day maintenance, someone inside your business needs to own the relationship with the system — and that's true whether you built it yourselves or a partner runs it for you. That person doesn't need to understand the model architecture. They need to be the one who notices when something feels off, who reviews the escalations and can tell you whether they look like isolated cases or a pattern, and who can make a fast call when the system needs a small decision rather than letting a question sit for two weeks waiting on a committee.
This mirrors what a good build process already asks of you. Ownership doesn't start at launch — it's built during the engagement, which is why the Run stage of how we work exists to train your team on how to work alongside the system and how to override it when it gets something wrong, so that by the time a studio's active involvement tapers off, someone on your side already understands what "normal" looks like for that system well enough to spot when it isn't.
If nobody internally owns this, maintenance becomes something that happens to your business rather than something your business actively directs — and a vendor, however good, cannot know your process changed unless someone tells them.
What happens if nobody maintains it
An unmaintained AI system does not fail the way most software failures look. It doesn't throw an error, crash, or send an alert. It keeps running, keeps answering, keeps taking actions — just with a growing gap between what it's doing and what it should be doing. A field it depends on changed months ago and it hasn't noticed. A policy update never made it into how it responds. The edge cases it mishandles quietly pile up because nobody is looking at the escalation queue as a set.
That's worse than a loud failure, not better. A system that breaks obviously gets fixed immediately, because everyone can see it's broken. A system that degrades quietly keeps being trusted at full strength long after it has stopped deserving it, and the first sign anyone gets is usually a customer complaint, a compliance question, or a number that's been quietly wrong for longer than anyone wants to admit. The cost of that gap is almost always larger than the cost of the maintenance that would have caught it early.
What to ask a vendor about post-launch support before you sign
If you're evaluating a vendor for an AI build, ask these questions before you sign anything — the answers tell you whether maintenance was part of their plan from the start or something they'll figure out later:
- Who actually watches the system once it's live, and how often?
- How do you catch a degradation in quality before a customer reports it?
- How is the system evaluated after launch, and against what — a fixed test set from before launch, or real, recent cases?
- What happens when our business changes something the system needs to know about — who updates it, and how fast?
- What's included in ongoing support, and what gets billed separately?
- Who owns the system if we want to change vendors or bring maintenance in-house later?
A vendor who answers these clearly, before you've asked twice, is one who has actually run systems past launch day. A vendor who treats the question as an afterthought is telling you what your first six months will look like.
We won't tell you maintenance is a fixed number, because it isn't — it depends on your volume, how many systems the build touches, and how much oversight the workflow needs, exactly like the build itself. What we will do is scope it and price it before anything starts, the same way we scope and price everything else, so the number you agree to is the number you're billed.