The agent decay problem
The failure mode people plan for with agents is the dramatic one: the agent does something wildly wrong, expensively, in public. It happens, and guardrails exist for it. But it is not the failure mode that kills most agents.
Most agents die quietly. They keep running. Nobody turns them off. And by month six, nobody is using what they produce. We call this decay, and it is the single most common reason an agent that worked at launch is not working a year later.
How decay happens
An agent's behaviour depends on things outside its code. The model it calls, which the vendor updates. The tools it connects to, whose interfaces change. The data it reads, which drifts as the business changes. The prompts and rules it was tuned against, which described last quarter's reality.
Any of these can shift without anyone touching the agent. When they do, the agent's outputs get a little worse. Not broken, worse. A summary misses a detail it used to catch. A classification lands in the wrong bucket slightly more often. A draft needs a little more editing than it did.
The people downstream are reasonable, so they adapt. First they correct the outputs. Then they start double-checking everything, which erases the time the agent saved. Then they work around it, doing the task themselves and letting the agent's output pile up unread. No alert fires for any of this, because nothing is technically failing.
Why nobody notices
Decay is invisible for three reasons.
Nobody is measuring the thing that is decaying. If the only metric is "did the agent run," it will look healthy right up to the day it is deleted.
The people who notice are not the people who own it. The person editing the agent's drafts every morning knows exactly what is wrong. The person who sponsored the agent sees a dashboard that says it ran three hundred times this week.
And the change is gradual. There is no day when the agent stopped working. There is a slope, and slopes do not trigger anyone's attention.
The four numbers that make it visible
Decay becomes visible when you measure the right things and put them in front of the right person. Four numbers, tracked weekly, are enough for most agents.
Success rate: how often the output was accepted as-is, by whatever definition the process owner wrote down at launch.
Override rate: how often a person changed or rejected the output. Rising override is decay's earliest signal, and it is only visible if overrides are captured rather than done silently in a text editor.
Cost per run: drifts when the model changes, when inputs grow, or when the agent starts retrying. A cost line moving with no change in volume is a question worth asking.
Latency: rarely the first sign, but a sudden change means something underneath moved.
Put those on a dashboard the owner looks at. Set a threshold on each. When the line crosses it, someone gets a message. That is the whole mechanism. It is not complicated. It is just rarely done.
Fixing it is routine work
Once decay is visible, fixing it is ordinary maintenance: a model update is evaluated against the harness before it is adopted, a changed tool interface is reconnected, a prompt is retuned against recent examples, a rule is adjusted for a case the business did not have last year. Small work, done monthly, by someone whose job it is.
This is why we structure agent work as a setup followed by a care plan rather than a one-time build. The setup makes the four numbers observable from day one. The care plan is the standing commitment to look at them and act. You get the outcomes. We carry the pager.
The question to ask about any agent
If you have agents in production, ask a simple question about each one: what number would tell us it had gotten worse, and who looked at it this week?
If there is no number, you have an agent that will decay in silence. If there is a number and nobody looks, same result. If there is a number, and a person, and a threshold, you have something you can leave running. Most agents do not clear that bar. The ones that do are the ones still working next year.