What Makes A System Agentic

The word "agent" has been stretched until it stopped carrying information. It gets applied to a scripted pipeline that calls a model once, to a chat interface with a search tool bolted on, to a long-running process that spends an afternoon editing a codebase, and to a speculative system that supposedly runs a department. These are not variants of one thing. They differ along the single property that determines how you build, test, secure and operate them, and the word obscures exactly that property.

Here is the definition worth keeping. A system is agentic to the degree that the model, rather than the author, chooses what happens next. That is the whole distinction. Everything else — tool use, memory, planning, reflection, several models talking to each other — is machinery in service of that choice, or compensation for the problems it creates. If the sequence of steps is fixed when you write the code and the model fills in the content of each step, you have a workflow. If the sequence is decided at runtime by a model reading the result of what it just did, you have an agent. Most real systems sit somewhere between, and where they sit is a design decision you make rather than a fact you discover.

The second thing worth keeping is a bias. Autonomy is not a feature. It is an expense, paid in predictability, testability, cost variance and incident surface, in exchange for the ability to handle situations you did not enumerate in advance. Sometimes that trade is obviously correct. Frequently it is not, and the thing that ships is a workflow with a model in it — which is the right answer, usually arrived at reluctantly, and usually described afterwards as an agent because that is the word the roadmap uses.

The spectrum, stated as levels

It helps to stop asking whether something is an agent and start asking how much control flow you have handed over. There are roughly five positions, and systems frequently occupy different positions in different parts of themselves.

Level	Who decides the next step	Characteristic failure	What you can promise
Scripted pipeline	You, at design time	A known step produces bad output	A latency budget and a path-complete test suite
Model in a step	You; the model fills the content	Right shape, wrong content	The same, plus an output variance you must evaluate
Routed workflow	The model picks one branch from a fixed set	Misrouting into a valid but wrong path	Every path enumerable and individually testable
Constrained loop	The model picks tools from a fixed set, bounded iterations	Wrong sequence, repetition, premature stopping	A cost and step ceiling, not a specific path
Open-ended autonomy	The model sets subgoals, tools and stopping condition	Anything, including novel failures	Very little without heavy runtime controls

Read down the last column, because it is the one that appears in your incident review. As you descend, what you can honestly promise degrades from a tested path to a bounded envelope. You do not get to skip that trade by choosing a better model. A more capable model widens the range of tasks that succeed; it does not restore your ability to enumerate what the system will do.

Who chooses the next step

The useful way to think about this is where control flow lives. In a workflow, control flow is in your code: readable, diffable, reviewable, covered by tests, changed deliberately by a human who leaves a commit message. In an agent, control flow is in the model's weights and the current context: not readable, not diffable, different on Tuesday because you changed a sentence in the system prompt or because a tool returned a longer error string than usual.

Everything awkward about agents follows from that relocation.

Testing changes category. With enumerable paths you write tests per path and reason about coverage. With a runtime-decided sequence, the unit under test is a trajectory, and you are sampling from a distribution rather than asserting on a function. This is the subject of evaluating agents and the underlying discipline is covered in testing non-deterministic systems.

Cost becomes a distribution with a tail. A workflow's cost per run is roughly known. A loop's cost depends on how many iterations it takes, which depends on how confused it got, which depends on the input. The median is fine and the ninety-fifth percentile is the one that shows up on the invoice, as argued in inference cost as an architectural constraint.

Blast radius is decided at runtime. In a workflow you know which mutating calls can occur and in what order. In a loop, the set of possible action sequences is the set of permutations of your tool list, bounded only by your iteration cap. That is why authority has to be enforced outside the model, which is the entire argument of designing agents with bounded authority.

Debugging becomes archaeology. A failed workflow has a stack trace. A failed agent run has a transcript, and the question is not which line threw but why, at step nine, the model believed a tool result meant something it did not. You need that transcript recorded and queryable before the incident, not after.

Most production agents are workflows, and should be

This is the unpopular part and it is the part that holds up. Walk through the systems that have actually made it into production doing useful commercial work, and the overwhelming majority are pipelines with one or two model-shaped holes in them. Document arrives, gets classified, gets fields extracted, gets validated against a schema, gets routed. Support message arrives, gets categorised, gets drafted against a retrieved knowledge base, gets shown to a human. The model is doing the part that resisted automation for twenty years — dealing with unstructured human language — and the control flow is doing the part control flow has always done.

That is not a failure of ambition. It is the correct design, for reasons that are structural rather than temporary.

The process is already specified. If you can draw the flowchart, the flowchart is cheaper, faster, more reliable and easier to change than a model rediscovering it on every request. Paying a model to infer a procedure you already know is paying for the same work repeatedly at a worse success rate.

Determinism is frequently what you are being paid for. In a regulated or contractual context the requirement is not "handle this well" but "handle this the same way every time, and be able to show that you did". A fixed path is evidence. A trajectory is a story.

Failures land somewhere you can look. When step three of a five-step pipeline degrades, you know it is step three, you have metrics on step three, and you can improve step three in isolation. When a loop degrades you have an aggregate success rate and a pile of transcripts.

Cost and latency are predictable enough to sell. You can put a workflow behind a synchronous API with a timeout. Putting an open loop behind one is how you discover that your p99 is a different animal from your median.

It is a much smaller change to how you operate. A workflow fits the on-call model, the change process and the review culture you already have. An autonomous system does not, and the organisational cost of that mismatch is usually larger than the engineering cost of the system.

The test for when autonomy earns its unpredictability

Before you hand over control flow, five conditions should hold. Not three of them. All five.

1. The situation space is genuinely open. You tried to enumerate the branches and the tail kept growing. Every time you added a case, two more appeared in the logs. If your branch list converged, build the branches.
2. Verification is cheaper than generation. There is a check — a compiler, a test suite, a schema, a reconciliation, a human glance — that is substantially cheaper than the work itself and catches most of what matters. Without this, autonomy produces confident output nobody can afford to validate, which is worse than no output.
3. The cost of a wrong step is bounded and recoverable. Every action the loop can take is either reversible or gated. If a plausible sequence ends in an irreversible external effect, you do not have a design problem, you have a liability.
4. Latency and cost variance are tolerable. Somebody is willing to wait an unknown number of minutes and pay an unknown multiple of the median. Often the honest answer is no, and that alone settles it.
5. There is somewhere to put the human. A defined escalation point, a review queue, an approval step, a person who owns the outcome. "The agent handles it" is not an operating model; it is an absence of one.

The honest arithmetic is that for most business processes at least one of these fails, usually the second or the fourth. That is not a reason to avoid the technology. It is a reason to put the model where the ambiguity is and leave the control flow where it already works.

The middle is where the good systems live

The useful design is rarely the fixed pipeline and almost never the open loop. It is the constrained loop: a model that chooses from a small, deliberately curated tool set, inside a hard iteration and spend cap, with irreversible actions gated behind a human, and with the surrounding process fixed in code. The model gets to decide the order and the arguments. It does not get to decide the boundaries, the budget or the stopping condition.

That design gets you most of the adaptability — the ability to handle an input nobody anticipated, to recover from a tool failure by trying a different route, to stop early when the answer is already in hand — while keeping the properties that make a system operable. It is also the design that scales down gracefully. When you discover that a particular category of request is handled the same way every time, you promote it out of the loop and into a branch, which is cheaper and better. Agents that get more workflow-shaped over time are agents that are being learned from.

What to do on Monday

Take the system you currently call an agent and draw its actual control flow on one page. Mark every decision point with who makes it: you in code, or the model at runtime. Most teams find fewer model-made decisions than the word implies, and the ones they find are usually not the ones they would have chosen.

For each model-made decision, run the five conditions above. Any decision that fails a condition is a candidate to move back into code, and moving it back is usually a day of work that removes a class of incident permanently.

Then measure what you have actually got. Run fifty realistic tasks and record, per run, the outcome, the number of steps and the total cost. Look at the distribution rather than the mean. If the tail is wide, you have found the number you will be explaining to someone in six weeks, and you have found it early enough to do something about it. The next decision — which shape to build — is covered in agent architecture patterns, and the runtime controls that make any of it safe are in running agents in production.