Yesterday, a model retired.
Claude Opus 4.1 hit its scheduled retirement date on the Claude API on 5 August 2026, sixty days after the deprecation notice went out on 5 June. Anywhere a production system still had claude-opus-4-1-20250805 hardcoded, that call now fails.
Somewhere today, an agency is on a call explaining to a client why their invoice classifier stopped working overnight. And the real question on that call isn't technical. It's: who pays for this?
If the answer isn't already written down, the agency eats it. Every time.
Before starting Scopeyard, I spent years running a product development studio and delivering AI automation across healthcare, recruitment and operations. The pattern I keep seeing is agencies who scope the build beautifully and then hand over a maintenance agreement copy-pasted from their website retainer template. It talks about bug fixes and uptime. It says nothing about the four things that actually go wrong on AI systems.
So it becomes free work. Not once — monthly, for the life of the relationship, until someone resents someone.
The thesis in one line:
AI Maintenance Contract = Keep It Running + Keep It Accurate + Keep It Current + A Named Line Where New Work Begins
Traditional software maintenance only needs the first term. AI needs all four.
1. Start from what actually breaks
Write the contract from the failure modes, not from a template. On AI systems there are four, and they behave completely differently:
| Failure mode | What it looks like | How you find out |
|---|---|---|
| Infrastructure | Workflow errors, jobs stuck, queue backed up | Alerts, within minutes |
| Integration | Upstream API changes, auth expires, schema shifts | Errors or silent bad data |
| Model lifecycle | Provider deprecates or retires the model you called | Provider notice, weeks ahead |
| Quality drift | Output slowly gets worse. Nothing errors. | Nobody. That's the problem. |
The first two look like normal software support and your existing template probably covers them. The last two don't, and they're where the money leaks.
Quality drift is the nastiest because it's silent. Research on agentic systems in 2026 found nearly 90% of agents showed measurable goal drift after around 30 steps, and the same body of work notes that a system running at a 60% success rate on a single attempt can fall closer to 25% measured across eight consecutive runs. Treat those as directional rather than gospel — evaluation methods vary a lot — but the direction is not in dispute. Systems that passed acceptance testing degrade in production without throwing a single error.
You cannot write "we fix bugs" and expect that to cover a system that is quietly getting 8% worse a month.
2. Price it as a percentage of build value, then sanity-check it
The old software rule still gives you the right starting number. Annual maintenance for custom software has sat at 15–20% of the original build cost for decades, with complex or legacy systems running higher.
For AI work I start at 20–30% annually, because you're carrying model lifecycle and quality assurance on top of ordinary support. Then I check it against what the market actually pays. Published 2026 benchmarks put AI support and maintenance retainers in the $2,000–$8,000 per month range depending on system complexity, with broader AI automation retainers spanning roughly $1,000–$3,500 monthly for a small business running two or three workflows up to $8,000–$25,000 for enterprise engagements with a dedicated team.
Two numbers, two directions, one decision:
| Build value | 20–30% annual | Monthly floor | Sense check |
|---|---|---|---|
| $30,000 | $6,000–$9,000 | $500–$750 | Too thin — either raise it or make it best-effort only |
| $80,000 | $16,000–$24,000 | $1,300–$2,000 | Reasonable for a single well-defined workflow |
| $200,000 | $40,000–$60,000 | $3,300–$5,000 | Lands squarely in the market band |
| $500,000 | $100,000–$150,000 | $8,300–$12,500 | Needs a named team, price it that way |
If the percentage gives you a number below roughly $1,000 a month, the honest move is to say so. Below that you can't afford to look at the system regularly, and a maintenance contract you can't afford to honour is worse than no contract — it's a promise you'll break slowly.
Don't be lazy here. A monthly figure someone picked because it sounded fine is how agencies end up subsidising their own clients for three years.
3. Separate the three tiers and name them
Bundling everything into "support" means every request lands in the same bucket and you argue about each one. Split it explicitly:
Tier 1 — Keep it running. Monitoring, error alerts, restarting failed jobs, fixing broken integrations, credential rotation. This is classic support. Response times, business hours, escalation path.
Tier 2 — Keep it accurate. Reviewing outputs against the accuracy bar you agreed at scope, investigating drift, retuning prompts, updating retrieval sources, re-running evals. This is the tier most agencies forget to charge for and then perform anyway.
Tier 3 — Keep it current. Model migrations, provider deprecations, upgrading to a better or cheaper model, adapting to changed upstream APIs. Scheduled work, not emergency work — if you're doing it as an emergency, you missed the notice.
Anything outside those three is new work. Which brings me to the clause that matters most.
4. Write the line between maintenance and new scope, in specifics
"Enhancements are out of scope" is not a boundary. It's a phrase both parties will interpret in their own favour at the worst moment.
Be concrete. For a CV screening system I'd write:
In scope: keeping extraction accuracy at or above the agreed threshold on the twelve fields defined in the build scope; adapting to changes in the ATS API; migrating models when the provider retires ours.
Out of scope (billable at $X/hour or by change order): adding a thirteenth field; supporting a second ATS; extending to a new document type; raising the accuracy threshold above what was agreed; any increase in volume beyond the contracted monthly ceiling.
That last one is the sleeper. Volume growth is the most common way an AI maintenance contract quietly becomes unprofitable — the client's business grows, the system processes three times more, your API bill and your review time triple, and your monthly fee doesn't move. Put a volume band in the contract with a defined step: "up to 5,000 documents per month; above that, a reassessment at 3,000-document increments."
Naming five specific out-of-scope things is worth more than a page of boilerplate exclusions. It's the same discipline as scoping the build properly — you're writing down what the client is quietly hoping for, before they hope it out loud.
5. Handle model deprecation as a planned event, not a surprise
Providers publish their notice periods. Use them.
Anthropic commits to at least 60 days' notice before retiring a publicly released model and publishes a "not sooner than" date for active models. OpenAI's deprecation policy runs longer for generally available models and much shorter for previews and experimental endpoints. The dates are public. There is no excuse for being surprised.
What to put in the contract:
- Who watches. Name it as your responsibility and charge for it. Subscribe to the provider's deprecation feed. Check it monthly.
- Included migrations per year. I'd include one or two like-for-like migrations annually — same capability, new model version, re-run the evals, confirm accuracy holds. That covers the normal cadence.
- What counts as a migration versus a rebuild. Swapping model versions and retuning prompts is maintenance. Re-architecting because the client wants a fundamentally different capability is a project.
- Who pays if accuracy changes. Newer models sometimes behave differently on your specific task. If a migration requires substantial prompt or pipeline rework to restore the agreed accuracy, say up front whether that's included or billable.
- Version pinning as policy. Pin model versions in production and migrate deliberately. Floating to "latest" means the client's system changes behaviour on the provider's schedule instead of yours.
Pin the cost assumption too. A maintenance contract that silently absorbs the API bill carries an open-ended liability. Either the client holds the provider account, or you pass costs through with a stated ceiling.
6. Define monitoring as a deliverable, not a promise
"We'll monitor the system" is worth nothing unless someone can point at what monitoring produced. Make it a thing the client receives.
At minimum, specify what's measured and how often it's reported: uptime and error rate, volume processed, accuracy on a sampled set against the agreed threshold, cost per unit, and any incidents with their resolution. Monthly is usually right. Quarterly is too slow to catch drift.
The sampling matters more than people expect. Pick a fixed sample size — say 50 outputs a month for a moderate-volume system — score them against the same rubric you used at acceptance, and chart the number over time. That single chart is what turns "the AI seems worse lately" from a feeling into a number you can act on, and it's the artefact that justifies the entire tier-2 fee.
Gartner projects that by 2028, 40% of enterprise AI failures will trace to inadequate evaluation and monitoring rather than model capability. The agencies that build monitoring into the maintenance contract are selling the thing that's about to be the scarce skill.
7. Set response times you can actually honour
Copying enterprise SLA language into a small agency contract is how you promise a 15-minute critical response with a team of six people in one timezone.
Write bands you can meet on a bad week:
| Severity | Definition | Response | Resolution target |
|---|---|---|---|
| P1 | System down, no output being produced | 4 business hours | Same business day, best effort |
| P2 | Degraded — running but accuracy below threshold | 1 business day | 5 business days |
| P3 | Cosmetic, minor, or a question | 2 business days | Next maintenance cycle |
Business hours, stated timezone, and a named escalation contact. If a client genuinely needs 24/7 with a 15-minute response, that's a different contract at a different price with a rota behind it. Sell that separately or don't sell it.
On service credits: the common enterprise pattern caps monthly credits at 30–50% of the monthly invoice. At agency scale, keep credits modest and exclusions clear — a credit regime you can't administer is just a future dispute.
8. Say who owns the human in the loop
Almost every AI automation worth running has a human review step somewhere. The contract has to say whose human it is.
If the client's team reviews flagged cases, write down what "flagged" means, what volume they should expect, and what happens if they stop reviewing — because they will stop, quietly, around month three, and the first you'll hear of it is when a bad output reaches a customer.
If your team reviews, that's labour with a monthly cost attached to a volume assumption, and it belongs in the pricing model explicitly, not folded into a flat fee. Ten minutes a day of someone's attention is roughly $2,000 a year at agency rates. Charge for it.
This is also where the runbook earns its keep — the escalation path, who to call, what a "normal" week looks like. Put it in the maintenance agreement rather than the build phase and it stays current instead of ageing on a shared drive.
9. Make the contract visible, not just signed
The best-written maintenance agreement still fails if nobody can see what's been done against it. Clients don't dispute maintenance fees because the work wasn't valuable. They dispute them because the work was invisible.
Every month, the client should be able to see what was monitored, what incidents occurred, what was fixed, what's waiting on their approval, and where the accuracy number sits. That's the difference between a retainer that renews without discussion and one that gets questioned every quarter.
It's the same problem as slow client approvals draining cash flow — the work is fine, the visibility isn't. We built Scopeyard around exactly this: milestones, review states and client approvals in one place, so what's done and what's waiting on whom is never a question either side has to ask over email.
Final thoughts
An AI maintenance contract isn't a warranty. A warranty says the thing you built works as specified. Maintenance says the thing you built will keep working in a world where the models retire, the APIs change, the data shifts and the outputs quietly drift.
Those are ongoing obligations with real cost. Price them, tier them, and write down where they end.
The agencies losing money on AI work usually aren't losing it on the build. They're losing it in month seven, on work nobody agreed to and nobody's paying for.
Maintenance you didn't scope isn't a service. It's a subscription you bought for your client.