We do not ask agents to own business judgment.
We do not ask agents to decide what should exist, which tradeoff matters most, or whether a feature is wrong for the user.
Agents can generate enormous leverage. Senior engineers still decide where that leverage should be applied.
Most writing about agentic engineering is about what agents can do. This is the other list — the decisions that stay with a person, and the reasoning behind each one. It is short on purpose. A long list would mean we had not thought carefully about where the line actually falls.
The common thread: agents are excellent at problems with a checkable answer, and unreliable at problems where the answer is a judgment about consequences.
What Should Exist
The first and most important exclusion.
An agent asked to build a feature will build it. It will not ask whether the feature solves the user’s actual problem, whether a simpler mechanism would work, or whether the request is a symptom of something upstream that should be fixed instead.
That is not a limitation of the model. It is a consequence of the framing. The agent receives a specification and optimises toward it. Questioning the specification requires knowing what the business is actually trying to achieve, what it tried before, and what it can afford to maintain.
Every engagement we run has a moment where the most valuable output is “we should not build this.” An agent has never once produced that sentence unprompted, and we do not structure the work as though it might.
Architectural Boundaries
Where the seams go is a judgment about the future.
An agent can implement a module boundary faithfully once you have drawn it. It cannot reliably decide where to draw it, because that decision depends on which parts of the system you expect to change independently over the next three years — and that is a claim about the business, not the code.
Get the boundaries right and mediocre code inside them stays cheap to fix. Get them wrong and excellent code becomes expensive to move. Agents produce a lot of code quickly, which raises the cost of a wrong boundary rather than lowering it.
So the senior engineer decides:
- What the modules are and what each one owns.
- Which direction dependencies flow.
- What crosses a network boundary and what does not.
- Which parts are allowed to know about which other parts.
Then the agents build inside those lines.
The Data Model As A Contract
Code is cheap to change. Data is not.
A schema that goes to production accumulates rows, integrations, reports, and downstream assumptions within days. Migrating it later is a coordination problem across every consumer, not a refactor.
Agents are good at writing migrations. They are not good at weighing whether a field should be nullable, whether this is really one entity or two, or whether denormalising here will cost you a consistency guarantee you will need later. Those calls are made with a person at the keyboard.
Security Posture
We will happily have an agent implement authentication against a design. We will not have it decide the design.
The distinction matters because security failures are not usually implementation bugs. They are modelling errors — the wrong trust boundary, an over-broad token scope, a permission checked at the wrong layer. Those errors produce code that works perfectly and is wrong.
Specifically off the table:
- What the trust boundaries are.
- What a given role may access.
- Where authorisation is enforced.
- What is logged, and what must never be.
- Which data leaves the system, and to whom.
An agent can review these decisions and often catches real problems doing so. It does not make them.
Irreversible Operations
Anything without an undo needs a human hand on it.
Production data deletion. Schema changes that drop columns. DNS cutovers. Credential rotation. Anything touching payments or customer communication.
This is less about capability than blast radius. An agent that is right 99% of the time is a fine collaborator on reversible work and an unacceptable risk on the 1% that cannot be walked back. We gate these behind explicit human approval regardless of how confident the plan looks.
flowchart LR
A[Task] --> B{Reversible?}
B -->|Yes| C{Checkable<br/>acceptance criteria?}
B -->|No| D[Human executes]
C -->|Yes| E[Agent implements,<br/>engineer reviews]
C -->|No| F[Engineer decides,<br/>agent assists]Naming And Domain Language
A small thing that compounds badly.
The words in your codebase become the words in your team’s conversations, your API, your documentation, and eventually your customers’ mental model. Agents pick plausible names from general programming convention. They do not know that your business already has a precise word for this concept, that the word means something specific to your regulator, or that two teams use the same term for different things.
Wrong names are cheap to introduce and expensive to remove. We keep domain vocabulary with the people who know the domain.
Judging Its Own Output
An agent is not a reliable judge of whether its work is done.
It will report success against the criteria it was given. If the criteria were incomplete — and they usually are, because the interesting failures are the ones nobody specified — a confident completion message means very little.
This is why every change is reviewed by the engineer who framed it, and why we invest in tests, evals, and type systems. Those are mechanical checks that do not share the agent’s blind spots. Self-assessment is not a control.
What This Leaves
A great deal, which is the point.
Implementation against a clear spec. Test coverage. Refactoring within established boundaries. Documentation. Migration scaffolding. Dependency upgrades. Debugging with a reproducible case. Boilerplate of every kind. The unglamorous volume that used to consume most of a team’s capacity.
That is where the leverage is. It is substantial precisely because the judgment layer above it is held steady by a person.
The teams that get poor results from agents usually have not drawn this line. They either restrict agents to trivial work and see little gain, or hand over decisions that need consequences weighed and spend the savings on rework.
The Bottom Line
Agents are extraordinary at problems with a checkable answer. They are unreliable at problems where the answer is a judgment about consequences.
The list of what we do not delegate is short: what should exist, where the boundaries go, what the data means, where the trust boundaries are, what cannot be undone, and what things are called.
Everything else is fair game — and there is a lot of everything else.