What You Can't Delegate to AI Agents

The dangerous version of AI delegation is not an agent doing too much work.

It's you. Quietly giving away the part that was never meant for agents in the first place: deciding what matters, what is safe enough, and who owns the result when something goes wrong.

That's the shift I keep coming back to as we wire agents into real company workflows. The work doesn't vanish. It concentrates. When an agent can research, plan, draft, build, test, summarize, and hand work forward, our job moves to fewer, higher-stakes decisions.

The tempting conclusion is that autonomy itself is the goal. I think the better target is governed autonomy.

That distinction matters because agentic systems are not simply chatbots with better branding. The term describes how systems pursue complex goals in complex environments with limited direct supervision (OpenAI paper).

So the real question you should be asking is: “Should this agent be allowed to do this, with what permissions, and what do I need to see to confirm the outcome was correct?”

The leverage is real.

If you're building with agents, you will feel very empowered.

The first time an agent completes a task that used to take a person hours, you feel the leverage. Then you start to wonder what else it can do. If the agent can produce the plan, write the code, generate the test notes, draft the email, and summarize the tradeoffs, where do you still need to insert yourself to verify the output?

The honest answer is that you shouldn't stay in every loop.

Continuous human oversight over every agent workflow becomes impractical at scale. You need to ensure meaningful accountability at significant checkpoints for high-stakes or irreversible actions.

That's more useful than “human in the loop” as a slogan.

You don't need to approve every tiny step. You need to own the few points where a wrong step becomes expensive, public, irreversible, legally sensitive, financially meaningful, or hard to unwind.

In our own agent-assisted work, the surprising lesson was that faster execution makes those points more important, not less. Loose requirements used to create slow confusion. With agents, loose requirements can become fast wrong work.

From our own experience, we learned that the hard way. A high-speed, low-process approach can feel efficient. When everyone has access to agents, a loose requirements discussion can turn into implementation almost immediately. But different people (and now agents!) can walk out of the same conversation carrying different versions of the goal and the acceptance bar.

The fix? Shift your thinking from feasibility to readiness: is this the right plan to make executable?

Your role shifts from pressing every key on a keyboard to deciding what should become executable.

Fast wrong work is the new bottleneck.

A slow team can hide a vague plan inside the cost of implementation. The work takes long enough that people keep talking, clarifying, and correcting course while the thing is being built.

Agents remove some of that drag. That's the good part.

They also remove some of the accidental safety that drag created.

If an agent can turn a loose prompt into a plan, a branch, a draft, a pull request, a QA pass, and a release note, the expensive mistake moves upstream. Bad code or bad copy is only one possible outcome. The deeper mistake is approving the wrong objective with weak acceptance criteria, then letting a machine execute it very efficiently.

Be careful not to ask for the wrong thing.

Execution can be delegated. Ownership cannot.

There are plenty of tasks you could stop doing by hand.

Let agents turn rough notes into a first pass. Let them inspect a codebase before writing an implementation plan. Let them run repeatable checks. Let them prepare review artifacts. Let them draft the boring internal summary you always postpone. Let them do the work that becomes more valuable when it's fast, cheap, and repeatable.

But don't confuse delegation with a transfer of ownership.

Your non-delegables are the moments that require a judgment call, not merely the performance of a task.

You still own intent: what outcome is worth pursuing.

You still own risk appetite: what the company may expose, change, promise, spend, ship, or automate.

You still own the definition of done and safe: what evidence is enough for this class of work, and what evidence is not enough.

You still own escalation: when the agent should stop, ask, hand off, or be overridden.

You still own final accountability: what happens if the decision was wrong.

An agent can prepare an answer for each of those. It should. But if you delegate the judgment itself, the company gets faster without getting wiser.

Delegation without judgment turns leverage into abdication with better tooling.

The gate has to be rare enough to matter.

You need to be careful, though: human-in-the-loop approval gates can become the slowest and least honest part of an agent workflow.

If every reversible, low-risk action waits for approval, the agent's work queues up.

If the approval prompt lacks context, evidence, uncertainty, risk, and a real reject path, the workflow launders the system's uncertainty with a click.

If the team treats the existence of a gate as proof of control, the process becomes theater.

Human-in-the-loop AI agents need more than an approval prompt. A weak approval gate can create false confidence.

The answer is not more approvals.

The answer is sharper approvals.

A good gate changes the outcome.

It lets a human approve, edit, reject, ask for more evidence, change the risk tier, narrow the permissions, or escalate to another person. When the only realistic option is “approve because the workflow is waiting,” the prompt becomes a loading screen with liability attached.

What “done and safe” means is your decision.

One of the most useful questions you can ask before delegating work to an agent is: “What artifact would make me comfortable accepting this?”

For a small visual change, that artifact might be a rendered preview, a before-and-after screenshot, a short recording of the built change, and the checks that confirm the app still builds.

That example comes from our own review flow. For smaller visual work, attaching a recording to the work item can give a reviewer enough context to see that the feature exists and behaves as expected, without forcing them to reconstruct the whole change every time. The same artifact would be wildly insufficient for a migration, a security-sensitive change, or anything involving private or sensitive data.

The review artifact has to fit the risk of the decision.

For a data migration, a visual preview is nowhere near enough.

For a customer-facing email, the evidence is different again: final copy, recipient logic, opt-out handling, legal or compliance review if needed, and explicit human approval before anything is sent.

For a security-sensitive workflow, the concern is tool access and data boundaries: which tools the agent can call, what data it can reach, what it can send outside the company, and who signed off on those limits.

The evidence has to match the risk.

A demo doesn't replace tests. A screenshot doesn't replace security review. A green build doesn't prove the product decision was right. A reviewer note doesn't prove privacy risk was handled. A human approval doesn't magically turn weak evidence into strong evidence.

Define the evidence standard before agents start executing, and bake it into the plan and the initial requirements, rather than negotiating it after the agent says it's done.

Put the work in three buckets.

I would map agent work into three buckets.

1. Delegate repeatable execution

Delegate work where the desired output can be checked against a clear standard.

Examples include first drafts, codebase inspection, implementation plans, test scaffolds, QA checklists, summarization, formatting, research collection, routine refactors, and repetitive internal updates.

The agent should produce something reviewable, and a failure should be reversible or caught before it creates an external consequence.

2. Automate evidence collection

Don't inspect everything from scratch yourself. Ask the system to gather the evidence you need.

That can include test results, changed files, screenshots, rendered previews, logs, risk notes, unanswered questions, rollback options, and a plain-English explanation of what changed.

The system should collect evidence.

You should judge it.

3. Keep irreversible or reputation-bearing gates human-owned

Pause before actions that are hard to unwind or expensive to explain.

That includes production releases above a defined risk tier, migrations, destructive operations, private or sensitive data access, financial commitments, legal or compliance-sensitive steps, external messages, public claims, subscriber or list actions, security-sensitive tool use, and anything where the system reports low confidence or ambiguous context.

Your version should be boringly explicit:

1. What can the agent do without asking?
2. What must it ask before doing?
3. What evidence must it attach?
4. Who can approve, edit, reject, or escalate?
5. What happens if the evidence is missing?
6. What happens after release if the decision was wrong?

If those answers are vague, autonomy will find the gap.

Your job gets smaller and heavier.

After agents, your job gets smaller and heavier: fewer decisions, more weight behind each one.

You get this right by moving your judgment to the places where it changes the work: intent, plan approval, risk boundaries, evidence standards, escalation, and final release decisions.

That's the version of autonomy worth building toward: agents that can run farther because you have made it clear where they must stop and check in.

So before you add another agent to a workflow, do one less glamorous thing first.

Draw the boundary.

Write down the tasks the agent may execute, the evidence it must bring back, the actions it may never take without approval, and the human who owns the outcome.

Then turn the document into a workflow change. Pick an agent workflow you already run and add a pause before its highest-risk action.

The success signal is concrete: the next high-risk action arrives as a paused request with the evidence attached, instead of a notification that it already ran.

That is not less control.

That is control finally becoming explicit.