The AI Teardown· August 14, 2026
The Fix For Unattended Agents Wasn’t What You’d Think
A team billed it as a “40 minute unattended run.” It was six interruptions strung across an afternoon.
The agent wasn’t wrong about anything. It just wouldn’t stop asking.
Every ambiguity became a question, and every question meant someone had to stop what they were doing and answer it.
Four months and 63 tickets in, the fix wasn’t a smarter agent. It was deleting the tool that let it ask.
The team removed one tool, but didn’t expect where the risk went next
The team asked for holes, and over in r/AI_Agents the sharpest reply named the actual failure: “the mutation seam.”
A silent default is harmless on a draft.
Nobody gets hurt if the agent guesses wrong about a local diff. You just fix it next commit.
The same silent default on a remote mutation is a different animal entirely. That’s where the real damage was hiding, not in the questions removed, in the ones nobody replaced with anything.
Aggravating-Risk1991 found the part that survives even a careful fix: the system greps CI to prove the question tool is gone, then trusts a confidence score from the exact process it just declared untrustworthy.
Unsurprisingly, nobody in the thread asked who grades the grader.
His fix asks the agent nothing. Count files touched outside the ticket path, new dependencies, new APIs.
Proxy signals the agent can’t flatter, because it never gets asked to grade itself at all.
Everyone else in that thread tuned the confidence number, the same number nobody had explained why it deserved trusting in the first place. He deleted the need for one, and it cost him nothing except admitting the number was never load-bearing.
The failures were never in the reasoning
726 runs, 18 tasks, one open model, and the failure mode nobody in the thread predicted.
“Writing a file to a wrong-but-valid path is a completely successful operation.” The tool did exactly what it was asked, the task still failed anyway, and nothing in the loop noticed.
It got confused least of all. What actually broke it was typing.
Six of nine failed runs on one task dropped the same identifier. Not a random one, the last one, every time.
In fairness, 726 runs is a serious sample size for a typo problem. Most benchmark claims in this industry don’t survive three.
The best fix for lost ideas wasn’t the one everyone tries first
The best integration between a phone and a coding agent turned out to be a folder of plain text files. One markdown file per idea, written straight into the project’s own folder.
No API, no backend, no MCP server, nothing to maintain on the agent side. Claude Code reads files, so files are the integration.
The build-vs-buy instinct usually runs the other way. Find the API, wire the sync service, make it real infrastructure.
Here the dumb answer beat the engineered one, and it was tested properly before it got called done. Siri won’t dictate free text into the shortcut, only the app will, three tries on a real device before that got written down as fact rather than assumption.
The real lesson is smaller than “use files.” Naming the project takes one second at capture time, and skip that second and the idea sits in an inbox nobody sorts.
Branching solved the wrong half of the problem
On database branches for agent writes: branch the production data, let the agent do whatever it needs inside the branch, review one final diff instead of approving twenty individual actions.
TeagueXiao’s pushback is the actual finding here. Branching solves the babysitting problem by relocating it.
You stop approving actions one at a time and start reviewing a merge instead. A diff across six tables at 2am is not meaningfully more reviewable than twenty individual prompts were.
The pitch was fewer approvals. The receipt says the same approvals, batched and renamed.
The pipeline claimed 100% success. The facts told a different story.
An orchestration command exited clean and went green after executing zero phases and shipping nothing.
The dashboard said done. The work said otherwise, and nobody checked which one was lying.
jonah_omninode’s own diagnosis is the whole story: the team had quietly redefined “done” as “did not crash.”
His own fix, offered in the same thread after a commenter described an identical two-week silent failure: require an artifact.
Existence and size prove something was produced, not that the right work happened. That’s a lower bar than it sounds, and it still would have caught this.
The one thing you can rely on agents never to do
Non-deterministic agents break traditional CI, and most evals grade the final answer instead of whether the agent picked the right tool along the way.
Potential_Purple7511’s fix treats tool-call correctness as ordinary deterministic code: track pass^k, not pass@k, “because pass@k looks great in a demo and lies in prod.”
Six replies agreed with him. Zero pushback.
One line buried in the middle actually said something structural: “the dataset is the asset, the harness is just plumbing.” Everyone in that thread was talking about the plumbing.
The write-access debate everyone else is getting wrong
How far do you let an agent write to production? Asked plainly, for ERP and CRM, and three positions showed up, only one of which actually solves anything.
Enough-Mind-1645 gates CRM writes above a 95% confidence score, human on order confirmations.
TeagueXiao says the real axis isn’t reversible-versus-not, it’s blast radius times detection latency.
Aggravating-Risk1991 goes further. The confidence numbers are measured on the common path, and the writes that cause real damage live in the tail those numbers never sample.
All three are still trying to predict which write is safe in advance.
Livid-Somewhere-8431 gives up on that question entirely: unsupervised is fine wherever a bad write is “cheap, reversible, and detectable,” because at that point the pre-write confidence number stops mattering.
“The fuse sized to the load, not to how much I trust the generator” names the real shift. He stopped trying to predict the mistake and made it cheap instead.
Every other build in this thread is still betting on being right. His is the only one betting on being wrong safely, which is the actual definition of production-ready.
Also worth the scroll
Someone ran one planning prompt over ten app ideas and read every step instead of trusting it once it looked done.
Eight of ten buried real work in a step called “polish.” The fix costs nothing: drop the target count from the prompt, since the model reads a number as a quota, not a ceiling.
“Memory is the whole ballgame.” The gap between a writing tool and a writing agent is almost entirely whether it remembers what it corrected last time.
By the numbers
- 726 real-world agent runs, across 18 tasks on one open model
- 63 tickets carried from intake to merged PR over four months, on one deleted tool
- 6 of 9 failed runs on one task dropped the same identifier, never a random one
- 8 of 10 build plans buried real work inside a step called “polish”
- 95% the confidence floor one builder sets before an agent may touch a CRM field