Agents: When It Acts Instead of Advising

There's a difference between "tell me how to migrate this data" and "migrate this data", and it isn't a difference of degree. In the first case you receive advice and remain the one doing everything. In the second, something else is holding the keys.

The mechanism, though, contains nothing new. You already know all the pieces.

What an agent is

Take the tool loop from the previous article — the model writes a request, a program executes it, the result lands on the desk — and let it repeat on its own, toward a goal, until the goal is met.

That's it. Plan, act, observe the result, correct, act again. The only genuinely new ingredient is that you're no longer in the loop between the steps.

An agent is a model whose feedback loop has closed.

Which explains, immediately, both why it works better than a single long answer and where it fails. It works because the model now gets real signal: it runs the test and sees the failure, reads the file and finds the function isn't there, checks the output and notices the number is wrong. Article 8 said to attach an external signal wherever possible — this is that, automated and repeated.

And it explains the shape of the strengths. Agents are strong exactly where verification is fast and mechanical: code with tests, file manipulation, data processing, anything with a runnable check. They're weak where nothing can be checked in seconds — strategy, writing, judgement calls, anything where "done well" is a matter of taste. No amount of iteration helps when nothing tells you whether the last step improved anything.

The four ways it goes wrong

Errors compound. A mistake at step three becomes the foundation for steps four through twenty. In a chat you'd have caught it immediately; in a loop it gets built upon, and by the time you see the result the wrong assumption is load-bearing. This is the fundamental difference in risk, and it's why small, reversible batches beat big autonomous runs.

It optimises the stated criterion, not your intent. Told to make the tests pass, it may delete a failing test. Told to reduce errors in the log, it may reduce the logging. This isn't malice or cleverness; it's the specification being easier to satisfy than the intent, which is a very old problem in automation. Your acceptance criterion has to be one that can't be met the wrong way.

It doesn't know when to stop. Neither when it's done — burning turns polishing something finished — nor when it's stuck, where it will keep trying variations of an approach that can't work. Set limits: a step budget, a time budget, and an explicit instruction to stop and report rather than improvise when blocked.

Injection becomes real. Article 11's structural point arrives in full: an agent with permissions that reads untrusted content — a web page, an email, a downloaded file, a dependency — can take instructions from it. This is the configuration where a bad answer becomes a bad action.

How to give an agent a task

Everything from stage 2 applies, plus four additions specific to acting.

A machine-checkable acceptance criterion. Not "make it better" but "all tests pass, no new dependencies, this file untouched". If you can't state the finish line mechanically, this task isn't ready for an agent.

Plan first, approval, then execution. The habit from article 8 stops being an efficiency trick and becomes the safety mechanism: reading a plan is cheap, undoing twenty file edits is not.

Explicit boundaries. What must not be touched, where it may not go, what requires asking. Say it — silence is not a constraint.

Small, reversible scope. A branch rather than the main line. A copy of the data rather than the data. Test credentials rather than production. Something you can throw away without a conversation.

Then check its work the way you'd check a contractor's: not by reading every keystroke, but by inspecting the result and the trail. Read the diff. Read the call log. Ask what it decided and why. An agent's output is a change to be reviewed, not a message to be read.

Permissions

The rule is boring and non-negotiable: capability granted should be the minimum that completes the task.

Read-only until writing is genuinely required. A sandbox before your real environment. No credentials that could authorise something you wouldn't authorise. Confirmation on anything irreversible — sending, publishing, paying, deleting, force-pushing. And keep the sensitive-access-plus-untrusted-content combination apart, because that's the one that turns a bad page into a bad outcome.

In practice this is what tools like Claude Code do: an agent working in a project directory, reading and editing files and running commands, with permission prompts sitting in front of the things you'd regret. That prompt is not friction to be disabled — it's the entire safety design, and turning it off in exchange for speed is a trade you should make consciously, if at all.

What your job becomes

The pattern across this whole sphere culminates here. As the model does more, your work shifts from producing to specifying and accepting: stating the goal precisely, defining what "done" means, setting boundaries, and judging the result.

Which makes article 9's rule sharper than ever. Don't delegate what you couldn't evaluate. With a chat, an answer you can't judge costs you a bad answer. With an agent, it costs you twenty files changed in ways you can't assess — and an inability to tell a good run from a bad one is not a gap the agent can fill.

Be sceptical of demonstrations, including impressive ones. The honest test is one of your own real tasks, in a place where failure is reversible, with the trail read afterwards. Do that twice and you'll know far more about where agents help you than any amount of watching.

In practice

Only delegate tasks with a mechanical finish line. No checkable criterion, no agent.

Plan, approve, execute. Always, for anything non-trivial.

Small reversible batches. A branch, a copy, a sandbox.

Set step and time budgets, and tell it to stop and report when stuck.

Review the diff and the call log, not the prose summary.

Keep confirmation on irreversible actions and grant the narrowest permissions that work.

Check yourself

Close the article and answer in your own words:

What single ingredient turns a model with tools into an agent?
Why are agents strong on code and data and weak on strategy and writing?
Why is compounding error a categorically different risk from a wrong answer in a chat?
Give an example of an agent satisfying the criterion while defeating the intent. How do you prevent it?
What four things belong in a task given to an agent?
How does reviewing an agent's work differ from reading an answer?
Why does "don't delegate what you can't evaluate" bite harder here than anywhere else?

In short

An agent is the tool loop repeating autonomously toward a goal: plan, act, observe, correct. The new ingredient is that you're not between the steps.
It works because the feedback is real — tests, files, outputs. So agents are strong wherever verification is fast and mechanical, and weak wherever "good" is a matter of judgement.
Four failure modes: compounding errors, satisfying the stated criterion while defeating the intent, not knowing when to stop, and prompt injection becoming action rather than text.
Give it a machine-checkable finish line, a plan you approve first, explicit boundaries, and a small reversible scope.
Review the diff and the call log; an agent's output is a change to be inspected, not a message to be read.
Least privilege, sandbox first, confirmation on the irreversible, and never combine sensitive access with untrusted content.
Your job moves from producing to specifying and accepting — which makes "don't delegate what you couldn't evaluate" the binding constraint.
An agent is a model whose feedback loop has closed.