Retiring an AI Feature Is a Trust Event, Not a Deprecation

The metrics tell you to kill it. Three percent of monthly actives. The eval refresh has slipped two cycles. The prompt has a // TODO: revisit when we move off the legacy ticket schema from a year ago. Your senior AI engineer spends a full week per month babysitting the thing — model upgrades, label drift, the one tool integration that flakes whenever the upstream API changes its date format. Every quarterly review, somebody asks why this assistant still exists, and every quarter the answer is "we haven't gotten to it yet."

So you write the deprecation memo. You copy the structure from the API sunset playbook your platform team perfected: T-minus-six-months announcement, a migration guide, a banner in the product, a webhook for partners, the usual Sunset: HTTP header. You ship it on a Tuesday. By Thursday afternoon, your CSMs are forwarding emails that don't sound like API deprecation complaints. They sound like breakup letters.

That's the moment most teams realize they took a category error to production. The thing you're retiring isn't an API. It's a relationship the user formed with something that talked back.

Why the API deprecation playbook misfires

The deprecation playbook for code APIs is one of the most refined artifacts in modern platform engineering. There's a reason every major provider — Microsoft Power Platform's April 2026 cutover to the modern model-driven look, OpenAI's GPT-4o retirement window, Anthropic's Claude 4 sunset on June 15 — runs a recognizable choreography: clear subject line, affected versions, replacement endpoint, soft cutoff, hard cutoff, support contact. Six to twelve months of notice for anything load-bearing. The receiver of that comm is an engineer holding a Jira ticket. They run the migration. The relationship between them and the API is contractual: schema in, schema out.

That receiver exists for AI features too — but only for the integrators. The end users of an AI assistant aren't holding tickets. They're holding habits. They taught your assistant the abbreviations they use for product SKUs. They saved a "summarize this for my Monday standup" workflow that nobody on your team knew was a workflow. They told it personal things — illness, a death in the family, that they're job-hunting — because the conversational interface invited disclosure and they responded the way humans respond to invitations to disclose. None of that is in your audit log under "feature usage." It is, nonetheless, what you're about to retire.

There's a research base for why this hits differently. Trust in conversational AI is built on two foundations: cognitive trust (does it work) and affective trust (does it feel reliable, kind, on my side). The systematic review in Computers in Human Behavior frames this clearly — affective trust does work that cognitive trust can't, and it's the part that fractures publicly when you take the assistant away. The JMIR study on conversational AI in counseling contexts found that anxious-attachment users develop a measurably different relationship with chat AI than secure-attachment users do, and the APA's 2026 Monitor feature describes the pattern at population scale: users apply theory of mind to chatbots within seconds. None of those users are going to read your migration guide. They're going to feel something you didn't put in the comms calendar.

The maintenance-cost ledger that the qualitative pushback will overrun

Before any of the trust-handling matters, the team has to be able to defend the retirement decision quantitatively, because the qualitative pushback is going to be louder than the engineering cost on every dimension that's visible to leadership. "Power user wrote a 2000-word LinkedIn post" travels further than "the AI engineer reclaimed 18 hours a month."

The maintenance-cost ledger has to capture the things that don't show up in the inference bill. Eval refresh and label maintenance — every prompt change forces some chunk of the eval set to be re-graded, and a stale eval is worse than no eval, so the work is non-optional. Model upgrade tax — when the underlying model retires, you re-tune temperature, re-run safety evals, re-validate the tool-calling contract. The two-to-six-week migration windows that providers like Anthropic and OpenAI now ship every quarter mean every long-tail feature is paying that tax on someone else's schedule. Prompt drift — the prompt that worked at launch has been edited fourteen times by people who are no longer on the team, and nobody has the unifying mental model anymore. Tool surface area — every tool the agent can call is a contract you're maintaining with another team. Incident overhead — every degraded-mode outage in a dependency requires the on-call to think about what a 3%-usage feature should do.

When you total it, the line you want is engineer-hours per active user per quarter. Compare it to the same number for the rest of the AI portfolio. If it's an order of magnitude higher, that's the number that survives the meeting where someone says "but our top customer wrote in." It also gives you the credit you can offer the affected users in dollars, which we'll come back to.

Cohort analysis: separate the dependent from the curious

The 3% number is a trap. It doesn't tell you whether you're retiring a feature or evicting a population. The cohort that needs to surface is who actually depends on this: the user whose retention depends on the feature, the user whose workflow has the assistant on the critical path, the user who would churn if it disappeared. The other cohort — the one-time tester who clicked the tooltip in 2024 and never came back — is in your monthly-active count and shouldn't be.

A workable cohort cut for an AI assistant looks something like this:

• Habituated: 3+ sessions per week for 8+ weeks, with at least one workflow that recurs (same tool sequence, same intent class). These are the people whose week reorganizes if the assistant goes away.
• Embedded: integrated the assistant into a downstream artifact — saved its outputs into a doc, shared its links in Slack, built a personal prompt template. The assistant left footprints in their work that they can't easily remove.
• Disclosed: shared sensitive information with the assistant — health, finances, personal context. Even at low usage frequency, the trust transaction has happened and the retirement comm has to acknowledge it.
• Casual: weekly use without recurrence pattern. The assistant is one of several tools, replacement is real but inconvenient.
• Vestigial: in the 3% by accident — opened it, never returned, maybe forgot it exists.

The maintenance-cost ledger is defensible against Casual + Vestigial loss. It is not defensible against Habituated and Embedded loss without a transition design that those cohorts actually trust. Disclosed needs separate handling — those users are owed something different from a banner. Researchers studying feature sunsets in B2B SaaS have noted that poorly managed sunsets can move churn 18-34%, and well-managed ones leave it flat or improve it; the difference is almost entirely in whether the team did this kind of cohort separation before designing the comms.

A transition design that respects what was built

The standard sunset playbook is "feature is going away on date X, here is the alternative." For an AI assistant, the alternative was never designed to absorb the workflows the assistant carried. A search bar is not a substitute for a thing that summarized your standups. A help center article is not a substitute for a thing that remembered which dashboards you cared about.

Three things have to land in the transition design:

A real alternative path, not a banner. If the workflow the assistant carried doesn't have a replacement in the rest of the product, you don't yet have a sunset plan; you have a feature removal. The rule is: build the alternative path, validate it with the Habituated cohort before the announcement, and let those users tell you whether it carries the workflow. If it doesn't, the sunset date moves.

A data-portability promise that's executable. The Embedded cohort has artifacts that depend on the assistant — saved outputs, prompt templates, conversation histories. Export tooling that lets them retain what they built, and retain their personal customization for the replacement, is the version of "migration guide" that maps from APIs to assistants. If you cannot let them export, you cannot honestly call this a sunset.

A credit, not a coupon. When you can quantify the engineer-hours you're reclaiming, some of that should be visibly redirected to the affected cohorts — usage credits, priority access to a successor feature, white-glove migration help for the top decile of dependents. This is the only part of the maintenance-cost ledger that the affected user gets to see, and it converts the retirement from "we took something from you" into "we made a tradeoff and you got something for it."

A comms cadence calibrated to the relationship, not the contract

API deprecation comms are timed to integration cycles: announce, give six to twelve months, hard-cut. Assistant retirement comms have to be timed to the relationship, which means staged disclosure and active outreach to the cohorts you've identified.

A workable cadence:

• T-90 days, in-product, in-conversation: the assistant tells the user about the change, in its own voice, the next time the user opens it. Not a banner. Not an email. The thing the user trusts is the thing that breaks the news. Every conversation gets a short footer with the timeline and the alternative path.
• T-90 days, direct outreach to Habituated and Embedded cohorts: a real human reaches out to the top decile by usage. Asks what they'd lose. Offers the migration credit. Listens for the workflow you didn't know existed.
• T-60 days, a separate comm to Disclosed cohort: acknowledging that the assistant held personal information, explaining what happens to that data on the retirement date, giving the option to export or delete on the user's terms.
• T-30 days, in-product warning the user can dismiss but not silence: the assistant proactively raises the deadline at the start of any session involving a workflow that won't survive.
• T-7 days, the soft cutoff: new sessions disabled, existing sessions allowed to complete. This is the analogue of a Sunset: header — but it's the conversation that gets the warning, not the API caller.
• T-0, the actual end state: the assistant says goodbye. This is not optional and it's not melodrama. The same theory of mind that made users disclose to the assistant in the first place is going to apply at the moment of removal; an unceremonious cutoff is a trust violation that the product won't recover from cheaply. A two-line, in-character close with a pointer to where the user can find the alternative path is the version of 410 Gone that this medium calls for.

The team that runs this cadence and treats it as overkill will find that the postmortem looks nothing like an API deprecation postmortem. The team that runs the API deprecation cadence on an assistant will find out which of their support transcripts get screenshot.

The portfolio failure mode that kills future shipping velocity

The single-feature retirement is hard. The bigger failure mode is the portfolio. AI features accumulate fast — every team ships an assistant for their corner of the product, every assistant generates its own eval set, prompt library, tool integrations, telemetry surface. A year in, the org has fifteen of them, three of which are above 20% adoption and twelve of which are between 1% and 5%. The maintenance cost of the long tail is now competing with new-feature velocity, and every time a model retires upstream, the team eats two weeks of forced migration work for features that nobody is going to mourn.

The thing that has to land at the org level is a retirement budget — a quarterly cadence where the AI portfolio gets reviewed against the engineer-hours-per-active-user metric, and the bottom decile gets put on a retirement track unless someone makes the case for keeping them. The reason it has to be a cadence, not a one-shot, is the same reason model deprecations are a cadence: drift is continuous, and so is the maintenance compounding it produces. Without the budget, the team postpones the retirement conversation indefinitely because the customer pushback for any single feature is louder than the cumulative engineering cost across all of them. The platform tax on shipping the next assistant is paid in old assistants.

The framing that moves this conversation from postponed to scheduled is naming retirement as a first-class lifecycle stage with its own playbook, separate from the deprecation playbook for code APIs. New feature, beta, GA, sustaining, retirement. Each stage has owners, exit criteria, and a budget. Retirement is the stage where the trust that was built gets handled — not the stage where the code path gets removed. That's the architectural realization underneath all of this.

What to take into the next planning cycle

The team that hasn't named the distinction between API deprecation and AI-feature retirement will mishandle the first one. The team that has named it will spend more time on the comms than they expected, more time on the transition design than they expected, and less time defending the decision than they feared — because the maintenance-cost ledger is doing the defending and the cohort analysis is showing the work.

If you're staring at a 3%-usage assistant right now and trying to find the right Tuesday to send the email, the prework is: build the ledger, segment the cohorts, validate the alternative path with the Habituated users, write the staged comms, scope the data-portability promise, and budget the credits. Send the email last. The thing you're retiring built a relationship — let the retirement be the last act of that relationship, not the moment it became transactional.