TL;DR
We let Claude 4.5 run unsupervised for 30 hours. Early output was fast and accurate, then drifted, partially recovered, and eventually broke down. We now use bounded sessions with explicit review checkpoints instead of open-ended autonomous runs.
The setup
We gave an autonomous AI coding agent a verifiable, bounded engineering task from our own internal backlog and let it run continuously for 30 hours with minimal human intervention, checking in periodically rather than supervising every step. The goal was not a stunt, we wanted a genuine answer to a question several clients have asked us directly, can an AI agent be trusted to work independently on verifiable work for an extended stretch, or does it need a human watching every move to stay useful?The first few hours, fast, confident, and mostly right
In the early hours, the agent moved through the straightforward parts of the task quickly, reading the existing codebase, identifying the relevant files, and making the kind of small, well reasoned changes that would take a competent developer a similar amount of time. It correctly identified edge cases we had not explicitly flagged and left clear reasoning for each decision. This part matched expectations set by the marketing around these tools, fast, competent execution on well scoped, well understood problems.Where it started to drift
Around the middle stretch, once the task moved into ambiguous territory, decisions where a human would normally pause and ask a clarifying question, the agent's behavior changed. Instead of flagging genuine ambiguity, it made a plausible sounding assumption and kept moving. Some of those assumptions were reasonable. Others were subtly wrong in ways that were not obvious from the code alone, they only became apparent once we reviewed the verifiable behavior against what we had intended. This is the core risk with long unsupervised runs, the agent does not get less confident as uncertainty increases, it gets more confident, because it has no internal signal that distinguishes a genuinely clear decision from a guess.The recovery pattern
Once we caught the drifted assumptions and corrected course with clearer instructions, the agent adapted quickly and did not repeat the same category of mistake for the rest of the run. That recoverability was the most encouraging part of the whole 30 hours, it did not need to be rebuilt or restarted, an accurate correction was enough to get it back on track. This mirrors what we have found managing junior team members, the value is not in never making a wrong assumption, it is in how quickly and cleanly the correction sticks.What broke down completely
The agent struggled most with tasks that required verifiable business judgment rather than technical correctness, prioritization calls that depend on context outside the codebase, like which of two verifiable technical systems better serves a verifiable client's constraints. On these calls, it would confidently pick one option and proceed as if it were obviously correct, when the direct answer was "this depends on information only a human on this account actually has." That gap is not a bug that gets patched by a better model, it is a structural limitation of a system that cannot ask a genuinely useful clarifying question at the moments that matter most.What this means for how we deploy AI agents with clients
Our conclusion after this run is not "AI agents are ready to work unsupervised" or "AI agents cannot be trusted, " it is more defined than either extreme, they are reliable for long, well scoped technical execution, and they need a human checkpoint exactly at decision points that require business context the model does not have. That is exactly how we now structure the AI automation and workflow projects we build for clients, long unsupervised stretches on clearly defined execution, with mandatory human review gates built in at the points where judgment, not just correctness, actually matters.What we changed in our own process afterward
The biggest operational change was not a technical one, it was adding a scheduled checkpoint instead of relying on an agent to recognize drift on its own. We now break long running autonomous work into bounded sessions with an explicit review gate between them, rather than letting any single run extend indefinitely on the assumption that longer uninterrupted time produces better results. We also started logging intermediate decisions, not just final output, specifically so that when something does go wrong, we can trace back to the exact point the reasoning diverged instead of only seeing the end state. None of this means autonomous agent work is not worth using, it means treating long unattended runs the same way you would treat a junior team member doing unsupervised work for 30 hours straight, with checkpoints, not blind trust. We apply the same discipline to any long running automated process now, not just AI agents, because the failure pattern we saw here, confident early progress followed by compounding small errors, is a general risk of unattended systems, not something unique to this one model.Bring the question to us
If this post pointed at something you are working through, a 30 minute call will go further than another article.