What Actually Makes an AI 'Agentic'

The word is doing a lot of work

"Agent" has become one of the most overloaded words in software. It now describes everything from a customer-support chatbot, to a retrieval pipeline that answers questions over your documents, to a cron job with a language model bolted onto the end. When a single word stretches that far, it stops carrying information, and that vagueness is not harmless. The label you attach to a system quietly decides how you architect it, how you test it, who signs off on it, and, most importantly, how it fails. Calling something an "agent" when it is really a fixed pipeline leads you to over-engineer. Calling something a "workflow" when it is really making autonomous decisions leaves you under-prepared for the ways it can surprise you.

So it is worth being precise.

A working definition

An AI system is agentic when it can pursue a goal across multiple steps, decide for itself what to do next at each step, and act on the world through tools, rather than producing a single response and stopping. Three properties have to be present together:

• Autonomy. It chooses the next action rather than following a fixed, pre-written script. Given the same goal twice, it might take two different routes.
• Tool use. It can affect something outside itself, query an API, read or write a file, send a message, run a calculation, and bring the result back into its reasoning.
• Feedback. It observes the outcome of each action and adjusts its next move accordingly, rather than executing a plan blindly.

Remove any one of these and you usually have something simpler and far more predictable. A model that uses tools but cannot choose among them is a function call. A model that loops but cannot act on the world is a thought experiment. A model that acts but never reads the result is an open-loop script that happens to contain an LLM.

A spectrum, not a switch

It helps to stop thinking of "agent or not" as binary and instead place systems on a spectrum of autonomy. At the low end sits a single prompt-and-response: deterministic enough that you can almost unit-test it. A notch up is retrieval-augmented generation, where the system fetches context but still answers in one shot. Higher still is a chain with a couple of fixed steps. And firmly in agentic territory is a loop that plans, calls tools, reads the results, and decides for itself whether it is finished or needs to keep going.

The key intuition: as you move up the spectrum, capability and unpredictability rise together. More autonomy lets the system handle messier, more open-ended tasks, and it also widens the range of things it can do that you did not anticipate. There is no free lunch. Every increment of autonomy you grant is an increment of control you give up, which you must buy back with guardrails, evaluation, and observability.

Why the distinction is practical, not academic

This is not pedantry. The label changes your entire engineering posture.

A scripted workflow fails in ways you can enumerate ahead of time. You can list the branches, write a test for each, and reason about the whole space of outcomes. An agent fails in ways you cannot fully enumerate, precisely because it is choosing its own path through a large space of possible actions. That single fact cascades into every part of how you build:

• You cannot test it with a handful of fixed inputs and outputs; you need evaluation across many tasks and many runs, because the same input can produce different behaviour.
• You cannot assume it will only do what you intended; you need guardrails that constrain the actions it is even capable of taking.
• You cannot debug it by reading the code; you need traces that show what it observed, decided, and did on a specific run.

Teams that treat an agent like a deterministic function get blindsided in production. Teams that respect its probabilistic, path-choosing nature design for it from day one.

A quick litmus test

When you are unsure what you are building, ask three questions. Does the system decide what to do next, or do you? Can it take actions that change the world, or only produce text? Does it react to the results of those actions, or run a fixed sequence? Three yeses mean you are building an agent and should adopt the discipline that demands. Mostly noes mean you have something simpler, and you should resist dressing it up as more.

Where to start

The most common and expensive mistake is making everything an agent because the word is exciting. Start instead with the least autonomy that solves the problem. If a fixed pipeline does the job, ship the pipeline; it will be cheaper, faster, and far easier to reason about. Add a single decision point only when the task genuinely requires choosing what to do next. Add a full loop only when the work cannot be expressed as a fixed sequence at all.

And whenever you do grant autonomy, grant it alongside the things that make autonomy safe: tightly scoped tools, a hard cap on iterations and cost, a clean way to hand off to a human, and a trace of every decision. Agency without those is not sophistication; it is a liability waiting for production traffic.