What Makes an AI System an Agent, and What Does Not

Not every AI workflow is an agent. Most of the things being sold as agents right now are prompt chains with job titles.

Last week I opened an AI tool and read the code. Four AI calls, one after another. Intake, document analysis, drafting, review. Each call had a job title in its system prompt. The interface described it as a pipeline of specialists.

It is a good tool. It is well built. It is not an agent.

This post sorts out the vocabulary. Agent, workflow, agentic workflow, orchestration, prompt, system prompt, skill. These words are being used interchangeably by people who should know better, and the confusion is not harmless. It changes how you price a system, how you audit it, and who is answerable when it gets something wrong.

The one question that settles it

Before the taxonomy, here is the test. Apply it to any AI product and you usually have your answer in thirty seconds.

Who decides what happens next: your code, or the model?

If your code decides, you have a workflow. If the model looks at the current state, picks an action, sees the result, and then decides whether to keep going, you are in agent territory.

Anthropic's applied AI team puts it better than I can. With a workflow, you own the plumbing. With an agent, the model owns the plumbing.

Everything below is elaboration on that one line.

Why the confusion exists

Three reasons, and only one of them is anyone's fault.

The umbrella problem. Anthropic uses "agentic systems" as a category covering both workflows and agents. Under that reading, a fixed prompt chain can honestly be called part of an agentic system. But Anthropic's own architecture guidance also says workflows are predefined and static, unlike the dynamic behaviour of individual agents. Both statements are true. Vendors quote the first and skip the second.

The framework problem. LangChain has a class called AgentExecutor that wraps what is functionally a chain. Your code imports something called an agent, so you assume you built one. The naming in the tooling got ahead of the concepts.

The commercial problem. "AI Agent" raises money. "Prompt Chain" does not.

The three tiers

The cleanest production taxonomy I have found comes from Anthropic, sharpened into three tiers rather than a binary.

Notice the failure column. It is often more diagnostic than the definition itself.

If your system fails by being too rigid, it is a workflow. If it fails by wandering off and burning tokens, it is an agent.

Prompt and system prompt

A prompt is input to a model. A system prompt is persistent behavioural instruction attached to a model call: identity, rules, constraints, output format, safety boundaries. The user prompt carries the specific task and the data.

Neither creates agency.

This matters because the most common way a workflow gets mislabelled as a multi-agent system is by giving each system prompt a job title. Calling a system prompt "Intake Analyst" does not create an intake analyst. Mechanically, four "agents" in most tools are four different system prompts sent to the same endpoint, in an order your code decided in advance.

Giving a model a professional title does not give it agency.

Chain and workflow

A chain connects operations so that one output becomes the next input. Anthropic calls this prompt chaining and lists it as the first of five workflow patterns. The other four are routing, parallelisation, orchestrator-workers, and evaluator-optimiser.

A workflow is broader. It can include conditional branches, parallel calls, human approvals, validation gates and retries.

A workflow with a branch is still a workflow, if your code wrote the branch.

Workflow and agentic workflow

This is where most of the confusion lives, because the term gets used in two incompatible ways.

The strict use. An agentic workflow is a workflow that contains agent nodes. Deterministic intake, then a research agent that loops internally, then a human approval gate, then deterministic formatting. That is a real and useful architecture, and most serious production systems look like this.

The loose use. Any multi step model system with a nice diagram.

I would not ban the loose use. I would ask that anyone using it says whether execution is code directed, model directed, or mixed.

Orchestration is not agency

Orchestration is the coordination layer. It handles execution order, model selection, context transfer, retries, timeouts, parallel work, state and stopping conditions.

A system can have sophisticated orchestration and zero autonomy. Per step timeouts, retry from failed step, and token cost accounting are all orchestration. None of them let the model choose anything.

The useful distinction is what kind of orchestrator sits in that layer.

• Deterministic orchestration. Your code says run A, then B, then C, then stop.
• Model directed orchestration. A lead model breaks the task down at runtime, delegates subtasks, and puts the results together. Anthropic calls this the orchestrator-workers pattern.

OpenAI splits model directed orchestration further into two patterns worth knowing. In the manager pattern, one agent holds the others as tools, calls them, and keeps ownership of the final answer. In the decentralised handoff pattern, control transfers to the specialist, which then owns the response.

A hardcoded loop over four API calls is sequencing. It is not orchestration in this sense.

Skills

Anthropic's Agent Skills spec defines a skill as a directory containing a SKILL.md file, alongside folders of instructions, scripts and resources that extend what an agent can do. A skill for writing reports might hold a house style guide, a structure template, a list of things never to claim, and a script for pulling comments out of a DOCX.

The mechanism is the interesting part. Skills load in three levels. Only the name and description sit in the system prompt at startup, about 30 to 50 tokens each. The full SKILL.md body loads when the model decides the skill matches. Supporting files load only when the body reaches for them.

Practitioners consistently report that when a skill fails to trigger, the problem is almost never the instructions. It is the description.

Two things follow, and they pull in opposite directions.

A workflow can absolutely load a skill file through hardcoded logic, so the presence of skills proves nothing on its own. But progressive disclosure only makes sense if something is deciding what to load. The spec was designed around a model that chooses.

So skills are weak evidence of agency, not proof. And the reason they are weak evidence is itself informative about where the line sits.

What actually makes an agent

No single feature is enough. Multiple steps do not create agency. A persona does not. JSON output does not. Memory alone does not. Tool access alone does not.

The combination is what matters. Here is my working definition, put together from the sources at the end.

An AI agent is a goal directed system in which a model has bounded authority to select and execute actions, use tools, observe the resulting state, adapt its plan, and continue until it reaches a completion or termination condition.

Broken into a checklist you can actually run:

1. Goal. The system receives an outcome to pursue, not one isolated transformation.
2. Loop. The structure is observe state, choose action, execute, observe result, repeat.
3. Dynamic tool selection. The model picks from two or more tools based on context, not from an if-else block you wrote.
4. Environment feedback. Tool results genuinely change later decisions. The system gains ground truth at each step.
5. State. Context builds up across iterations rather than resetting on every call.
6. Self termination. The model signals completion. The loop breaks on that, or on a maximum iteration guardrail, not on a hardcoded step count.

OpenAI's framing is compatible and worth putting alongside this. An agent is a system with instructions for what it should do, guardrails for what it should not do, and tools for what it can do. Their guide is explicit that a simple model application is not an agent.

Running a real tool through the checklist

Here is the pipeline I opened last week, reduced to its shape.

User request and documents
|

    Intake call -> returns strict JSON

    Document call -> returns strict JSON

    |

    Work product call -> returns draft

    |

    QA review call -> returns final Markdown

    | Output shown to user

Four calls, hardcoded, same order every run.

And here is the part of the QA system prompt I keep thinking about.

Do not explain your review process.

Do not mention the four-call pipeline.

Do not mention agents.

The architecture is deliberately hidden from the user. I do not think that is dishonest. It is a UX decision. But it is a neat illustration of how the label detaches from the code.

Here is the scorecard.

Three of six, and the three that fail are the decisive ones.

The correct label is a sequential prompt chaining workflow with role specialisation.

The detail almost everyone would miss

The fourth call looks like Anthropic's evaluator-optimiser pattern. One model generates, another evaluates.

But evaluator-optimiser requires a loop. The evaluator sends feedback and the generator revises until it passes a quality bar.

This QA call evaluates once and cannot return the work. It is a single pass reviewer, not an evaluator-optimiser.

Read the role labels and you classify it wrong. Read the control flow and you get the right answer. That is the whole reason the vocabulary matters.

Being fair about it

Andrew Ng frames agentic AI not as autonomous chaos but as structured, controllable workflows. He argues most real world gains come from well designed workflows rather than bigger models. Reflection, meaning draft then critique then revise, is one of the patterns he recommends most strongly.

So a QA review stage is a good design decision, not a pretension. Ng's own caution is the fairest sentence anyone could write about this tool: self critique is not full autonomy.

And there is an inversion worth sitting with. Anthropic's guidance says workflows offer predictability and consistency for well defined tasks, and agents are the better option when flexibility and model driven decision making are needed.

A drafting task with known steps is exactly what should be a workflow. The architecture is arguably correct. Only the vocabulary is off.

Who gets to define this

Fair question, and the honest answer is not "Anthropic said so."

Authority here rests on four legs, and it is convergence rather than any single ruling.

Russell and Norvig give the classical foundation. An agent perceives its environment through sensors and acts on it through actuators, and a rational agent acts to achieve the best expected outcome under uncertainty. Artificial Intelligence: A Modern Approach is the standard AI textbook, so this is as close to canonical as the field gets. The catch is that the definition is broad enough that a thermostat qualifies. It cannot separate a modern language model agent from ordinary automation. It is a foundation, not a test.

Wooldridge and Jennings narrow it usefully for software. Their four properties are autonomy, meaning control over actions and internal state; reactivity, meaning perceiving and responding to change; proactiveness, meaning goal directed initiative; and social ability, meaning interaction with other agents or humans. Their real contribution is that agency comes in degrees. A system can be reactive without being proactive. That gets you out of the binary trap.

Anthropic provides the operational modern distinction, and their essay has become the reference the ecosystem cites rather than argues with. It came out of applied engineering work, not a marketing team.

OpenAI and Andrew Ng confirm it independently. OpenAI's guide reaches a compatible definition with different vocabulary. Ng, from a third direction, treats plain prompt to response as not agentic, calling it the baseline to beat.

The honest caveat: no standards body owns this term. There is no ISO definition of an AI agent. The strong claim available is not that one definition is authoritative. It is that four independent sources draw the line in the same place, and that convergence is what makes the line worth respecting.

Why mislabelling is expensive

This is not pedantry. Here is what it actually costs.

Money. A fixed four call pipeline bills the same content repeatedly, because each stage's output becomes the next stage's input. You pay agent scale prices for chain scale capability, on every request, including trivial ones.

Procurement. To a buyer, "agentic" implies adaptive verification. A chain with no lookup tool cannot verify a fact. Its QA stage is one language model checking another language model, which is structurally incapable of factual grounding no matter how good the prompt is. Selling that as agentic verification is a misrepresentation risk, not a wording quibble.

Audit and debugging. Workflows are predictable and inspectable step by step. Agents may take a path nobody anticipated. If you hold the wrong mental model, you will look for the bug in the wrong layer.

Governance. This is the part I think is genuinely missing from current practice. Documenting an AI system by listing its prompts is adequate for a workflow and inadequate for an agent. Once a model controls execution, the prompt is the least interesting thing about the system.

What documentation should disclose

I would like to see AI system documentation state, as a matter of routine:

• Whether execution is deterministic, model directed, or mixed
• What actions the model can start on its own
• Which tools it may call, and with what permissions
• What data it can reach, and whether it can change external systems
• How it decides to stop
• Whether the plan can change mid run
• Where human approval is mandatory
• Whether intermediate decisions are logged
• Whether the same input can produce materially different execution paths

That last one is the sharpest question.

In a workflow the answer is no. In an agent it is yes, and everything about oversight follows from that.

What would make it an agent

Not a rewrite. A modest change, which is itself the proof that this boundary is architectural rather than a matter of scale or sophistication.

1. Add real tools. A search or database lookup, so verification touches ground truth instead of another model's opinion.
2. Add a loop. Let the reviewer return work to the drafter with specific defects, capped at a maximum number of iterations.
3. Add routing. Skip document analysis when no documents were uploaded. Cheap, deterministic, reliable.
4. Move the stopping condition into the model. Not a constant in the source file.
5. Make guardrails a layer, not a stage. Relevance and safety classifiers, PII detection and output validation running alongside the work rather than after it.

Steps one and two alone would cross the line.

The frame I would leave you with

Most real systems live somewhere between a pure workflow and a pure agent. Purity tests are not useful.

The useful question is never "is this an agent." It is:

How much control have I handed to the model, and can I afford the consequences?

Answer that clearly in your documentation and I do not much mind what you call it.

This is also why a better model will not fix unclear thinking. The architecture decisions sit above the model, and they are the ones that decide whether the output can be trusted.

Sources

• Anthropic, Building Effective Agents
• Anthropic, agent pattern implementations in the Claude cookbook
• Anthropic, Equipping agents for the real world with Agent Skills
• Agent Skills specification
• OpenAI, A Practical Guide to Building Agents
• OpenAI, orchestration and handoffs
• Andrew Ng, agentic design patterns
• Russell and Norvig, Artificial Intelligence: A Modern Approach, chapter 2
• Wooldridge and Jennings, Intelligent Agents: Theory and Practice
• Microsoft, system message design guidance