The thing that surprises practitioners most when they start delegating real work to AI agents isn’t how often they fail. It was how quietly they did it.
An agent running off stale context doesn’t stop and say so. It keeps producing output. The sentences are fluent. The formatting is clean. Nothing on the surface signals that the policy it’s citing is six months out of date, or that the permission you gave it last quarter is now too broad for the model it’s running on. It just keeps going.
This has happened with content pipelines still summarizing material from an archive instead of current sources. It shows up in support-adjacent workflows where the agent was drafting from a policy the team had quietly updated. The agent wasn’t broken in any obvious way. It was just wrong, confidently.
This is what people mean by “silent failure”: the agent continues working while operating from increasingly wrong context. Most agent failures aren’t crashes. They’re drift.
The harness, not the model
The framing shift that matters most is separating the model from what practitioners call the harness — the system around the model. That’s the job definition, the sources it reads, the memory it builds on, the tools it can call, the permissions it carries, the proof it produces, and whether anyone is still getting value from the work.
The model is actually the part that needs the least maintenance. The big providers keep improving it. The harness is what you own, and it drifts. Here are the seven surfaces worth checking systematically.
The seven-part check
Job. Can the agent’s function be described in one sentence? “Help with support” is not a job. “Draft refund replies for subscription cancellation tickets from the current refund policy, Stripe status, and recent customer thread, for support reviewers, with human approval before any message is sent” is a job. Agents drift when their scope grows silently. The job definition is the anchor; everything else gets checked against it.
Diet. What is the agent reading? Policies, documentation, examples, previous outputs. Stale diet produces stale output. Bad examples teach bad standards. The check is whether the sources the agent depends on have been updated since the harness was last touched.
Memory. This one matters more than expected. Recent research found that agents with memory show what’s called “experience-following” — similar past outputs get retrieved and similar future outputs get produced. That sounds useful until you realize that wrong or outdated memories propagate forward too. One study found that adding memory pushed a certain category of tool-use failure from around five percent to more than fifty percent. Old memory entries are best treated as technical debt.
Tools. This isn’t about adding more tools. It’s about removing the ones that have become confused, narrowing the ones that are too broad, and improving descriptions. Tool descriptions need as much care as prompt work. If a tool was built as a workaround for something the model couldn’t do six months ago, that workaround may now be an active constraint.
Reach. The actions an agent can take: read-only, draft, create, send, publish. Reach should change as evidence changes, not as enthusiasm changes. An agent that can only draft produces a review problem when it goes wrong. An agent that can send produces a live mistake. Reach should stay as narrow as it can be while still being useful.
Proof. Is there a visible record of what the agent actually did? Which policy it cited, which record it read, what it skipped, what it couldn’t verify. An agent that produces polished final output with no visible trail is much harder to maintain and much harder to catch when something goes wrong.
Value. Is anyone actually using the output? Sometimes the honest maintenance answer is retirement. That isn’t failure — it’s maintenance. An agent that keeps producing unread reports while nobody checks it isn’t helping anyone.
The habit that’s hardest
Of the discipline worth building around this, the hardest step remains: delete before you add. When something goes wrong, the natural reflex is to write another instruction. But very often the real fix is removing the stale source, pruning the outdated memory entry, or narrowing the tool that’s doing too much. Adding instruction on top of drift doesn’t fix drift.
A small test worth running after any maintenance change: a replay pack — a set of known cases with known correct behavior — run against the updated agent before it touches live work again. Historical tickets with known routing, past drafts with a known quality bar. If it passes those, there is some confidence to work from. If it doesn’t, nothing real has been broken yet.
The agents worth trusting most aren’t the most capable ones. They’re the ones maintained honestly — narrow job, current sources, earned reach, visible trail.
The question worth asking at the start of every maintenance pass: if this agent went wrong today, would the team know within a day? If the answer is no, that’s where to start.
Text summarized and optimized using Anthropic’s models and reviewed by a human.