The capability shift of 2026 is duration. Agents stopped being request-response and started running for minutes, then hours. Multi-agent setups fan work out across a plan-implement-test pipeline. Cloud agents run asynchronously, off your machine, without a terminal window you are watching.
The seductive framing is free work overnight. That is not wrong, and it is not the whole picture, because delegation to something unattended has the same structure whether the delegate is a person or a model: the quality of the outcome is decided almost entirely by the quality of the brief, and you find out how good the brief was much later than you would like.
Supervised delegation lets you correct course mid-task. Unattended delegation does not. Every judgement you would have made by glancing at the screen has to be made in the brief, or it gets made by the model on your behalf.
Every mid-task judgement moves forward
When you watch an agent work, you intervene constantly without noticing it. It heads toward a file you know is deprecated and you redirect. It starts building an abstraction you do not want and you stop it. It asks a question and you answer in ten seconds. That supervision is so cheap you do not count it as work.
Remove it and those decisions do not vanish; they get made without you. The deprecated file gets modified. The abstraction gets built, thoroughly, and now there are eleven files depending on it. The question that would have taken ten seconds gets resolved by assumption, and the assumption propagates through four hours of subsequent work.
This is why the brief matters more than the model. The failure mode of an overnight run is rarely that the agent could not do the task. It is that it did a task, competently, that was slightly not the one you meant, and did it for four hours. Everything we said about what agent delegation actually requires applies with the correction loop removed, which means the up-front specification has to carry weight it never had to carry before.
The morning triage problem
The second place the difficulty lands is the morning. Overnight runs produce artefacts that need judging, and judging them is not free. A four-hour run can produce a large diff, and the reviewer has none of the context the agent accumulated. You are reading the conclusion of a process you did not observe.
One overnight PR is a pleasure. Five, every morning, is a queue, and it hits exactly the constraint we keep coming back to: the bottleneck is not producing work, it is a senior person responsibly saying yes to it. Firing off six overnight tasks because they are cheap to start is how you arrive at a morning where nothing can be merged because nobody has six hours of fresh attention. The review problem does not improve just because the work happened while you were asleep; it concentrates.
The practical rule we landed on is to cap unattended runs at what one person can genuinely review the next morning, which for us is two or three, not six. That feels like leaving capacity unused. It is not; it is refusing to build a backlog of unverified work, which is a worse asset than no work at all.
What makes a task suitable
Some work is well-shaped for this and some is not, and the difference is mostly about how checkable the result is.
Good candidates have a clear definition of done that a machine can evaluate: a failing test that should pass, a migration with a verifiable end state, a mechanical change across many files, a well-specified feature with a test suite around it. If the agent can tell whether it succeeded, it can iterate without you, and that is where the hours pay off.
Bad candidates are ones where correct is a matter of taste, where the requirements are genuinely unclear, or where the work touches something with irreversible consequences. An overnight run that resolves ambiguity by guessing produces four hours of confidently wrong work; an overnight run against production, per the write-access tiers, is a category error rather than a risk to manage.
The brief we write
Ours has settled into five parts, and it takes about ten minutes to write. The goal, stated as an outcome rather than a procedure. Done means: the specific, checkable condition, usually a command that must pass. Boundaries: what not to touch, which files are off limits, what is explicitly out of scope. Known traps: the deprecated module, the flaky test, the thing that looks wrong but is intentional. And on ambiguity: what to do when the spec runs out, which for us is nearly always to stop and write down the question rather than to guess.
That last one changed our outcomes more than anything else. An agent that stops at hour one with a clear question has cost you an hour. An agent that guesses at hour one and continues has cost you four hours plus the time to work out where it went off. Giving explicit permission to stop is not a limitation, it is the highest-value instruction in the brief.
What we got wrong first
We started with too many parallel runs, on the theory that they were cheap to launch. They were cheap to launch. The next morning was not, and we merged less that week than a normal one because everything was queued behind review.
We also under-specified boundaries at first, and got back changes that were technically correct and much larger than we wanted, because nothing in the brief said "only this." A model with time and no scope constraint will improve things you did not ask about, and every one of those improvements is a change somebody now has to read.
And we initially read overnight diffs the way we read a colleague's PR, which is to say assuming the author understood the system. That is the wrong posture: it is better to read them as the output of a capable stranger who has never seen this codebase before and had no one to ask.
The bottom line
Overnight agent work is real and worth doing. It is not free labour, though; it is a trade where you pay in advance with specification and afterwards with review, in exchange for the hours in between. Teams that get value from it write proper briefs, pick tasks with a checkable definition of done, tell the agent to stop rather than guess when the spec runs out, and cap the number of runs at what they can actually judge the next day. Teams that do not get value from it are usually not launching too few runs. They are launching too many, with too little said up front, and discovering both facts at nine in the morning.