An agent that is stuck rarely says so. It keeps working, keeps producing output, keeps sounding confident. Learning to recognise the five shapes of an agent run going wrong - from the outside, quickly - is most of what separates people who get value from these tools from people who give up on them.
1. The poisoned conversation
Looks like: it fixes a bug, which breaks something else, which it fixes, which breaks the first thing. Round and round, each turn sounding reasonable.
What happened: something false entered the conversation early - a misread file, a wrong assumption about how a function works - and every subsequent step reasons from it. The model is not confused; it is reasoning correctly from a bad premise.
The move: start a fresh thread. Not "please reconsider" - a genuinely new conversation, describing the current state of the code as it is now. The wrong premise only lives in the history, so dropping the history removes it. Asking a bigger model to try harder just gets you more capable reasoning from the same bad premise.
2. The context wall
Looks like: it forgets a decision from twenty minutes ago, re-reads files it already read, or asks you something you already answered.
What happened: the conversation outgrew what fits, and something had to be dropped or summarised. Whatever got dropped is simply gone.
The move: put the durable facts somewhere that is not the conversation - the project instruction file. This is also the cheapest habit change available on cost, for the same reason. Conventions, the things not to touch, the command that verifies a change. Those get re-supplied every time instead of being remembered.
3. The unverifiable goal
Looks like: it says it is done. It is not done, or it is done wrongly, and nothing caught it.
What happened: nothing in the loop could tell right from wrong. The agent optimised for producing something plausible, because plausible was the only target available.
The move: give it something to check against before you give it the task. Vibe coding lives or dies on this. A test, a build, a command whose output is unambiguous. "Make it faster" with no measurement is the canonical version of this failure.
Which of the five is most common in your experience?
In our own logs, the unverifiable goal is the most common by a distance - and it is the one people are least likely to blame the setup for, because the agent's output looks like success. The poisoned conversation is the most frustrating, because the agent is visibly working hard while going nowhere.
4. Permission deadlock
Looks like: it stops constantly, or it silently avoids the approach that would have worked because it cannot run the thing it needs.
What happened: the tool it needed was not available, so it routed around it. Agents rarely announce this; they just take a worse path.
The move: when a run goes strangely indirect, check what it was allowed to do. An agent that cannot run your tests will write code that looks right instead of code that is right, and it will not tell you that is what it is doing.
5. The ambiguous instruction
Looks like: a technically correct answer to a question you did not ask.
What happened: your request had two readings and it picked the other one. This is not a model failure - a colleague would have done the same, except a colleague would have asked.
The move: state the outcome and the constraint. Not "clean up this file" but "split this file so the parsing and the network calls are separate, keeping the exported names". The second one has one reading.
| Shape | Tell | Fix |
|---|---|---|
| Poisoned conversation | Fixing its own fixes | New thread, fresh description |
| Context wall | Forgetting, re-reading | Facts into the instruction file |
| Unverifiable goal | Confident wrong "done" | Give it a check to run |
| Permission deadlock | Strangely indirect approach | Look at what it may run |
| Ambiguous instruction | Right answer, wrong question | Outcome plus constraint |
Notice what the fix column does not contain: "use a bigger model". It is the right answer to none of the five, and it is the first thing almost everyone reaches for.
Name the failure
Four scenarios. Diagnose each one.
The agent has "fixed" the same test four times, each fix breaking a different thing.
Fixing its own fixes is the signature. Something false is in the history and every step is reasoning from it - so the fix is a new thread, not a better prompt.
It reports the refactor is complete. The app does not start.
Nothing in the loop could distinguish done from plausible. If it had been able to run the app, the loop would have caught this without you.
It writes an elaborate workaround instead of the obvious three-line change.
Strangely indirect work usually means it could not do the direct thing. Check what it was allowed to run before you blame the model.
It asks you again about a convention you explained an hour ago.
The conversation outgrew what fits and your explanation was dropped. Durable facts belong in the instruction file, which is re-supplied every time.
Sources
- This taxonomy comes from our own dogfooding and support logs while building W1 through 2026, not from a published study. Read it as field notes.
- Our changelog documents fixes for several of these shapes in the harness itself - the context wall in particular.
Built around these five
Most of what W1's changelog describes is the harness getting better at exactly these failures. Free during beta.
Download free beta