The loop goes like this. The agent produces something disappointing. Somebody suggests the new model. You switch. It is better for about a week. Then the same class of failure comes back, and the next model ships, and around you go.
We have watched a lot of teams run this loop and we don’t think the model is what is limiting most of them.
The diagnostic
Take a task your agent recently failed at. Now do the retrieval by hand. Open the relevant files. Find the decision that explains the constraint that looks arbitrary. Dig up the incident from last quarter that is the reason the retry logic is shaped that way. Grab the test covering the adjacent case.
Paste all of it in. Ask the same model the same question.
It usually works. Not always. But often enough that if it works for you, the model was never your problem. Your problem is that nothing in your setup could assemble that context without a human spending twenty minutes doing it by hand.
That is a retrieval failure wearing a reasoning failure’s clothes, and no model upgrade will touch it.
Why the mistake is sticky
Switching models is easy. One line, immediate measurable difference, feels like progress, and sometimes genuinely is.
Building the layer that knows what to hand the model is slow and invisible when it works. So teams pull the easy lever again and again while the actual ceiling stays exactly where it was.
Which is why we stay out of the model business
Use whichever frontier model you already pay for. Use an open-weight one. Run something on a machine under your desk. We sit underneath all of them and we get better every time any of them does.
Every lab on earth is spending serious money making the models smarter. Almost nobody is making sure they can see your codebase. We would rather work on the second problem.