give Claude a big enough task and it will quit halfway through, convinced it's done. the work isn't finished. it just can't remember starting.
an agent doesn't work on a long task the way you'd think. it works in shifts.
imagine a software project staffed by engineers working in shifts, where each new one shows up with no memory of what happened on the last shift. that's not a metaphor for how agents feel. it's mechanically what they are. the context window is finite, most real work doesn't fit inside one, so the agent works in discrete sessions - and every new session begins with no memory of the one before it.
anthropic ran exactly this experiment and published what broke. that's the part worth reading, because it isn't a blogger saying the tool is weak. it's the team that builds Claude documenting where Claude falls apart.
Why One Window Can't Finish the Job
give a frontier coding model a high-level prompt - "build a clone of claude.ai" - put it in a loop across many context windows, and it fails to produce a working app. not sometimes, reliably. and this is Opus running on anthropic's own agent framework, with context compaction turned on, the whole setup built to keep it going.
it fails in two specific ways, and both are shift-handoff problems.
the first: the agent tries to do everything at once. it attempts to one-shot the entire app in a single window, runs out of context halfway through a feature, and the session ends with something half-built and undocumented. the next shift clocks in, sees a mess it didn't make, and has to guess what was happening. so it spends its whole session just getting the basic app working again, instead of moving forward.
the second shows up later, once some features exist. a fresh agent looks around, sees that real progress has been made, and decides the whole thing is finished. but it isn't - half the features were never built, and nobody wrote down which ones. the shift called it done without checking the list.
both failures have the same root. the leaving shift left nothing behind, so the arriving shift is flying blind. the fix isn't a smarter model. it's what the shift writes down before it clocks out.
What the Leaving Shift Writes Down
the answer anthropic landed on has two parts: one agent that sets up the site before any work starts, and then the shift workers who show up session after session to make progress.
the setup agent runs once, at the very beginning. its whole job is to leave the environment in a state where every future shift knows what "done" looks like. the key piece it writes is a feature list - a structured file spelling out every single thing the finished app needs to do.
for the claude.ai clone, that meant over 200 features. things like "a user can open a new chat, type a query, press enter, and see a response." every one of them marked as failing at the start. each entry looked roughly like this:
1{2 "description": "New chat button creates a fresh conversation",3 "steps": ["click New Chat", "verify fresh conversation", "check welcome state"],4 "passes": false5}
that "passes": false on every entry is the whole point. it's an unchecked box, and there are 200 of them.
that failing list is the thing that stops an agent from declaring victory early. a shift can't look around and decide the job is done, because there's a file sitting right there with 200 unchecked boxes. the work is defined before the first line of it gets written.
one small detail that tells you how careful this had to be: they used JSON for that file, not markdown. the reason is that the model is less likely to quietly rewrite or delete a JSON file than a markdown one. and the instructions around it are blunt on purpose - it is unacceptable to remove or edit tests, because deleting a test is how a feature silently goes missing. the shift is allowed to check a box. it is not allowed to erase one.
The Note on the Desk
setting up the work is half of it. the other half is making sure each shift leaves the place clean enough for the next one to walk into.
two things do that. the agent commits its work to git with a real message describing what changed, and it writes a plain progress file - a running log of what's been done. that log alongside the git history is what lets a fresh agent, starting cold, understand the state of things in a few minutes instead of reverse-engineering it for an hour.
git does something else here too. when a shift makes a bad change, the next one can roll back to the last working version instead of trying to untangle the damage. the progress file says where we are. the commit history is the undo button.
and "clean" has a specific meaning. it means the kind of code you'd be fine merging to a main branch - no major bugs, orderly, documented. not "technically I made progress." the standard is: the next person could start a new feature without first cleaning up your mess.
How the Next Shift Clocks In
put those two things in place and every shift starts the same way. before touching anything new, the agent runs a fixed opening routine to get its bearings - the same thing a good engineer does walking in on a project they haven't seen in a while.
1run pwd to see which directory you're in - that's the only place you can edit2read the progress file and the git log to see what recently happened3read the feature list and pick the highest-priority thing that isn't done yet4start the app and run a basic check that core features still work5only then, start building
that fourth step matters more than it looks. before writing a single new feature, the agent boots the app and confirms the basics still work - opens a chat, sends a message, gets a response. if the last shift left something broken, this catches it immediately, before the new shift piles fresh work on top of a broken foundation and makes it worse.
this is the whole trick, and it's almost boring how simple it is. the leaving shift writes down what it did and what's left. the arriving shift reads that before doing anything. the handoff is the entire game.
Your Long Tasks Have Shifts Too
none of this is really about building web apps. anthropic tested it on code because code is easy to verify, but the shape underneath is the shape of every long task you hand an agent.
anything that won't fit in one window has shifts. writing a long report chapter by chapter. running a research project across a dozen chats. working through a big analysis over days. every time you start a new session on the same task, a fresh worker is clocking in with no memory of the last one - and if you didn't leave a handoff, it starts by guessing.
so leave one. before a long session ends, have the model write down what got done, what's still open, and what the next session should pick up first. keep that note somewhere it reads on the way in. it's the difference between a project that moves forward every session and one that keeps rebuilding the same thing over and over.
same model tonight and tomorrow. the only thing that changes is whether tomorrow's session walks in blind, or walks in reading last night's note.
it was never about how smart the shift is. it's about what it leaves for the one that comes next.
more breakdowns like this - https://t.me/+xYv1MgmIuds5YTli
