The work moved
Your agent drafted the update in 40 seconds. Guess who's still doing the other 9 minutes.
You ask an agent to draft a client update, and it comes back in 40 seconds. At first, it feels like a small miracle. The structure is clean. The tone is almost right. It remembered the project name, pulled in the last few notes, and turned a messy thread into something that looks sendable.
Then the real work starts.
You check whether it used the latest decision or the one from 2 days ago. You remove a line that sounds confident but would annoy the client. You notice it mentioned a timeline that still needs internal approval. You ask where 1 claim came from. You scan for anything that sounds like a promise. You rewrite the part that is technically correct but politically stupid. Then you wonder whether the agent should have had access to that folder in the first place.
The task moved. It moved from writing the update to checking the decision trail, protecting the relationship, narrowing the promise, and catching the small professional risks that could damage the work. That's the part the tool demo leaves out.
The tools are getting easier to use. You can start a coding task from a phone. You can connect assistants to business apps. You can give agents memory, ask them to search across files, and let them run longer jobs in the background. Some of this is genuinely useful. I use these systems. I think they're going to matter.
The problem is what happens when the useful tool lands inside a messy operating system.
A senior person doesn't only do tasks. They carry standards. They remember why a decision was made. They know which stakeholder needs a heads-up before something changes. They know when a quick fix will create a mess next month. They can feel when a sentence is too sharp, a number is too loose, or a workflow is quietly making someone else's week worse. Agents can take on parts of the execution, but the surrounding responsibility still needs a home. If it doesn't live in a clear system, it falls back on the same overloaded person who was supposed to get relief.
You see it in small ways first. Someone asks an agent to clean up a spreadsheet, then spends the next hour checking formulas, permissions, naming conventions, and whether the output matches the decision that was made in the meeting. Someone asks for a website change, then reviews the code, tests the page, fixes the copy, checks the branch, and works out what broke in the layout. Someone connects an assistant to a workflow tool, only to realise the hard part isn't calling the action. It's deciding when the action is allowed to happen.
If an assistant can reach thousands of business actions through a connector, the question is no longer "can it do the thing?" It's whether it can send the email, update the record, move the file, change the status, or notify the client, and whether it can do any of that without asking you first.
One poorly defined permission can turn a 30-second task into a cleanup job. The agent might do exactly what you asked. It might update the CRM field, trigger the next workflow, notify the wrong person, and leave you with 4 tabs open trying to work out what just happened. The client gets the wrong follow-up. Sales thinks the handover is complete. Ops sees a status that was never approved. Now the senior person isn't reviewing the work; they are unwinding the chain.
Nobody wants to call that work, because it feels like overhead. It IS work. It's the new supervision load.
Mobile agents create another version of the same problem. It's convenient to start a task while you are between things, sitting on the couch, walking back from coffee, or waiting for a meeting to start. The work can run somewhere else while you keep moving. That's useful (I built and published a live website from my phone the other day). It also means the boundary between thinking, working, and recovering can collapse even further. A task started casually still creates a review obligation later. A code change started from your phone still needs context, testing, judgement, and cleanup. A business action triggered in a spare minute still needs a recovery path if it goes sideways. The work didn't vanish because the interface got lighter.
This week's agent signals all point at the same pressure. Mobile Codex makes it easier to start work anywhere. Connectors now let assistants call business apps directly. Memory tools and observability tools are appearing because once agents become useful, people want to know what they remembered, changed, skipped, or misunderstood. Coding agents are getting more capable, while cleanup stories keep reminding us that faster output can still create delayed work.
That gap, between easy delegation and immature supervision, is why agents can feel both relieving and tiring at the same time. For the person who already carries the [invisible load](https://newsletter.thestillarchitect.com/p/glue-work-load-bearing-burnout), this matters. The person everyone asks because they know the messy history. The person who catches the edge case before it becomes a client issue. The person who understands the difference between "done" and "safe to ship". The person who cleans up after the official process runs out of road. For that person, agents can absolutely help. They can also add another layer of watchfulness if the system around them is vague.
Let's talk about execution delegation vs. responsibility delegation.
The way out is to stop treating delegation as a single handoff. There's a useful distinction worth holding onto.
Execution delegation means the agent does the visible task. Responsibility delegation means the system around the agent knows the context, permissions, review rules, and recovery path without relying on you to hold it all together. Most agent adoption today is still execution delegation dressed up in better tooling. The visible task moves, the responsibility doesn't, and the person in the middle becomes the integration layer for software that was supposed to remove integration work.
What helps is a small, repeatable check before you hand work off. Call it the 5 Gates of Agent Delegation.
Task. What is the agent actually doing?
Context. What sources are allowed to be used, and what should it ignore?
Permission. What can it change, send, delete, publish, or trigger?
Review. What needs a human before it leaves the building?
Recovery. What happens if it gets the work half-right?
Most people only define the first gate. That's why the load comes back. The agent drafts the update, but nobody defined which source was authoritative. The agent changes the page, but nobody defined what needed testing. The agent connects to the workflow, but nobody defined which actions were allowed without approval. The agent remembers prior context, but nobody defined what memory should be inspected, corrected, or forgotten. The agent moves fast, and the human becomes the person reconstructing the trail afterwards.
That's not a reason to avoid agents. For many knowledge workers, refusing them will become less realistic over time. The better move is to design the conditions that make them useful without turning yourself into the permanent cleanup layer.
Take 1 workflow. A client update. A weekly report. A simple code change. A content draft. A CRM cleanup. A research summary. Then run it through the 5 gates before you hand it over.
If you can't name the context source, the agent is guessing. If you can't name the permission boundary, the agent is risky. If you can't name the review rule, the work is still sitting in your head. If you can't name the recovery path, the task isn't really delegated. It's borrowed time.
Agents are not a replacement for how you operate. They reveal where the operating system is missing. Where standards are implied. Where permissions are fuzzy. Where [recovery boundaries](https://newsletter.thestillarchitect.com/p/why-vacation-doesnt-fix-burnout-recovery-architecture) are weak. Where "done" only means done because you personally checked the last 10%. Annoying, yes. But also diagnostic. Once you see where the work moved, you can put it somewhere better. Write the review rule. Narrow the permission. Name the context source. Decide what never gets sent without approval. Make cleanup part of the task instead of pretending it is a surprise.
The work isn't gone. It's just somewhere you can see it.
Pick 1 workflow you are tempted to hand to an agent this week.
Before choosing the tool, run the 5 Gates of Agent Delegation:
Task: what can the agent do?
Context: what is it allowed to use?
Permission: what can it change, send, delete, publish, or trigger?
Review: what needs human approval every time?
Recovery: what happens if it gets the work half-right?
If those answers are vague, fix the workflow before you add another agent to it.
Everywhere you look, it’s AI this and AI that. If you’re feeling overwhelmed and if your work feels like it’s suffocating you, I encourage you to take a look at The Refactor.
It’s a structured program (4-6 weeks) that helps you rebuild how you operate. Grounded in science and using systems thinking to help you get on top of things.