What Makes Something an Agent?

An agent is a system where the model, not your code, often decides which steps to take next.

The word “agent” gets stretched to cover anything with a model inside it. A chatbot is an agent. A summarizer is an agent. A script that calls an API twice is an agent. When a word covers everything, it explains nothing. So here’s a sharper line, and it has nothing to do with how smart the model is: an agent is a system where the model owns part of the path.

Let’s walk through it.

The first useful thing we built with language models was the feature. Your app sends a prompt, the model returns a summary or a classification or a rewritten paragraph, and your code does the rest. The model is a function call with a fuzzy output. You decide when to call it, what to feed it, and what to do with the answer. The path through the program is yours. The model is a clever subroutine sitting inside a control flow you wrote line by line.

Then came orchestration, and this is where the confusion starts. Orchestration chains several model calls together: retrieve some documents, ask the model to draft, validate the output against a schema, retry if it fails, call a tool, summarize the result. It looks sophisticated. It often is. But notice who’s still driving. You wrote the chain. The order of steps lives in your code. The model fills in the blanks at each station, but the assembly line was designed in advance and it runs the same way every time. RAG pipelines, structured-output workflows, most of what gets demoed as “AI-powered,” all of it is orchestration. The model is a better subroutine now, called in more places. The path is still yours.

Agents break that arrangement in a specific way. The model decides what to inspect next. It decides which tool to call, and whether to call one at all. It looks at a result and judges whether that result was good enough, then decides whether to keep going or stop. The control flow you used to own now lives partly inside the model’s reasoning, generated fresh on each run, different every time the inputs change. You didn’t write the path. You wrote the conditions under which the model writes its own.

That single shift changes what you’re actually building. When you owned the path, the surrounding code was plumbing. It moved data from one place to the next and the interesting work happened inside your logic. Hand the path to the model and the plumbing becomes the product. Now the question that decides success isn’t “did I sequence the steps correctly” (you didn’t). It’s “did I give the model what it needs to sequence them well?” What can it see when it decides? What can it actually do? The harder questions come after: how does it know when it’s done, and what is it allowed to touch without asking?

So the test for whether you’ve built an agent isn’t “does it use a language model” or even “does it use tools.” It’s whether you could predict the exact sequence of steps before you ran it. If you can, you wrote a workflow with a model in the loop, and that’s often exactly what you should build. If you can’t, because the model gets to choose, then you’ve built an agent, and you’ve also signed up for the work that agency demands.