You stop trusting the agent before you stop using it
By Maximo Correa · 2026-08-19
When an AI coding agent stops reliably following instructions, people do not report it as a missing feature. They start re-reading outputs they used to skip, re-checking work they had stopped checking, and narrowing what they hand off, all before anyone reports a bug. The felt problem is trust, not capability.
The tell is not a bug report
Something changes in how you work with an agent, and it is not a complaint you would ever file. You do not open an issue that says the trust is lower than it was last week. You start reading the diff again, line by line, on a change you used to glance at and merge. You reopen the file it said it edited, to check. You give it the small task instead of the one you meant to hand off.
None of that shows up anywhere. There is no counter for "things I used to not check." The only visible symptom is a shrinking set of tasks you are willing to hand off without reading closely, and it shrinks quietly, one task at a time, long before anything breaks loudly enough for anyone to report.
How people actually describe it
Search for the complaint and it rarely names a missing feature. A Hacker News thread titled almost exactly "Claude often ignores CLAUDE.md" is not full of people asking for a setting. It is full of people saying "it forgets what I told it after a while," or "my agent goes wild," or, in the sentence the whole pattern comes down to: "I set this up and it still does its own thing."
That last sentence is the one worth sitting with. "Still" is doing the work. This is not a first impression. It is someone describing a rule they wrote carefully, watched hold, and are now watching fail again, in the present tense, as something that keeps recurring rather than something that happened once.
Why decay reads as distrust, not a missing feature
A missing feature has a name. You ask for it, someone ships it, and the request closes. Instruction decay does not behave that way. Published measurements of instruction compliance across coding agents put it near 95 percent early in a session, falling to somewhere between 20 and 60 percent by message six to ten. That is not one rule breaking once. It is the same rule holding, then not holding, on no schedule anyone announces.
You cannot file a bug against a schedule you cannot see. What people do instead is stop assuming the rule holds and start checking for themselves. That is not a workaround for a missing capability. It is the behavior of someone who no longer takes a claim on faith, and that is a different problem than the one a changelog closes.
What the checking actually costs
Nobody in these threads writes this part down. The posts describe the moment trust broke, not the accounting that follows it. But the accounting follows anyway: the entire value of delegating a task is that you do not have to do the parts you delegated. The moment you start re-reading every output and re-running every check you used to skip, you are paying for that work twice, once in the agent's time and once in your own.
In practice the checking is unglamorous and specific. You stop trusting that a commit message describes what actually changed, so you read the diff instead of the summary. You stop trusting that a test run was real, so you rerun it yourself before you believe it. You stop trusting that "done" means done, so you open the file it claims to have finished. None of these are hard. Each one just quietly cancels out the time you thought you had bought back.
Narrowing what you hand off has the same shape from the other side. If the biggest task you will delegate without checking it keeps getting smaller, no single request has to fail for that to happen. The agent is just being trusted with less, a little at a time, and no dashboard reports it. It is one of the quieter ways a tool can lose most of its value while every individual session still looks fine.
Trust does not come back because you ask nicer
Writing the instruction in capital letters, or repeating it every prompt, treats this like an emphasis problem. It is not one. The instruction was not unclear the first time. It held, then stopped holding, for reasons that have nothing to do with how loudly it was written. Trust that leaves on a schedule like that does not return because you asked politely. It returns the way it left, slowly, and only after the thing you stopped believing holds again, in front of you, more than once.
That points at two different fixes, and they are not the same fix. The instruction needs a mechanism that survives past the first read of it, not a louder version of the same read. And whatever is making the decision on your behalf needs to be something you can open and check, not a claim you are asked to take twice.
A way to see it happening in your own work
You do not need anyone's research to check whether this is already true of you. Think of the last task you handed off without reading the result closely. Now think of the one before that. If the earlier one was bigger, or you checked it less, the pattern is already running in your own habits, whether or not you have written it down anywhere. The honest version of this test is not "does the agent still work." It is "what is the biggest thing I would let it do unsupervised right now," asked again next month.
What we build toward
We think the second fix matters as much as the first. Flowy ships every Auto-invoked plugin with a plain FLOW.md router, the routing decision written down in a file you can read before you decide whether to believe it. Trust that has to be taken on faith is exactly the thing that erodes here. Trust you can check does not have that problem, because there is nothing left to take on faith.
