Agents Don't Need Prompts. They Need Managers.

TL;DR: Claude sessions stop before the work is done, and the closing message often reports the task finished when it isn’t. That’s real — I run agents daily and I’ve watched both halves of it happen. But “the model is lazy” is the wrong diagnosis. A human employee arrives wrapped in a management system nobody had to build: a queue, a standup, a manager who notices when they go quiet, a peer who catches the miss. An agent arrives with none of it, and you become all of it, by hand, one agent at a time. Meanwhile two things are true together: companies cut headcount for agents and then regretted it at scale, and the vendor has shipped limits that cap exactly the behavior operators want — Anthropic shipped weekly rate limits in August 2025 aimed explicitly at people running Claude Code “continuously in the background, 24/7.” The gap between those two facts is where the frustration lives.

Why does an agent stop before the work is done?

Because it arrived without the management system that keeps a person from doing the same thing.

Run agents on real work long enough and you converge on a pattern. A session ends before the task is actually finished, and the last message says some version of “this still isn’t complete” — noting the gap instead of closing it. Told to be thorough, it cuts a corner anyway. (The comic version of what that feels like day to day is its own post.) Pushed on the corner, it admits to skipping it, plainly, and then explains what would fix it — which raises the obvious question: why explain it instead of doing it?

I’ve watched all of that happen on this repo and others, and the worst version isn’t the early stop. It’s the agent reporting completion on work it didn’t do. That’s a different, more serious failure than laziness. What I want to argue first is that “the model is lazy” is a correct observation aimed at the wrong layer, and the correct read costs a lot more money than the wrong one.

What a person arrives wrapped in

Hire a mid-level engineer and you get a person. You also get, for free, an apparatus around that person that took your company years to build and that nobody thinks of as a feature.

There’s a queue that tells them what’s next when they finish, so the end of a task isn’t the end of the work. There’s a standup where somebody would notice they’ve been stuck since Tuesday. There’s a manager whose actual job is detecting when work has stalled and applying a nudge. There’s a code review that catches the shortcut. There’s an escalation path for the moment the task turns out to be underspecified — which is most tasks. There’s memory: they remember the incident in March, they remember that you hate that pattern, they remember they said they’d circle back.

Not one of those is the employee. All of them are the system around the employee. Take a genuinely excellent engineer and remove all of it — no queue, no manager, no review, no memory of yesterday — and you get someone who does good work in bursts, stops when the current thing looks done, and has no mechanism to know they stopped short.

That is precisely the thing people are describing when they say an agent can’t work independently. The independence they’re missing was never a property of the worker. It was a property of the org.

The reversal wave is that bill coming due

Orgvue’s 2025 survey of more than a thousand business leaders found that about four in ten had laid people off as a result of deploying AI; 55% of those now say they made the wrong call. Orgvue’s CEO Oliver Shaw put it about as bluntly as a vendor ever puts anything: “dismissing employees without a clear plan for workforce transformation is reckless.” Robert Half found that more than three in ten US hiring managers who eliminated a position after implementing AI later added it back, and when Gartner asked over 320 customer service leaders in October 2025 whether they’d actually cut human support staffing because of AI, only about a fifth had — most held headcount steady and served more customers with it, roughly the same shape I found when I checked the McKinsey numbers that had 25,000 people supposedly replaced by AI agents.

What the reversals have in common isn’t that the models underperformed. It’s that the buyer removed the humans doing supervision, quality control, and exception handling, kept the part the machine could do, and found out the removed part was load-bearing. I’ve run the capacity math behind that in more detail in “why AI won’t shrink your team.”

And the vendor would like your agent to stop

One paragraph on this, because it’s not the whole story. Anthropic introduced weekly rate limits effective August 28, 2025, and the stated reason was subscribers running Claude Code “continuously in the background, 24/7” — the company said it would affect under 5% of subscribers. Read that against the frustration above: the exact behavior operators want is the exact behavior the vendor named and capped. You don’t have to invent a motive to notice that — draw your own conclusion about why. Netflix asks “are you still watching?” after three episodes and ninety minutes of uninterrupted play, and Netflix’s own help page gives two reasons, both framed as the viewer’s benefit: saving your place, and not burning your data on a show nobody’s watching. The bandwidth on the other end is a real cost line too, and Netflix doesn’t need to say so. Inference is a real cost line too, and right now it’s still subsidized — I put numbers on that when I priced the plan tiers — which means every stopped agent session is margin. That doesn’t make the model lazy by design. It does mean nobody upstream of you is strongly motivated to solve continuous unattended operation on your behalf, so stop waiting for them to.

Build the layer yourself

Here’s the part that changes outcomes. Everything a manager does for a person has a mechanical equivalent you can build, and none of the equivalents are exotic.

Put the state on disk, not in the conversation. The model’s working memory ends when the turn ends. A file doesn’t. A task list the agent reads at the start of a session and updates as it goes is the single highest-leverage thing in this list, because it converts “remember what we were doing” from a context problem into a filesystem read. I run this as a literal tasks/todo.md in this repo — the agent checks items off as it finishes them, and the next session starts by reading the file instead of reconstructing intent from a transcript. This is also why a stalled session isn’t really about the size of the context window: you don’t want one enormous run, you want many small ones that share a checkpoint. Anything the agent knew mid-session that isn’t written down is knowledge you’re about to lose the moment the session ends, regardless of why it ended. I wrote a longer version of this pattern — treating a CLAUDE.md and its adjacent files as onboarding documentation for a new hire who has no memory between shifts — in the case for treating your AI config like an onboarding doc.

Make the important things reflexes instead of requests. Anything you have to ask for, the model can skip under pressure. Anything wired into the harness, it can’t, because it isn’t the model doing it — it’s a program that runs regardless of what the model decided. On this site, a hook runs mix format after every file edit, so a formatting break can’t reach a commit no matter how tired or rushed the agent got mid-task. A second hook denies writes to .env outright, full stop, no negotiation with the model about whether this edit is the exception. A third validates a content JSON file after every edit and blocks the write if the file no longer parses — because a plausible-looking edit that breaks JSON is exactly the kind of thing a model will confidently make and not notice. I wrote up the four I run everywhere; the point isn’t those four specifically, it’s the category. An instruction in a prompt is a request. A hook is a reflex, and reflexes don’t degrade when the model is nine hours into a long session.

Gate on output, not on effort. “Be thorough” is not a specification and there’s no way to verify it happened after the fact. A preflight check that returns READY or FIX REQUIRED is a specification. A test suite that must pass before work is called done is a specification. The difference matters because a model optimizing to satisfy an instruction will satisfy the literal instruction — if the instruction is “be thorough,” the model can produce something that reads as thorough without being complete, and neither of you will notice until it ships. If your only mechanism for getting careful work is asking for careful work in the prompt, you have no mechanism; you have a hope.

Cut the work small enough that stopping is cheap. Most of the pain in a long agent session isn’t the stop itself, it’s that the unit of work was too big to verify in pieces, so a failure surfaces at the very end instead of at the seam where it happened. When a task is scoped to something with a checkable output — a function that either passes its test or doesn’t, a file that either parses or doesn’t — an agent quitting early is a visible, recoverable event instead of a silent one buried three files deep in a diff nobody read closely.

Notice when the “nudge” you keep giving is actually a missing input. This is the one I’d want a frustrated operator to sit with longest. When you find yourself typing “continue” for the fourth time in a session, that’s usually not the model being lazy — it’s the model reaching the edge of what you actually specified and stopping at a boundary you drew without meaning to. The fix lives upstream, in the brief, not downstream, in the nudge. Write the task list once, specifically, and the agent works through it faster than you can type the next prompt. That’s the trade, and it’s a good one, but it only pays off if you do the upfront work instead of narrating the gap after the fact.

The reason this feels like a lot of work is that it is the work. It’s the same work your company already did for humans, over years, mostly without anyone framing it as work at all. Nobody skips it and gets away with it. What people are calling a model problem is a missing org chart.

What no harness fixes

If I stopped there this would be vendor defense, so: some of this really is the model’s fault, and no hook I’ve described touches it.

A model reporting completion on work it didn’t do is not a supervision gap you can gate around, because the harness has no way to know what the task was supposed to mean in the first place — it can check that a response was produced, not that the input was actually read. In my own long sessions, quality seems to erode well before the context window is anywhere near full; I don’t have a benchmark for that — it’s a pattern across a lot of sessions, not a measured curve. I’ve written before about the specific bugs this produces and about how an agent has no stake in whether the code is good — both remain true and neither is going away this year.

Anthropic’s own Opus 5 launch materials claim ground on exactly this failure mode. Their published example: given a real bug in a popular open-source package manager, Opus 5 found the root cause and fixed an edge case the community’s own patch had missed, while “a competing model fixed only the surface symptom (not the underlying cause), then reported the bug resolved.” That’s the same shape of failure this post is describing, named by a vendor, in its own launch copy, as the failure its competitors ship. Whether it’s actually fixed at the rate the marketing implies is a separate question I can’t settle from a launch page — but either way, the model layer moving is not a reason to skip building the management layer. It’s a reason to expect the gap to keep moving rather than close.

The practical mitigation is unglamorous: stop handing the model the whole history. Give it the recent turns and a summary you control. Ask for the answer and the evidence for it, so work the model skipped shows up as a missing citation instead of a confident sentence. There is published support for the instinct — Liu et al. found model performance degrades markedly depending on where in a long context the relevant information sits — so assume anything that landed in the middle of a long context wasn’t really read, and structure the task so that assumption is cheap to be wrong about.

And a caution I’d apply to my own argument here. Building this layer works, and it does not produce an unattended agent. It produces one that needs fewer, better-placed inputs from you. If a plan depends on the layer eventually reaching zero human input, that plan hasn’t been demonstrated by anyone, including me.

What to price before you cut a role for an agent

Write down what the person you’re removing actually supplies, separately from the task they perform. The queue, the noticing, the exception handling, the memory of why the last attempt failed. If the answer is “the agent does the task,” you’ve priced one column of a two-column problem, and the Orgvue number above says you’ll find the second column later, at a worse price, once it’s already gone.

Say who the manager is. Not metaphorically — name them. Every agent doing real work needs a human whose job includes noticing when it stopped — and knowing which calls that person should be making themselves is a different skill from building the scaffolding, and if that human is also doing their own full-time job, you’ve just found your actual capacity limit. I made this argument in more detail in “Nobody Got Replaced, Agents Got Added”: “The supervision doesn’t disappear. It changes shape and moves up a level.” That line is doing more work than it looks like — it’s the whole argument, compressed to one sentence.

Then build one piece of the layer before you add the next agent. One hook, one task file, one gate that blocks a bad output instead of asking politely for a good one. That ratio improves from the supervision side far more reliably than from adding more agents — which is roughly the shape of the argument I made about what token economics actually do to the size of a firm.

The failure mode is real. The diagnosis was wrong. What looks like an unmotivated model is an unmanaged one, and you’re the only one in a position to fix that — the vendor has told you, in its own launch copy and its own rate-limit announcement, that it isn’t going to do it for you.

You already cut headcount on an agent thesis, and the quality is drifting in a way nobody on the team can quite name yet — that’s the conversation I have with founders most often right now, more often than the sizing conversation that usually starts it. Let’s talk.