Plausible Is Not Proven
Two approaches read equally well. One of them has already failed in your environment. Nothing in the text tells your agent which one.
A query is slow, so you hand it to an agent. It reads the schema, looks at the plan, and tells you to add an index on the filtered column. That is a good answer. It is the answer in every article ever written about slow queries, which is a large part of why you got it.
It is also the answer your team tried fourteen months ago and reverted inside a week, because that table takes a heavy write load and the index cost more on every insert than it ever returned on the read. Somebody wrote a paragraph about it in a pull request nobody has opened since.
The agent did not make a mistake in reasoning. Its answer was correct in general and wrong here, and it had no way to know the difference, because the thing that separates those two states is not present in anything it can read.
Fluency and evidence are different properties
Models are built to produce text that reads well. That objective is extremely good at surfacing the approach a competent engineer would propose, which is genuinely useful and is why any of this works at all. The trouble is that "reads well" and "has held up here" are unrelated properties, and only the first one is recoverable from text.
Put two approaches side by side in a design doc and the failed one does not look worse. It usually looks better, because whoever wrote it up was making a case for it at the time. The record of it failing lives somewhere else entirely: in an incident channel, in a revert commit, in the memory of the engineer who was on call. By the time the agent reads your codebase, the losing approach has been deleted, which means the evidence about what does not work has been systematically removed from the only surface the agent can see.
Your repository is a record of what survived. It is not a record of what was tried.
Why this gets worse as agents get better
When an agent was only writing single functions, plausible was mostly fine. The blast radius of a reasonable-but-wrong suggestion was one review comment. Agents now pick strategies: which migration path, which retry policy, which service to change, which thing to do first. At that altitude the cost of choosing the approach that reads best is not a review comment, it is a week of work aimed in the wrong direction, and it is spent before anybody notices the direction was wrong.
This is also why better models do not solve it. A sharper model produces a more convincing case for the same approach. Convincing was never the missing ingredient.
What actually separates the two
The only thing that distinguishes the proven approach from the plausible one is what happened when somebody tried them, and that is a fact about your environment rather than about software in general. An agent that has that history behaves differently in a way you can watch: it stops proposing the thing you already ruled out, and when it does propose something contested it can tell you what happened last time rather than arguing from first principles.
That is the difference Hyperstruck makes. Agents act on what has actually worked in your environment, not on what reads best, and the approach that failed here stops coming back around every few months wearing a fresh justification.
The change is quiet. Your agent stops being a very well-read stranger and starts being someone who has worked here a while, and you stop spending your review time explaining the history of a decision to something that will need it explained again next month.