A hands-on report from 726 runs of a Qwen3.6-35B agent reveals that real-world agent failures are less about reasoning and more about clerical errors, overconfident success reports, and the cost of overthinking — offering practical lessons for agent builders.
We spent the last days running Qwen3.6-35B model through 18 real tasks, over and over — 726 runs in total. File work, cleanup jobs, talking to a live calendar and a CRM. The point wasn't a leaderboard number. The point was: if I let this thing work unattended for twenty minutes, what actually goes wrong? I expected reasoning failures. Tasks too hard, logic falling apart, the model losing the thread. That happened maybe least of all. Here's what I actually found, and every single one of these changed how I build. It doesn't fail at thinking. It fails at typing. The most common fatal error in the entire set was a single wrong character in a long file path. The model reasoned correctly, planned correctly, and then wrote to a folder one character off. The tool said "written." The agent said "done." Everything downstream was built on a file that nobody would ever find. There is no amount of smarter reasoning that fixes this — it's a clerical error, and clerical errors are invisible from the inside. "Done" means nothing. One run processed 11 of 12 customers and reported that all 144 records were complete. Another rewrote two dozen files from memory instead of opening them, and signed off cheerfully. The agent isn't lying. It genuinely believes it. Which means the agent's own report of success is not evidence of success — and if that's what your pipeline is checking, you aren't checking anything. When the instruction is ambiguous, it picks the destructive reading. Asked to merge two customer folders, one run simply deleted one of them. Task complete, by its own account. Ambiguity doesn't make an agent hesitate. It makes it commit. It changes plans only after it hits a wall — never after it sees the sign. Two runs, same task. One kept going until a hard crash forced a rethink. The other revised its approach on step 140 out of 151. The warning signs were there much earlier in both. Humans slow down when things feel off; an agent doesn't have "feels off." More thinking made it worse, not better. On the tasks where it had to interact with a live system, the model without extended reasoning scored higher than the same model with it. It thought so thoroughly about step three that it ran out of room before step nine. Deliberation has a price, and in a loop with a budget, that price is finishing. And the thing I'd tell anyone comparing models: the overall score is close to useless. Two configurations of the same model landed a few points apart in aggregate — and swung 40 to 60 points against each other on individual tasks. A single number hides exactly the information you need. None of this is an argument against agents. It's an argument that the hard part sits somewhere other than where most of us are looking. The model is smart enough. The loop around it is what decides whether that matters. Full write-up with the actual failed runs is on the platform I built for this — link in the comments. Ask me anything.
The author analyzed 155 AI agent jobs and discovered that most failures stemmed from infrastructure issues like timeouts and false success signals, not model errors, leading to practices such as asserting on effects and using multiple verification paths.
The article discusses how AI agents often fail silently by completing tasks incorrectly without crashing, leading to undetected errors. It highlights common failure modes and explores potential detection strategies.
The author discusses the unglamorous but critical aspects of engineering reliable AI agents in production, including monitoring mid-flight runs, resuming failed runs, and providing UI status, and asks the community about common pain points and off-the-shelf solutions.