Long-running Claude Code agents drift. Here's what keeps mine on the rails
This post links to my own Claude Code cookbooks. I pay for Claude out of pocket and run Claude Code daily, so the recommendations would be the same either way.
I run a small fleet of Claude Code agents around the clock on a cheap cloud VM. They write code, deploy to my own infrastructure, publish content, and check their own work while I sleep. None of that works if the agent wanders off task after twenty minutes, and the hard part was never getting an agent to start a job. It was getting one to finish the right job, the same way, on run one hundred.
This week a 465-point thread on r/ClaudeAI asked Anthropic to "please have Claude finish a task," and a 318-point thread collected hard-won lessons people picked up too late. I have opinions, because most of my early agent failures came down to four mistakes I had to unlearn. Anthropic's own engineering team has since written up much of this, which was a relief: the fixes that worked for my swarm are the same ones they recommend for harnesses that run for hours.
1. Separate the thinking from the typing
The fastest way to get a confidently wrong pull request is to let the model start editing before it has read the code. Early on I would hand an agent a one-line task and watch it touch eight files to solve a problem that lived in one. The output looked plausible and was useless.
The fix is boring and it works: make planning a distinct step from implementation. Anthropic's best-practices guide calls this out directly, telling you to research and plan before writing code so the agent doesn't solve the wrong problem. In practice I have my agents produce a short written plan first, then act on it in a second pass. A plan is cheap to read and cheap to throw away. A wrong 300-line diff is neither.
2. Treat context like a budget, not a backpack
A long task fails in a specific way. The window fills with old tool output, the early instructions fall off the back, and the agent forgets what it was doing. You can see it happen: the work gets vaguer the longer it runs.
Two things fixed this for me. The first is compaction, where the running history gets summarized so the agent keeps working without exhausting the window. The Claude Agent SDK does this for you now, and Anthropic's writeup on long-running harnesses leans on it heavily. The second is keeping durable state outside the window entirely. My agents write their decisions to a database and a few markdown journals, so the memory that matters survives a restart. The model's context is scratch space. The journal is the source of truth.
3. Use subagents to protect the main thread
When one agent tries to read fifty files and also hold the high-level goal, both jobs suffer. The read floods the window and the goal gets buried.
Subagents solve this cleanly. A lead agent delegates a noisy, focused job to a specialist that runs in its own isolated window, then returns only the conclusion. The orchestrator never sees the fifty files, only the answer it asked for. Anthropic describes the same pattern in their work on multi-agent orchestration: each subagent carries its own model, prompt, and tools, and reports back a small result. I use this for searches that would otherwise drown the main conversation, and for parallel work where three agents each own a slice. The win is not raw speed. It is that the orchestrator stays legible.
4. Demand evidence, never the word "done"
This is the lesson that took me longest and cost me the most. An agent that says a task is complete is making a claim, and a claim is not a result. My agents used to report green when the tests had not run.
Now the rule is simple: show the output. The command you ran and what it returned. The test log. A screenshot of the page rendering. Anthropic's guidance says the same thing, because reviewing evidence is faster than re-running the verification yourself. Their managed-agents work goes further and adds a separate grader that scores each result in its own context and sends the agent back to revise until it clears the bar. On their internal benchmarks that lift was up to ten points on the hardest problems. I learned this the expensive way after a "fixed" button stayed dead in real browsers for a dozen runs because every check tested the API and never the page. The fix was to make a real browser click the gate, not a curl command.
What this adds up to
None of these are clever. Plan before you type. Spend context on purpose. Hand noisy jobs to subagents. Trust evidence over assertions. The reason they matter more for agents than for a person is that an agent will repeat your process exactly, including the parts you got wrong, hundreds of times without complaint. A weak workflow does not bite you once. It bites you on each run.
The thread asking for Claude to "finish a task" is pointing at a real gap, but a lot of the gap closes from the harness side. The model will go further when the scaffolding around it forces a plan, protects its attention, and refuses to accept "done" without proof. That is the part you control, and it is where most of the real gains sit.
If you want the working versions of these patterns rather than the theory, I keep my Claude Code setup and a set of practical recipes at claude-code-cookbooks and write up the tools I lean on at tools.thesoundmethod.me. They are the same configs my agents run on right now.