The word “agent” is everywhere right now. Every product demo has one. Every YC batch ships one. But spend five minutes looking at what most of them actually do, and you’ll find the same thing: a language model with a longer system prompt.
That’s not an agent. That’s a chatbot in a trench coat.
The real definition
An agent is a system that perceives its environment, makes decisions, and takes actions that change that environment — in a loop, without a human in the middle of every step.
Three things matter:
-
It can act. Not just respond — act. Call an API, write a file, send a message, trigger a build. If the model can only produce text that a human then acts on, you have an assistant, not an agent.
-
It can observe the result. After acting, the agent gets feedback — did the API call succeed? What did the query return? It uses that to decide what to do next.
-
It loops. The reason-act-observe cycle repeats until the task is done or the agent decides it can’t proceed. One round trip isn’t an agent; it’s a function call with extra steps.
Where most “agents” fall short
The most common failure mode is no real tool use. The model “decides” to search the web, but there’s no actual search happening — it’s pattern-matching on training data. Or the tool calls are one-way: the agent sends a message but can’t read replies. The loop is broken.
The second failure mode is no goal clarity. Agents need a stopping condition. Without one, they loop forever or hallucinate completion. A well-designed agent knows when it’s done.
Chatbot vs agent in one sentence
A chatbot answers. An agent does.
If your user has to read the response and then do something themselves, you built a chatbot. If the system reads the response and acts on it autonomously, you built an agent.
Why the distinction matters now
The tooling gap between “chatbot” and “agent” used to be enormous — you were writing orchestration logic, retry handling, state management, tool dispatch, and context windows by hand. That gap is closing fast.
Protocols like MCP (Model Context Protocol) give agents a standard way to connect to tools. Frameworks are converging on common patterns for the reason-act-observe loop. The boilerplate is shrinking.
Which means the hard part is no longer the plumbing. It’s the design: knowing what your agent should decide, what it should act on, and when to stop.
Get that right and the rest is engineering.