An AI agent that works on the day of acceptance testing will not necessarily work six months later. The underlying model changes version, an API evolves, the input data shifts, and the first serious incident lands before anyone has decided who steps in and at what price. Most contracts signed today describe the build, very rarely the life of the system after go-live. The bill then gets settled in unbudgeted fix days, or worse, in an agent switched off for lack of agreement on costs.
Key Takeaways
- An AI agent maintenance contract must cover three distinct scopes: fixing breakdowns, adapting to external changes (models, connectors, data), and the changes the business asks for.
- The three causes of cancellation cited by Gartner (2025) are escalating costs, unclear value and inadequate risk controls: each one has a matching clause.
- Without a consumption cap and a non-regression clause, a third-party model update can move both your bill and your quality with no say from you.
- Access (API keys, repository, prompts, logs) and exit terms are negotiated at signature, not at the moment of divorce.
- No standard ratio says how many hours to budget: ask the provider to justify its retainer from its own incident history.
Why an agent degrades while the code stays the same
An AI agent is not a fixed piece of software. It is a chain of components, several of which belong to third parties: the model, the connectors to business tools, the reference data, the orchestration, and the prompts that hold the whole thing together. The code you paid for can stay identical to the character while the system's behaviour changes, because one link moved on the other side of the boundary.
Three movements produce most incidents:
- The model changes. Vendors ship new versions, deprecate old ones and sometimes change response formats. An agent tuned to a specific version stops working the day that version is retired, often on short notice.
- The data changes. A revised chart of accounts, a new catalogue, a website rebuild or a merger of two databases is enough to break a classification or an extraction that used to work.
- Usage changes. The agent handled 40 requests a day, now it handles 400. Rate limits, response times and cost per request do not follow the same curve.
This is what Gartner measures when the firm estimates that only about 130 vendors, out of the thousands presenting themselves as agentic AI providers, offer real agent capabilities. The gap between demo and production has become a contract issue, not a technical one.
The six clauses that make the difference
A readable maintenance contract comes down to six blocks. If one is missing, it will be missing at the worst possible moment.
| Clause | What it must say | What its absence costs |
|---|---|---|
| Scope | Which incidents are covered, under what retainer (hours, tickets, days), and when a request becomes a billed change | Every fix becomes a negotiation, and the budget drifts with no ceiling |
| Model updates | Who monitors versions, who tests before a switch, who pays for the remediation after a deprecation | The agent goes down on the date set by the vendor, and the repair is billed as an emergency |
| Variable costs | Who pays for consumption, with what monthly cap, what alert threshold and what level of billing detail | An unpredictable API bill, discovered at the end of the quarter |
| Monitoring and logs | Which indicators are tracked, how often, in what format, and with what access for the client | An incident reported by an unhappy user before the system reports it |
| Ownership and access | Who owns the prompts, the code, the test sets, the logs; which accesses are handed to the client | Total dependency: no way to have the system taken over by another provider |
| Term and exit | Fixed term, notice period, exit procedure, handover inventory and transfer of assets | A tacit renewal that binds you for another year, or an exit with no documentation |
The middle column is the one people argue about. The right-hand column is the one that costs.
Model updates: demand a non-regression clause
The most often forgotten point, and the most expensive. Your agent was calibrated on a given version of a model. The day the vendor announces its retirement, two paths open: migrate in a hurry, or let the agent stop.
A proper non-regression clause rests on four commitments:
- Pinned version. The contract names the version in use and forbids any change without written approval.
- Watch and notice. The provider commits to warning you as soon as a deprecation is announced, with the end-of-support date and a migration plan.
- Test set. A set of reference cases is kept and replayed before any switch. It is the only way to show that a new model does not degrade the answers.
- Who pays. A migration forced by a third party is not a business change. It should sit inside the maintenance retainer, or at least be priced in advance. This is exactly the kind of arbitration to write down in black and white, and it is also what we check first during an audit and advisory of an existing set-up.
Without those four points, the quality of your agent depends on a calendar decided elsewhere. Gartner puts a number on the risk: at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value, according to Gartner (2024). One abandonment in three is not a model problem: it is an operations problem.
Variable costs: cap, alert, rebilling
An agent costs twice. Once to build it, once to run it. The second expense is variable: it depends on request volume, context length and the model chosen. A contract that does not mention that expense leaves it mechanically with the client, with no limit and no visibility.
Three elements to put in writing:
- A monthly consumption cap, with the rule applied on overrun: stop, fall back to a cheaper model, or prior approval.
- An alert threshold, for instance at 80% of the cap, sent to a named person and not to a support inbox.
- Detailed billing by usage, with request volume, unit cost and total. A provider that cannot produce that level of detail cannot steer your budget.
Add infrastructure and the licences of connected tools (vector database, orchestration platform, ticketing tool): these are subscriptions that pile up, and nobody watches them once the project is delivered. The automation of a business process multiplies that kind of dependency, which makes budget tracking even more necessary.
Ownership, access and exit: negotiate at signature
An AI agent concentrates assets that carry value and are often poorly documented: the prompts, the test sets, the connectors, the execution logs, the business rules coded into the orchestration. If the contract does not say who owns them, the outgoing provider treats them as its know-how and the incoming one starts from scratch.
What to secure:
- Explicit ownership of the code, the prompts and the test sets, with a usage licence for third-party components.
- Handover of access during the contract, not at the end: code repository, API accounts, the model vendor's console, the orchestration tool. Not a copy, the real accesses.
- Retention and handover of execution logs, for the period required by law and by your own compliance obligations.
- An exit procedure: notice period, handover inventory, operating documentation, a support period for the takeover.
The topic is covered in detail in two companion articles: who owns an agent built for you and changing provider without losing everything. A third, further upstream, details what an AI agent quote must contain before maintenance even comes up.
What should not appear in a maintenance contract
Some clauses empty the contract of its substance. They are easy to spot.
- "The provider is not liable for changes to third-party models." Taken literally, that sentence excludes most real breakdowns. It can make sense for a price change imposed by the vendor, not for an agent that stops answering.
- A retainer that only covers fixes. Adapting to data and connectors is the most frequent part of the work. Leaving it out of scope is organising pay-per-call billing.
- An availability commitment with no indicator. "Best possible availability" commits to nothing. You need a measurement, a source for that measurement and a consequence for a breach.
- A long termination notice with tacit renewal. Twelve months of notice on a system that changes every quarter is a trap.
Conversely, recovery-time commitments and service levels deserve a separate negotiation, so much do the formulas vary with the criticality of the automated process. That subject has its own article.
How to read a maintenance proposal in one hour
A simple method, no technical skill required:
- Highlight every occurrence of the word "change". You have just found the boundary between the retainer and pay-per-call billing.
- Look for the word "model" and check that a version is named. No version, no commitment.
- Look for a consumption cap. If absent, ask for one.
- Count the periodic deliverables: incident report, consumption, quality indicators. No deliverable, no steering.
- Check what you get back on exit, and within what delay.
- Ask for the history: how many incidents has the provider handled on comparable set-ups, and in how long. That is the only honest basis for sizing a retainer.
A serious provider answers those six questions in writing. A provider that answers "we will see case by case" is in fact offering to let you pay for maintenance at emergency rates, one incident at a time. The same logic applies when you compare providers: warning signs are often visible before signature, as our article on unreliable AI providers points out.
FAQ
Should you pay for maintenance from the first year?
Yes, but not at the price of a full year of operations. The first year includes a stabilisation period during which early defects are fixed: they fall under the warranty of proper functioning, not under a maintenance retainer. Ask for an explicit warranty of three to six months after acceptance testing, then a retainer that starts when it ends.
What happens if the model vendor deprecates the version in use?
Three outcomes are possible, and only one is acceptable: the migration is planned and included in the retainer. The other two are migration billed as an emergency, or the agent stopping on the end-of-support date. The non-regression clause described above exists to make the first outcome mandatory.
Does maintenance cover new requirements?
No, and that is normal: a new requirement is a project, with its own scoping and its own price. What must be covered is adapting the system to an environment that changes without you asking for anything. The line between forced adaptation and requested change is the most profitable thing to clarify in the whole contract.
How many hours or days should be budgeted each month?
No standard ratio applies, and anyone who gives you one without looking at your set-up is making it up. The right figure is built from three inputs: the number of integrations with third-party systems, the volume of planned changes in those systems, and the provider's incident history. Ask for the retainer to be justified by those three elements, and plan an annual review of the volume.
Can you change provider mid-contract?
Technically yes, provided you hold the access and the documentation. That is precisely why the access handover clause and the closing inventory must be signed at the start. If the provider refuses to name the assets it holds, assume the exit will be adversarial and negotiate that point before anything else.
Conclusion
Maintaining an AI agent is not an optional service added at the bottom of a quote. It is the clause that decides whether your system lasts or dies at the first model change. Three scopes, a consumption cap, a non-regression clause, real access, an organised exit: five points to secure before signature, and far fewer unpleasant surprises afterwards.
NexeAI supports SME leaders on these topics, from initial scoping to taking over an existing set-up: audit and advisory, design of AI agents and training for the teams who will operate them. If you have a maintenance contract on the table and doubts about its scope, write to us: we will tell you what is missing, clause by clause.
