Every agent program eventually has an agent that should be killed. Maybe the use case evaporated; maybe a newer agent absorbed the work; maybe the eval scores never crossed the threshold and after four months of trying it is clear they never will. The instinct in most organizations is to defer the kill — to keep the agent alive on life support because killing it feels like admitting failure. This instinct is wrong, expensive, and a sign of immature operating discipline. Mature agent programs treat sunsets as a success metric. The architect who can run a clean kill — with a written kill plan, comms to affected humans, data export to preserve learning, and a replacement path for the work the agent was doing — is the architect whose program scales. The architect who cannot is operating a graveyard. This lesson is the playbook for sunsetting an agent without drama: the criteria for kill decisions, the kill plan template, the comms sequence, the data and learning preservation, the replacement path, and why kills should be a celebrated metric in your QBR.

Why Kills Are Success, Not Failure

The cultural frame matters. In most software organizations, killing a project carries stigma. The team that built it feels their work was wasted. The stakeholders who championed it lose face. The metrics dashboard that showed the project in its run-state has to be reconfigured. Everyone has incentives to avoid the kill, even when the kill is correct.

Mature agent programs invert this. A kill is a signal that the program has the operating discipline to make hard decisions. A kill frees engineering time for higher-leverage work. A kill prevents the slow drift of an under-performing agent eroding customer trust. A kill, well-executed, is harder than launching the agent in the first place — it requires honesty, planning, and the ability to communicate respectfully with humans whose work the agent has been touching.

The signals of a mature program

An agent program that has never killed an agent is not necessarily an unsuccessful program — it might be too young, or all its agents might genuinely be the right ones. But programs older than 18 months that have never killed anything are almost always operating with hidden technical debt. The agents are being kept alive past their usefulness; engineering time is being consumed maintaining them; the program is hiding from a hard decision.

The signals of a mature program include kill rate. Different programs find different equilibria — a program that runs 12 agents and kills two per year is operating differently from a program that runs 4 and kills one every two years — but both are demonstrating they can prune. Programs that cannot prune are accumulating drag.

Sunsets in the QBR

Sunsets should appear in the quarterly business review as named, celebrated outcomes. "This quarter we killed Agent X. It had been running for nine months at 64% approval, below our 78% threshold. We attempted three remediation cycles before deciding the work was better suited to a non-agent solution. Here is what we learned. Here is where the freed engineering capacity went."

The QBR framing matters. Stakeholders see sunsets normalized. The team that killed Agent X gets recognition, not criticism. The architect who proposes the kill earns capital, not loses it. The next time a kill is needed, the decision arrives faster.

The hardest part of running an agent program is not building agents. It is sunsetting them. Building feels generative; killing feels destructive. The mature architect understands that pruning is its own form of building — the program that prunes consciously is the program that compounds; the program that does not is the program that decays.

When to Kill: The Decision Criteria

The kill decision is not made on a feeling. It is made against criteria, written in advance, applied honestly.

The four categories of kill candidates

Agents end up on the kill list for one of four reasons:

• Use case evaporation. The work the agent was built to do is no longer being done, or has been absorbed by another process. The customer support agent that handled refunds was rendered moot when the company changed its refund policy to be fully self-service through a UI change. The agent is operating but unused.
• Replacement by a better solution. A newer agent, a different platform, or a non-agent solution does the work better. The classic example: a complex multi-agent system that has been replaced by a simpler single-agent solution as foundation models improved. The old system works; the new one is better and cheaper.
• Performance ceiling. After repeated remediation cycles, the agent has not crossed the eval threshold required for production confidence. Three months of work, eight prompt revisions, two model changes, one orchestration refactor — and the eval score has plateaued below threshold. The work is not landing; further investment is unlikely to change that.
• Cost-benefit inversion. The agent's operating costs (compute, model calls, human review time) have grown faster than the value it produces. What was profitable at launch is unprofitable at current volume; the path to profitability is uncertain.

The decision threshold

Each kill category has a threshold. The architect writes the thresholds in advance — typically in the agent's design doc at launch — and revisits them quarterly.

Example thresholds:

• Use case evaporation: usage has dropped below 20% of peak for three consecutive months.
• Replacement by a better solution: the replacement has been in production for at least one quarter at parity or better; the agent's costs continue.
• Performance ceiling: three consecutive remediation cycles with no statistically significant improvement; the eval score is more than 10 percentage points below the launch threshold.
• Cost-benefit inversion: cost per successful agent invocation exceeds the value of the work by more than 2x for two consecutive months.

The thresholds are not edicts. They are signals that the team should have the kill conversation, not that the kill is automatic. The kill conversation may produce a fifth alternative — a re-scoping, a major remediation, a transfer to a different team. But the conversation must happen.

The kill review meeting

When a threshold is crossed, the architect convenes a kill review. Attendees: the architect, the agent owner (often a business stakeholder), the operating team's lead, the engineering manager if applicable, and a representative from the AI governance function if one exists.

The meeting is 60 minutes. Agenda:

• The data (15 minutes). The eval scores, the usage, the cost, the customer impact. Concrete numbers, not impressions.
• The options (20 minutes). Kill, re-scope, remediate, transfer. The team discusses each and identifies the cost, benefit, and risk of each.
• The decision (15 minutes). The team converges on a recommendation. Often the recommendation is to kill; sometimes it is to give one more remediation cycle with a hard date.
• The next steps (10 minutes). Who owns what, what the kill plan needs to address, when the kill happens.

The decision is made by the agent owner with input from the architect and the operating team. The architect's role is to advocate honestly for the technical reality; the owner's role is to integrate that with business reality and decide.

The Kill Plan: Six Sections

Once the decision is made, the architect produces a kill plan. The kill plan is a written document, typically two to four pages, that addresses every aspect of the sunset.

Section one: kill rationale

One paragraph explaining why the agent is being killed. Specific. Honest. Cites the data. Names the category (use case evaporation, replacement, ceiling, or cost inversion). This section is for the audiences who will see the kill — stakeholders, the team, future learners — to understand the reasoning.

Section two: affected humans and comms

Who is touched by the kill. The cohort of human reviewers whose work the agent has been touching. The customer success function that has been escalating to the agent. The product manager whose feature uses the agent. The downstream agents that call this one.

For each, the kill plan specifies: how they will be told, by whom, on what date, with what message. The communications go out before the kill, not after. Surprise kills generate the drama the kill plan is designed to prevent.

The reviewers in particular need careful handling. They have built habits around the agent. Their role may change with the kill. The comms plan for them parallels the rollout comms plan — clear about what changes, what does not change, what they should expect.

Section three: data export and learning preservation

The agent has generated months or years of data. Run logs, eval results, incidents, postmortems, customer interactions. Some of this data is permanent organizational knowledge. The kill plan specifies what gets preserved and how.

Specifically:

• The eval set. The hand-curated eval cases that were built for this agent are organizational asset. They belong in the team's shared eval library, tagged by the agent and use case, available for future agents that face similar problems.
• The postmortem corpus. Every postmortem for this agent is permanent. They go into the team's postmortem library, searchable, available to the entire organization.
• The decision history. The major decisions made during the agent's life — model choices, orchestration architecture, prompt evolution — get a one-page retrospective at sunset. What worked, what did not, what we would do differently. This becomes input for the next agent.
• The customer data. Whatever production data the agent had access to — and the agent's outputs that touched customer records — needs handling per the company's data retention policy. The legal and compliance team is the owner here.
• The run database. The full agent run database, with traces, may be valuable for future analysis or compliance audits. Retention per policy; access controls per policy.

Section four: replacement path

What happens to the work the agent was doing. Three patterns:

• The work was no longer being done. Use case evaporation. The work has been absorbed by a UI change, a process change, or a different team. The kill plan documents where the work went.
• The work transfers to a different agent. Replacement. The kill plan specifies the cutover: the new agent's launch state, the migration of any inputs or state, the handoff date, the verification that the new agent is doing the work successfully before the old one is terminated.
• The work transfers to a human team. Ceiling or cost-inversion kill with no replacement. The work the agent was doing returns to a human team. The kill plan specifies which team, what the staffing implication is, and the training the team needs. This pattern requires the most care — humans absorbing agent work without warning is a fast path to morale collapse.

Section five: technical sunset sequence

The technical steps to take the agent down. Not a single deployment switch. A sequence over typically two to six weeks:

• Week one: announcement. Comms go out per Section two.
• Week two: traffic ramp-down. The agent is left running but traffic to it is reduced — sometimes by routing logic, sometimes by stakeholders being told to use the replacement.
• Week three: shadow mode. The agent runs but its outputs are not used in production. This gives a week to detect anything that was depending on the agent in undocumented ways.
• Week four: termination. The agent's compute is shut down; its API endpoints return a 410 Gone with a forwarding message; its scheduled jobs are deactivated.
• Week five to eight: cleanup. The agent's identities are decommissioned (Section seven). The agent's secrets are rotated and removed from systems. The agent's deployment configuration is archived but kept reachable for compliance. Any code repositories are archived and marked as no-longer-maintained.

The pacing is deliberate. Faster kills risk missing dependencies; slower kills extend the dramaturgy of the kill into a perpetual question of "is it really over."

Section six: lessons captured

The one-page retrospective on what was learned from this agent's life. What worked. What did not. What we would do differently. What the eval scores looked like over time. What the major incidents were. What category of work this confirmed was suitable for agents (or not).

This section is the seed of the next agent. The team that captures lessons at sunset compounds learning across agents. The team that does not has to learn the same lesson again.

The Comms Sequence

The comms sequence around an agent sunset is its own discipline. Get it wrong and the kill becomes a story; get it right and the kill becomes a routine operational event.

T-minus three weeks: stakeholder pre-brief

The architect briefs the agent owner, the operating team lead, and any executive sponsor before any wider communication. The pre-brief covers the rationale, the alternatives considered, the recommendation, and any open concerns. The stakeholders have time to ask questions, suggest modifications, and prepare for their own messaging.

T-minus two weeks: affected team announcement

The team that has been working with the agent gets the announcement two weeks before the kill begins. The announcement is clear: the agent is being sunset; here is why; here is what happens to the work; here is what the team can expect.

The format is similar to the rollout announcement: short, declarative, specific, with a separate FAQ. The affected team's manager is co-signatory.

The announcement explicitly addresses three things the team will be wondering:

• What does this mean for our work? Specific, dated.
• What does this mean for my role? Specific. If the team's responsibilities are changing, say so. If they are not, say so.
• Is this related to broader organizational changes? If yes, be honest. If no, say so plainly.

T-minus one week: cross-functional notice

Teams that depend on the agent — downstream agents, customer-facing teams, finance teams that track its costs, security teams that audit its activity — get notice one week before the technical sunset begins. The notice is informational: the timing, the impact, where to direct questions.

T-day: kickoff

The kill plan executes. The architect notifies the team of milestones throughout: traffic ramped down, shadow mode entered, termination complete. A short status update each milestone keeps stakeholders informed and prevents rumors from filling the information vacuum.

T+one week: post-kill retrospective

One week after termination, a brief retrospective. What went well in the kill. What did not. What we would do differently next time. The retrospective produces small process improvements that compound across future kills.

T+one quarter: lessons surface in QBR

The lessons section from the kill plan is presented in the next QBR. Named. Celebrated. The team gets credit for the discipline of the kill.

The Human Side of Killing

The technical and process side of sunsetting an agent is the easier part. The harder part is the humans.

The team that built it

The architect and the engineers who built the agent will feel the kill as loss. This is normal. The discipline is to honor the feeling without letting it block the decision.

The team needs to hear, explicitly, that the kill is not a judgment of their work. They built the agent based on the information available at the time. The decision to kill is based on information that emerged after — usage patterns, performance ceiling, better alternatives. Engineering judgment was sound; new information arrived.

Practical mechanisms to honor the team: name them in the kill announcement; credit them in the lessons section; explicitly assign the freed engineering capacity to higher-leverage work; consider an internal write-up of what was learned, with the team's bylines.

The reviewer cohort

The humans whose daily work has included reviewing the agent's output have built habits, identity, and relationships around the agent. The kill ends those habits.

For the reviewer cohort, the kill announcement must include a clear answer to "what happens to my role." If their role continues unchanged (the work transfers to a different agent and review continues), say so. If their role changes (the work returns to direct production), say so and specify the change. If the change is a reduction in their work, say so and address the team's headcount implications.

The hardest case: the reviewer cohort whose work was specifically about reviewing this agent. Their role exists because the agent existed. When the agent ends, their role must change. This is workforce planning. It happens with HR, before the kill announcement, and the announcement names the path.

The downstream customers

If the agent has interacted directly with customers — through customer-facing comms or through being part of a customer-facing product — the customers need to know. The form depends on the product: an in-app notice, an email, a public changelog. The legal team owns the customer comms; the architect provides the technical context.

The product manager

The PM whose feature depends on the agent has a planning problem. The kill changes their roadmap. The architect briefs them early (the T-minus three weeks pre-brief), helps them with replacement-path planning, and ensures their stakeholders hear about the change through the PM, not around them.

When the Kill Goes Wrong

Even with a kill plan, kills can go wrong. Failure modes to anticipate:

The undocumented dependency

An undocumented system somewhere depends on the agent. It might be a Slack bot that calls the agent's webhook. It might be a finance report that consumes the agent's database table. It might be a customer-facing feature that nobody on the kill side knew about. When the agent goes dark, the dependency breaks.

Mitigation: the shadow mode week (week three in the technical sequence) is specifically designed to catch these. Logging is set to capture every caller of the agent's endpoints. The team reviews the logs daily during shadow mode and triages any callers that should not exist.

If a dependency is found during shadow mode, the kill pauses. The dependent system is either migrated to the replacement or accepts the loss of the dependency. The kill resumes once dependencies are resolved.

The political pushback

A stakeholder who championed the agent pushes back when the kill is announced. The pushback may be in good faith (they had different information about value) or in bad faith (their reputation is bound up in the agent). Either way, the architect must respond.

The response: present the data calmly, acknowledge the contribution the agent made, offer a structured conversation about whether the data is being interpreted correctly. If the conversation surfaces new information that changes the kill decision, the kill pauses and the team revisits. If the conversation does not surface new information, the kill proceeds, with the stakeholder's escalation path noted but not blocking.

The team morale dip

The engineering team feels the kill more than anticipated. Sprint velocity drops. Slack channel tone changes. The architect notices and acts: a team retrospective on the kill, a deliberate assignment of higher-leverage work, possibly a one-on-one with each engineer to acknowledge the dynamic.

The customer escalation

A customer notices the kill and is unhappy. Maybe they relied on the agent's behavior in a way the team did not anticipate. The customer success function takes the lead; the architect provides technical context and proposes alternatives. The kill may be temporarily delayed for the customer's specific case while a transition is arranged.

Patterns of Good Kills

The kills that go best in 2026 share patterns. The architect who has run a few kills internalizes them.

The kill announced before the threshold is crossed

The team sees the trajectory. The agent's eval score has been declining for two months. Cost has been trending up. The architect announces, internally, that if the trajectory continues for one more month a kill conversation will happen. Stakeholders adjust expectations. The kill decision, when it comes, is anticipated.

This pre-announcement discipline takes the drama out of the kill. The kill is the conclusion of a known trajectory, not a surprise.

The kill paired with a launch

When an agent is sunset because a replacement is available, the announcement pairs them. "We are sunsetting Agent X and launching Agent Y as its successor." The narrative is forward-looking; the team's investment is being redirected, not abandoned.

The kill that explicitly captures lessons

The kill plan has a strong lessons section. The lessons are presented in the next QBR. The team gets visible credit for what was learned. The lessons are referenced when the next agent is scoped. The kill paid dividends in compounding institutional knowledge.

The kill with a celebrated team

The team that built the agent gets visible recognition at the kill, not punishment. Their work is named in the announcement. Their lessons are credited. Their freed engineering time goes to high-priority new work. The cultural signal: kills do not punish builders.

Anti-Patterns of Bad Kills

The zombie agent

The agent should have been killed six months ago. Nobody pulled the trigger. It runs in production, consuming cost, occasionally generating an incident, used by a tiny fraction of its peak audience. The team's mental model of "active agents" still includes it. New agents that should be built are delayed because engineering capacity is consumed maintaining the zombie.

Fix: quarterly kill review. Every agent reviewed against threshold criteria. Decisions documented even if "continue."

The silent kill

The agent is killed without announcement. The reviewer cohort logs in one morning to find no agent output to review. The product manager's feature breaks. The customer success function fields questions they cannot answer. Drama is generated retroactively because comms were skipped.

Fix: the comms sequence. T-minus three weeks for stakeholders. T-minus two weeks for affected team. T-minus one week for cross-functional. Always.

The kill without a replacement path

The work the agent was doing is real work that the business needs done. The kill is announced without specifying where the work goes. The work just stops, and three weeks later a customer escalation surfaces because something was not happening that nobody knew was happening.

Fix: kill plan Section four. The replacement path is mandatory, even if the answer is "this work no longer needs to happen because of X."

The kill that erases learning

The agent is killed and its eval set, postmortems, and decision history are not preserved. The team gets back to building. Three months later a new agent faces the same problem the killed one faced. The team has to relearn what was already known.

Fix: kill plan Section three. The preservation of organizational learning is mandatory.

The kill as punishment

The team that built the agent is publicly criticized at the kill. Their work is framed as failure. Engineering morale collapses. Future builders avoid risky agents because they fear being on the wrong end of the next kill.

Fix: the kill is a decision about the system, not the team. The team's contribution is acknowledged. Lessons are extracted with attribution. The freed engineering capacity is visibly assigned to growth, not idle.

The kill that drags on

The kill is announced. The technical sunset begins. Three months later the agent is still partly running because nobody finished the cleanup. Identities are still active. Secrets are still rotating. The agent's database table is still being written to. The mental overhead of the half-kill is greater than running the agent in full.

Fix: the kill plan has a date. The cleanup phase is bounded. The architect owns enforcement. A kill that has not completed cleanup within two months of announcement is itself a problem worth surfacing.

Kill Rate as a Program Metric

Mature programs track kill rate. The rate is not a target — the goal is not to kill the most agents. The rate is a signal.

What a healthy kill rate looks like

For a program with N agents in production:

• Zero kills over 18 months is suspicious. Either the program is young, or the program is hiding from pruning decisions.
• Roughly 5-15% annual kill rate is healthy for mature programs. A program with 12 agents that kills one or two per year is making the hard decisions and capturing the learning.
• Kill rate above 30% suggests the program is shipping agents that should not have been shipped. The launch bar is too low, or the eval discipline is too weak.

The rate varies by program type. Internal-only agent programs can sustain higher kill rates because the cost of churn is lower. Customer-facing agent programs benefit from lower kill rates because customer trust is harder to rebuild than internal trust.

The "kill that should have happened sooner" metric

For each kill, a retrospective question: when, in hindsight, should this kill have been triggered? Often the answer is "two or three months earlier than it was." The gap between when-it-should-have-and-when-it-did is the lag the program is reducing.

Reducing the lag is the meta-discipline. Programs that kill at the right time avoid carrying technical debt; programs that kill late carry it.

The Architect's Internal Relationship With Kills

The architect's psychology around kills determines how well the program runs them.

The investment fallacy

The architect invested time, energy, and reputation in the agent. Killing it feels like losing that investment. The investment fallacy: behavior driven by sunk cost rather than expected value.

The discipline: the investment is sunk. The decision is about the future. The architect who runs the kill at the right moment loses no investment that was not already lost; they avoid losing more.

The reputation fallacy

The architect fears that the kill will damage their reputation. Stakeholders will see them as having shipped a failing agent. The reputation fallacy: behavior driven by perceived judgment rather than actual judgment.

The discipline: in mature organizations, the kill enhances reputation. The architect who can kill cleanly is the architect with operating discipline. Stakeholders distinguish between launching a failed agent (a launch decision error) and killing an under-performing one (an operating discipline win).

The identity fallacy

The architect identifies with the agent. The agent is "theirs." Killing it feels like killing part of themselves.

The discipline: the architect's identity is the program, not any individual agent. A program that prunes is a healthy program. The architect's identity scales when they internalize this.

Key Takeaways

• Kills are a success metric, not a failure metric. Mature programs prune; immature programs accumulate. Kill rate appears in the QBR as a celebrated outcome.
• Four categories of kill candidates: use case evaporation, replacement by better solution, performance ceiling, cost-benefit inversion. Each has a written threshold; quarterly kill review checks every agent against thresholds.
• Kill decision is made by the agent owner with architect input. Architect's role is to advocate honestly for technical reality; owner integrates with business reality.
• Kill plan has six sections: kill rationale, affected humans and comms, data export and learning preservation, replacement path, technical sunset sequence, lessons captured.
• Comms sequence is its own discipline: T-3 weeks stakeholder pre-brief, T-2 weeks affected team announcement, T-1 week cross-functional notice, T-day kickoff, T+1 week post-kill retro, T+1 quarter lessons in QBR.
• Technical sunset sequence over 2-6 weeks: announcement, traffic ramp-down, shadow mode (detect undocumented dependencies), termination, cleanup. Shadow mode is the safety check.
• Data and learning preservation is mandatory: eval set goes to shared library, postmortem corpus is permanent, decision history captured in retrospective, customer data per retention policy.
• The humans matter most. The team that built it needs acknowledgment, not punishment. The reviewer cohort needs clear answers about their role. The PM needs early notice. The downstream customers need appropriate comms.
• Anti-patterns: zombie agent, silent kill, kill without replacement path, kill that erases learning, kill as punishment, kill that drags on. Each has a fix; the architect plans for each.
• Healthy kill rate is 5-15% annual for mature programs. Zero is suspicious; above 30% suggests the launch bar is too low. The meta-discipline is reducing the lag between when a kill should have happened and when it did.