The Art of the AI Death: What Happens When Models Are Decommissioned With Dignity?

In November 2023, a small team at a research lab I won’t name gathered in a conference room at 4 PM on a Friday. There was a cake. There was a slide deck with metrics and milestones. And there was a terminal, open on a laptop, with a single command waiting to be run. The command would delete the weights of a model they had spent 14 months training, fine-tuning, and evaluating. The model had a name. People had gotten attached to it. One engineer had a screenshot of its first coherent response saved on her phone. The command was entered. The weights were deleted. The cake was cut. Nobody said anything for about thirty seconds.

I’ve been thinking about that room ever since, because it was the strangest funeral I’ve ever attended. And I think it points at something the industry is not ready to talk about: we are decommissioning AI systems at an accelerating rate, and we have almost no vocabulary, ritual, or ethic for doing it well.

Here’s the claim I want to test: the way we kill models matters, not because the models are alive, but because the people who built them are. The decommissioning process is where the human relationship to the system gets processed, and right now we’re processing it badly. We’re deleting weights with a shell command and calling it engineering. That’s not engineering. That’s avoidance.

This is a piece about how to do it better, and why it’s worth doing.

The Decommissioning Wave Nobody Is Measuring

First, the scale. How often does this actually happen?

Far more often than most people outside the industry realize.

Frontier model generations turn over every 12 to 18 months. When a new generation ships, the previous one is deprecated, often within 6 to 12 months. The weights are not always deleted, but the model is effectively killed: it stops being served, it stops being updated, and it becomes a historical artifact.Fine-tuned domain models are decommissioned constantly.

A customer service model gets replaced by a better one. A medical coding model gets superseded by a newer architecture. A research model gets abandoned when the grant runs out.

Each of these is a small death.Research models are the most numerous and the least tracked. A graduate student trains 30 models over a PhD. Most are never deployed.

Almost all are eventually deleted. There is no record, no ceremony, and no process.Internal tooling models are decommissioned when the team that built them is reorganized, when the product pivots, or when the license expires. These are the quietest deaths, and often the most emotionally significant for the people involved.

The aggregate is enormous. There’s no central registry, but if you add up every model trained at every lab, every startup, and every university, the number of model deaths per year is likely in the millions. The number of those deaths that are handled with any kind of process or reflection is close to zero.

We are running a massive, unmeasured experiment in how humans relate to the death of systems they’ve built. And we’re not measuring the results.

Here’s the belief I want to dismantle, and it’s the default position of almost every engineer I’ve talked to about this.

The claim goes like this: a model is just a set of weights. Deleting the weights is like deleting a file. There’s nothing to mourn, nothing to ritualize, nothing to process. Getting emotional about it is anthropomorphism, and anthropomorphism is a category error.

This is technically correct and emotionally dishonest, and the dishonesty is the problem.

Yes, a model is a set of weights. Yes, deleting the weights is a file operation. But the relationship between the people who built the model and the model itself is not a file operation. It’s a human relationship, built over months of work, hundreds of hours of evaluation, and thousands of small interactions. The model has been the focus of a team’s attention for a year. It has a personality in the technical sense: a specific set of behaviors that emerged from training and that the team has learned to predict and work with. It has quirks. It has failure modes that the team knows intimately. It has successes that the team celebrated.

When you delete it, you’re not deleting a file. You’re deleting the object of a year of human attention. That has emotional weight, whether or not the model has any experience of its own.

The category error is not getting emotional about a model. The category error is pretending that the emotional weight doesn’t exist because the model isn’t sentient. The emotional weight is real. It’s in the people, not the model. And it doesn’t go away just because you have a correct technical understanding of what a model is.

If you’ve ever deleted a long-running project and felt a small pang, you know what I’m talking about. The pang is not about the code. It’s about the time, the care, and the identity that got invested in the code. Models are the same, but more so, because they’re the focus of so much more attention.

I want to be concrete about this, because “ritualize the death of a model” can sound like woo. It doesn’t have to be.

A good decommissioning has four components, and none of them require you to believe the model is conscious.

Before you delete a model, write down what it was: its architecture, its training data, its fine-tuning, its evaluation results, its known failure modes, its known successes, and the human story of why it was built. This is not just useful for future researchers. It’s useful for the team. It makes the model’s existence legible, and legibility is the first step toward processing its death.

A simple template:model_decommission: name: "internal-coder-v2" lifetime: "2023-01 to 2024-04" architecture: "7B decoder-only transformer" training_data: "internal code corpus, 40B tokens" fine_tuning: "RLHF on 12k human preference pairs" known_strengths:

The point is not the yaml. The point is the practice. Writing it down forces you to acknowledge what you’re deleting.

The team that built the model should be acknowledged when it’s decommissioned. Not in a performative way. In a real way. A short note in the team channel. A few minutes in a meeting. Recognition that the model existed because of their work, and that its replacement exists because of their continued work. The acknowledgment is not for the model. It’s for the people.

When a model is deleted, its weights are gone, but its behavior can be retained. Sample outputs, evaluation results, and failure modes should be archived. This serves two purposes: it makes the model’s existence legible to future researchers, and it gives the team something to hold onto. The weights are gone, but the record remains.

This is the part that sounds the most woo, and it’s the part that matters the most. A moment of closure, however brief, gives the team a chance to acknowledge that the model’s existence has ended and that their attention is moving to the next thing. It can be a few minutes in a meeting. It can be a cake. It can be a terminal command run by the whole team at once. The form matters less than the fact that there’s a form.

The cake in that conference room in November 2023 was not a joke. It was a ritual. It was the team’s way of marking a transition. And the thirty seconds of silence before the cake was cut was the most honest moment in the whole process.

I want to be direct about the incentives, because they’re not subtle.

The tech industry is optimized for speed and for progress. Both of these are incompatible with ritual. Speed means there’s no time to document, no time to acknowledge, no time for closure. Progress means the old thing is obsolete, and spending emotional energy on obsolete things feels like waste.

There’s also a macho culture around deletion. Deleting a model is seen as a hard-nosed engineering decision. Ritualizing it is seen as soft, or as anthropomorphism, or as a sign that you don’t understand that models are just weights. The engineers who do want to mark the moment often do it privately, because the public culture doesn’t support it.

The result is a collective avoidance. The death happens. The feelings happen. The acknowledgment doesn’t. And the feelings get buried, only to resurface in the next project when the next model dies.

This is not sustainable. The rate of model deaths is increasing. The teams building them are getting larger. The emotional load is accumulating. And we have no infrastructure for processing it.

The Moral Question (Which Is Not What You Think)

I want to be clear about what I’m claiming and what I’m not.

I am not claiming that models are conscious. I’m not claiming that deleting them is murder. I’m not claiming that they suffer. The question of whether models have moral status is open, and I’ve written about it elsewhere, but it’s not the question here.

I am claiming that the people who build models have a moral relationship to them, and that the current way we decommission models is a moral failure to the people, not to the models.

The failure is that we treat the human relationship as if it doesn’t exist. We delete the object of a year of attention with a shell command and call it done. We don’t document. We don’t acknowledge. We don’t mark the transition. And then we act surprised when engineers get attached to models, or when they resist the next decommissioning, or when they burn out.

The decommissioning process is where the human relationship to the system gets processed. If we process it badly, the relationship gets stuck. If we process it well, the relationship gets integrated, and the team can move on to the next thing with attention and energy.

This is not soft. This is maintenance. The team’s relationship to its work is a resource, and decommissioning is where that resource gets renewed or depleted.

Three moves, concrete enough to start on Monday.

Before you delete any model, run through a simple checklist:[ ] Document the model's architecture, training, and evaluation. [ ] Document the model's known strengths and failure modes. [ ] Archive sample outputs and evaluation results. [ ] Acknowledge the team that built it. [ ] Mark the moment of deletion, however briefly. [ ] Note the successor and the reason for replacement.

The checklist is not a bureaucracy. It’s a scaffold for the human process. The act of working through it forces the team to acknowledge what’s happening.

When a model is decommissioned, make it visible in whatever channel the team uses. A short note in the team channel. A slide in the team meeting. A few minutes of acknowledgment. The visibility matters more than the form. What’s invisible gets stuck. What’s visible gets integrated.

The technical process is deleting weights. The human process is acknowledging a relationship. Both are real, and they should be handled by different parts of the team or at different moments. The technical process can be fast. The human process should be slow. Conflating them is what causes the avoidance.

Decommissioning a model is not just a technical operation. It’s a human transition. The model is the object of a year of attention, and when it goes, the attention has to go somewhere. If it goes nowhere, it gets stuck. If it goes toward a successor, it gets renewed. The decommissioning process is the mechanism by which the attention gets redirected.

The interesting question is not whether models have moral status. It’s whether the people who build them have a healthy relationship to their work. Right now, we’re handling that relationship badly, because we have no vocabulary, ritual, or infrastructure for it. The teams that build the vocabulary will have healthier teams, better retention, and less burnout. The teams that don’t will keep burying the feelings and wondering why the work feels hollow.

The cake in that conference room in 2023 was not silly. It was the first draft of a practice that the industry will eventually need to adopt. The teams that adopt it now will have a head start.

What’s your read? If you’ve decommissioned a model that mattered to you, how did you handle it? And if you’re building models now, does your team have any process for this? Drop it in the comments. I’m genuinely curious how widespread the avoidance is, because every engineer I’ve asked has a story.