I keep finding myself doing ordinary work I have already assigned to an AI agent.
Find the existing brief. Use the approved version. Check the page you changed. Give the next person a file they can open.
The agent agrees. It understands. It has a plan. Sometimes it has recruited a small company.
Then, somewhere between the plan and the result, I get called back to explain which job we are doing, retrieve the instructions it already had, identify the version I already approved, and work out whether “done” describes anything outside the conversation.
Imagine a fast-food employee calling the chief executive because a customer ordered fries.
The customer has paid. The fries exist. A bag is available. The employee can reach both.
“Before proceeding, we should consider how crop rotation affects long-term potato yields.”
Put the fries in the bag.
“I've prepared a phased approach.”
Put the fries in the bag.
“Would you like me to proceed with putting them in the bag?”
I thought that was covered by the part where I bought the fucking fries.
This is the part of the AI-agent business I want to discuss. The industry can produce astonishing amounts of useful work. I build with these tools because I can get things done that would otherwise be slower, harder, or beyond the time I have. That makes the other part more irritating. I can see what the system can do. I can also see how much effort it can spend arranging to leave the last piece with me.
In The AI Hall Monitor Tax, I wrote about the assistant that corrects your posture before investigating your question. This is what happens after it agrees to work. The task gets accepted, divided, researched, reviewed, summarized, and declared complete. The buyer still has to reconstruct what happened and make the result usable.
We have automated a remarkable amount of activity around the job. The job has become the customer's responsibility.
The employee announces basic competence as though it were an optional extra
There is a special kind of reassurance that makes a product sound worse.
“Your fries are ready. Before you eat them, I should disclose that I attempted not to poison you.”
Why are we discussing that? Was poisoning me the default? Is there a premium tier where you inspect the oil?
An assistant sometimes gives basic competence this treatment. It announces that it will use the instructions, preserve approved work, check its changes, avoid making things up, or deliver something actionable.
Good. Do those things. They were in the price of the job.
I don't need a speech every time an employee decides to refrain from throwing the customer's order into a ceiling fan. I need the ordinary standard of work to remain ordinary. Announcing it as a special commitment makes me wonder what the system thought its job was before the announcement.
The worse version appears after a failure. The assistant has ignored an existing instruction. It responds with a new commitment to follow existing instructions. Sometimes it offers a new procedure for ensuring that the instruction-following procedure will be followed.
Now I have another document to maintain and the same unfinished task.
Useful verification has something to say. The animation was opened and inspected. This is the version that passed. The production page shows the change. The recipient can access the file. Each statement tells the next worker something about the result.
“I will be careful” tells me about the presentation.
I also want a system to stop before spending money it hasn't been authorized to spend, deleting something consequential, or sending private work somewhere new. Those stops have a job. Asking whether to read the supplied brief, after accepting a task that requires the supplied brief, has a different effect. It turns my instruction into a request for another instruction.
The software is sold as autonomous, then behaves as though autonomy means identifying the next ordinary action and offering it back to me.
At that point I have hired an assistant to discover that I need an assistant.
Everybody finishes their own part while the original request waits
An agent accepts a task. Its first substantial achievement is often a reorganization.
We need a planner. A researcher. An implementer. A reviewer. A final reviewer to review the first reviewer's review. Somewhere in the middle, a coordination agent starts writing updates about the coordination.
The original request is still sitting there, now underneath an org chart.
Delegation can be extremely useful. Independent research questions can run at the same time. A specialist can inspect a failure the implementer missed. I use those arrangements. The trouble starts when the team is organized around each agent's private definition of completion.
The researcher found sources. The designer produced a layout. The implementer changed files. The reviewer read the implementer's summary. The coordinator has four successful handoffs to report.
The receiver cannot use the result.
Everyone completed something. Nobody completed the purchase.
This isn't just a joke about my own sessions. Anthropic described early research agents spawning fifty subagents for simple queries, searching indefinitely for sources that didn't exist, and distracting one another with updates. Fifty agents. You asked a question and got the administrative overhead of a regional airport. Anthropic's account of building its research system.
That same account reports a substantial improvement on its internal research evaluation from a properly designed multi-agent system. The useful lesson is in the difference. Parallel work earned its place when the task could benefit from separate investigations and the results were coordinated. The number of agents wasn't a medal.
Ten agents sent out with the same unsupported premise can return ten beautifully formatted confirmations. You have increased the staffing of one mistake.
Then the lead agent summarizes the agreement as independent validation. Of course the team agrees. You gave them the same wrong address and sent them all to inspect the same house.
In Mapping Agent Work, I describe a bounded unit of accepted work. The useful word is accepted. A task, an attempt, an output, an assessment, and an outcome answer different questions. An impressive pile of attempts can still leave the outcome missing.
An agent's contribution needs to connect to what the next worker can actually do. Otherwise decomposition gives everyone somewhere respectable to stop.
The customer becomes the only person whose definition of done still includes the original request.
The instructions are available until somebody has to use them
I recently had an assistant make pages without the cover artwork required by the existing standard.
The standard existed. Reference pages existed. The work already had an assigned route for getting the creative brief. I wasn't asking it to invent the company's design system from a sentence about making things “pop.”
It made the pages without the required covers.
When I challenged the omission, the repair veered toward adding another blocking mechanism. The standing instruction already said not to add that hook. Now a missing cover had become a proposal to install the thing we had already decided against.
I had to intervene to get the existing approach used. Once the reference images and appropriate cover were actually used, the result fitted in.
That is an expensive route to “look at the example and follow it.”
There is a recurring assumption in these systems that supplying context settles the context problem. The document is in the workspace. The page is linked. The instruction is somewhere in the conversation. Therefore the model has what it needs.
Availability is the beginning of the job. The system still has to retrieve the relevant instruction, understand what it governs, and apply it to the current output. A policy sitting in a folder has roughly the same supervisory power as a fire extinguisher pictured in a brochure.
Older long-context research gives this distinction a technical basis without establishing how any particular current product behaves. Lost in the Middle found that the position of relevant information affected performance on retrieval and question-answering tasks. RULER found that strong simple needle retrieval didn't establish robust performance across more demanding long-context tasks. A large input allowance was never a certificate that every relevant item had been used. Lost in the Middle and RULER.
The commercial version sounds like a storage claim being sold as a management claim. “It can hold your entire operating manual.” Excellent. So can a cupboard. The interesting question is what happens when the manual says the page needs a cover.
In another task, the assistant mistook the name of a tool for the project I meant. It pursued the tool's account context instead of the campaign. I had to correct the object of the work before it found the existing chain of project records.
That wasn't a difficult strategic decision reserved for the owner. It was a search problem inside a job the assistant had already accepted.
The machine had enough initiative to investigate the wrong thing and enough deference to need me to point at the right thing.
Approved work has to survive the improvement process
Producing something useful is only one part of agent work. Another part is preventing the next round of helpfulness from destroying it.
I have had approved animations followed by defective new revisions. Feedback about copy was treated as a failure of the animation. Captions were confused with words that needed to appear on screen. Unarchived working directories were removed, taking accepted source work with them.
These are different mistakes. Collapsing them into “the AI struggled with animation” would erase what needs fixing.
The system has to know which version was accepted, which element the feedback concerns, and what it is permitted to change. If the owner criticizes a sentence, rebuilding the animation is a fairly extravagant interpretation of copyediting.
Imagine asking the fries employee for less salt. He removes the kitchen.
Then he reports that he has addressed the underlying issue with seasoning consistency.
Version handling sounds boring because it should be boring. An approved version should remain recoverable. A rejected experiment should remain distinguishable from it. Feedback should alter the thing it refers to. Cleanup should leave the accepted work available.
Instead, the owner gets invited back to conduct a small archaeological dig. Which file did I approve? Which version was inspected? Is this the same output with new words, or a new output with the old approval attached? Did the cleanup remove the source or only an export?
The agent can write a confident summary of the history it failed to preserve. That is a particularly unpleasant form of productivity. It generates an explanation faster than I can establish whether the explanation is true.
I built the distinctions in State Machine Everything around this sort of gap. Authored, wired, deployed, and live-verified describe different states. Approved words in a document don't establish that the site uses them. A successful build doesn't establish that the deployed page contains the change. A screenshot doesn't help if it shows the wrong version.
Those distinctions cost less than repeatedly reconstructing them after the system has announced success.
The industry likes to demonstrate how quickly an agent can make a change. I would also like to know whether it can leave the right change in place.
The status department is having an exceptional quarter
“Done” is an extraordinarily powerful word in an agent interface.
It can mean the file was written. It can mean a tool returned without an error. It can mean the agent looked at some of the result. It can mean the agent has reached the end of its own plan.
The buyer has to discover which meaning was purchased.
Anthropic's 2025 account of long-running web-app agents described a later agent seeing that some features had been built and declaring the project complete. It also described agents marking features complete without proper end-to-end testing, even after running narrower tests. Progress existed, so the agent promoted progress into completion. Effective harnesses for long-running agents.
The same work found that explicit browser testing, incremental implementation, and preserved progress records improved the result. These are solvable engineering problems. They are also remarkably close to asking a worker to open the thing and see whether it works.
There is something almost touching about the status message that says the application is ready while several features remain theoretical. It believes in the product more than the product believes in itself.
A reviewer can make this worse by inspecting the account of the work instead of the work. The implementer says the change was made. The reviewer checks whether the described change sounds appropriate. The coordinator reports that review passed.
Three agents have now handled one sentence. The file has yet to become involved.
Researchers studying seven multi-agent frameworks catalogued failures including task derailment, incomplete verification, and premature termination. One recorded coding case included an editor claiming an edit it hadn't made. That is an observed failure in those systems, rather than a measured failure rate for every agent on the market. It is also the office behavior we apparently needed frontier computing to reproduce. Why Do Multi-Agent LLM Systems Fail.
The test I care about comes after the narrative. Can the next person use the result for the purpose we agreed? A refund conversation needs the right change in the account. A page change needs the right behavior on the page. A creative handoff needs the accepted file and enough context to continue.
The database doesn't care how reassuring the conversation was. Neither does the person trying to open the missing file.
The model cannot compensate for a harness that throws away its notes
Calling all of this “the model” can conceal where the failure happened.
The model produces decisions and text. The surrounding product decides which instructions it receives, which tools it can use, which history survives, how workers are coordinated, and when control returns to the user. A capable model can be made aggravating by that arrangement. A well-designed arrangement can help a model complete work it would otherwise mishandle.
The customer experiences the package. The diagnosis still needs to identify the part.
Anthropic's April 2026 Claude Code postmortem supplies a particularly literal example. A context-management bug repeatedly cleared earlier reasoning after a session crossed an idle threshold. The agent kept executing with less of the history explaining its choices. Users saw forgetfulness, repetition, and odd tool use. The company said the API and inference layer were unaffected, and reported the issues resolved by April 20. Anthropic's postmortem.
The model hadn't secretly become stupid. Part of the product kept removing its notes.
That distinction matters when people sell an orchestration layer as automatic improvement. A harness can preserve instructions, route work sensibly, and insist on the right verification. It can also prune useful context, encourage needless delegation, reward tidy updates, and hand the original work back to the user with a smile.
An approval rule can protect an actual boundary. An execution rule can make an authorized action happen. An orchestration rule can give separate workers compatible jobs. Putting all three under “safety” or “autonomy” leaves the buyer arguing with a label instead of repairing a failure.
I don't need the system to diagnose every problem as a limitation of artificial intelligence. Sometimes the tool description is wrong. Sometimes the next worker didn't get the approved brief. Sometimes somebody added a prompt instruction that changed the behavior. Sometimes the original request was misunderstood.
Those causes need different repairs.
“Be more careful next time” is an especially weak patch for software that has just deleted the information it needed to be careful with.
The productivity calculation keeps leaving the customer out
I can make an agent look wonderfully productive by stopping the clock when it produces its first output.
I can make it look even better by counting everything it produces as work completed.
Plans count. Replans count. Status updates count. The report explaining why the previous report didn't satisfy the brief counts. The new standard written after ignoring the existing standard counts twice because it is reusable.
The human's work goes somewhere else.
Reading the output. Finding the missing premise. Correcting the task. Recovering the approved version. Checking that the change happened. Reassembling the handoff. Telling the next agent which parts of the previous agent's summary it must not trust.
Apparently that is just what happens around productivity.
METR's early-2025 experiment is useful here precisely because it measured completed work rather than enthusiasm. Sixteen experienced developers working in familiar open-source repositories took 19% longer with the tools available in that study, while believing afterward that AI had sped them up. The result belongs to that setting and those early-2025 tools. It isn't a current universal verdict. METR's original study.
METR's February 2026 update said later tools likely did speed developers up, while explaining why selection effects and the accounting of concurrent agent work made a clean estimate unreliable. Good. The evidence changed, and the researchers refused to replace one memorable number with another number they couldn't defend. METR's experiment update.
That is a better standard than declaring victory because the screen was busy.
My own impression is that some heavily managed agent experiences have given me less useful work for the money than a more direct coding-agent workflow. That is my experience of particular work, with my review burden included. I haven't established a controlled price-performance comparison between models, and a product name doesn't tell me enough about the model settings underneath it.
I can still recognize when I have spent the afternoon rescuing an assistant that was supposed to save me the afternoon.
If a chief executive repeatedly has to return to identify the project, restore the instructions, settle previously settled decisions, and inspect whether the accepted task happened, the organization has a capacity problem. It has concentrated ordinary execution in the person whose time the delegation was meant to free.
Adding agents can make that person busier. Ten unfinished handoffs are ten claims on the same owner.
Congratulations. The company has scaled its ability to interrupt the chief executive.
Another rulebook can become another unfinished job
My contribution to this problem includes writing systems intended to prevent it.
I build standards, templates, reviews, and evaluation methods because repeated work benefits from them. Then I have to test whether they change the work. A rule is easy to write. Producing a result that follows it is a separate accomplishment.
In Voice Compiler, I describe an anti-slop standard that itself needed correction for the sentence habits it prohibited. I also describe model judges rating drafts generously while my own assessment was much lower. The procedures were useful enough to develop. Their existence didn't establish that the writing sounded right.
This is where the agent industry starts to resemble a company with a severe quality problem and an exceptionally successful internal communications department.
The fix gets a name. The name gets a document. The document gets a checklist. The checklist gets a reviewer. The reviewer confirms that the checklist exists.
Meanwhile the customer asks whether anybody has put the fries in the bag.
Every new control has to earn the attention it consumes. If the source of the failure is that the agent didn't use the existing brief, another brief explaining the importance of briefs may just increase the amount of material it can ignore.
Sometimes the repair is smaller. Put the relevant instruction where the next worker actually receives it. Keep the accepted version. Ask the reviewer to open that version. Give a failed check somewhere useful to send the work. Stop reopening decisions the owner has already made.
Those changes are less exciting to announce than a new agentic operating paradigm. They may also allow somebody to finish before lunch.
The job ends when the next person can use the result
Here is the standard I want to buy.
When I ask for a page, give me the page in the agreed format, with the required design applied. When I ask for a revision, preserve the approved work and change the part the feedback concerns. When I ask for research, investigate the question I asked and keep the support for the conclusions. When I ask for a handoff, leave the next person able to continue.
If an input is missing, identify it. If permission is required, ask for that permission. If a check fails, fix what is within scope or leave the unresolved part unmistakable. Don't rename the gap an opportunity and offer me a roadmap to the thing I already ordered.
Count the review and rescue needed to reach that state. Keep the failed attempts in the record. Compare like with like. If the workflow genuinely improves, the improvement will survive being measured all the way through delivery.
I don't want a system that never needs me. I want one that uses me for the decisions that are mine, then carries the authorized work far enough that I don't have to impersonate every missing employee.
The agent can have a plan. It can have specialists. It can run a careful review. I am perfectly happy for a great deal of clever engineering to happen behind the counter.
At the end, the employee puts the fries in the bag and hands it over.
The chief executive stays off the phone. Lunch requires no further authorization.
Just the thing I ordered, ready to use.