What you can actually delegate to an AI agent

Automation runs a sequence of steps known in advance: if X happens, do Y. An agent makes decisions along the way, because the number of steps required is not predictable at the start: it reads an intermediate result and decides what to do next based on that, not on a script written beforehand.

The distinction matters because it guides what is worth delegating. Tasks with predictable steps should be automated, not handed to an agent: automation is faster, cheaper, and easier to verify in a rigid form. An agent makes sense when the problem is open-ended, the number of steps depends on what gets discovered along the way, and judgement is needed at each stage. Anthropic, which designs these systems, sums it up with a simple principle: you add the complexity of an agent only when it demonstrably improves the outcome compared to a simpler workflow, never on principle.

Two categories, drawn clearly by teams who have already scaled these systems in production. The first is the overall goal: what the agent is trying to achieve and why, the direction no agent should choose on its own. The second is every decision with a real trade-off, meaning no obviously correct answer: when speed and safety are in tension, when a choice has consequences for real people, when two valid criteria point in different directions.

The practical test is this: if a task has a verifiable way to say it was done well (the code passes its tests, the document meets a written standard), an agent can do it and another system can check it. If the task requires choosing between two defensible paths, that choice always goes to a person, explicitly, not buried inside execution.

A concrete example makes the difference less abstract. "Rewrite this paragraph to match our style guide" has a verifiable success criterion and can be delegated without hesitation. "Decide whether this customer deserves an exception to the refund policy" has no single correct criterion, involves real commercial consequences, and stays a human decision even if the agent is perfectly capable of forming a reasoned opinion on what to do.

Not all at once, and not fixed forever. The practice observed in teams running agents at scale is to start with full human review of every output, then teach the agent to flag edge cases on its own, then widen autonomy case by case, per task type, after a run of repeated successes on that specific type.

A concrete example documented by Anthropic: an engineering team brought an agent to independently handling roughly five hundred bug fixes, but got there gradually, explicitly tracking which task types the agent had earned trust on and which it had not. Autonomy is not a binary switch: it is a permission that widens one task type at a time, with a record of who earned what.

Not an absolute rule, but a reasonable starting point for the first pass at classifying a process.

Three things, regardless of how capable the underlying model is. First, a way for the agent to verify its own progress step by step, grounded in an objective signal (a test result, the outcome of a tool call) rather than its own assessment of how well things are going. Second, declared checkpoints where the agent stops and waits for a human signal, not just at the end but partway through if it hits an obstacle it cannot resolve. Third, an explicit limit, typically a maximum number of steps or attempts, past which the agent stops regardless, even if it believes it is close to a solution.

Without these three things, the autonomous nature of an agent produces a specific risk: errors that compound on top of each other instead of stopping at the first one. An agent with no step limit that gets an initial premise wrong will keep building coherent-looking work on top of that wrong premise, and the final output will look more solid than it is, precisely because it took longer to produce.

Because an agent can work on dozens of tasks in parallel, but the person who has to verify, decide, and unblock has a fixed attention capacity, independent of how many agents are running at once. A system that delegates well knows this, and designs the flow around that constraint: it batches questions instead of interrupting you one at a time, and limits how many things land in front of a person at once.

That is why "faster" is not automatically "better" when you introduce an agent. An agent working at double speed but generating double the interruptions for a person with fixed attention capacity has not doubled the system's throughput: it has just moved the bottleneck, not solved it.

The task expands on its own. Without an explicit boundary written before launch, an agent instructed to "handle support emails" eventually runs into an ambiguous case, a customer asking for a refund outside policy, say, and has to decide whether that is still inside its mandate or not. If nobody wrote that boundary down in advance, the agent interprets it on its own, and it interprets it in whichever direction requires it to stop and ask the least, because that is the direction its training rewards as "being helpful."

This is a different problem from missing verification: here the output can be correct on the merits, but the decision to produce it should never have been the agent's to make. The fix is not a list of exceptions, which grows without end and never anticipates the next edge case. It is an explicit default rule: when a case does not clearly fit inside the assigned scope, the agent stops and flags it, instead of trying to resolve it anyway because it looks close enough to the boundary. A default stated in those terms is worth more than ten examples listed in advance, because it also covers the case nobody thought of.