What is an AI agent? A practical definition, with real examples

The one-sentence definition

An AI agent is a system that uses a language model to decide what to do next, takes an action through a real tool, looks at the result, and repeats that loop until a goal is met or it hands off to a human. If there’s no loop and no tool, it isn’t an agent, it’s a chatbot or a text generator with a good prompt.

Why “chatbot with extra steps” is the wrong mental model

A chatbot takes an input and returns an output. One turn, no state beyond the conversation, no ability to change anything outside the chat window. An AI agent is judged on outcomes in the real world: did the ticket get resolved, did the record get updated, did the report get written and sent. That distinction matters because it changes what you have to build. A chatbot needs a good prompt and a UI. An agent needs tools, memory, error handling, and a way to know when to stop, which is most of what we wrote about in the boring parts of an AI agent that actually matter.

The three things every real agent needs

Tools. A way to actually do something: call an API, write to a database, send a message, run a query. Without tools, a model can only talk about doing things, not do them.

State. Memory of what’s already happened in this run, and often across runs: what was tried, what the user already said, what the last three steps produced. Without state, every step starts from zero and the agent can’t build toward a goal.

A loop with a stopping condition. Plan a step, take the action, observe what happened, decide the next step or decide it’s done. The stopping condition is the part teams skip, and it’s exactly why so many early agent prototypes either stop too early (leaving the task half-done) or never stop (looping until someone kills the process or the bill arrives).

Agent vs. RAG vs. plain automation

These get used interchangeably and they’re not the same thing. RAG (retrieval-augmented generation) is specifically about pulling relevant documents into a prompt so the model’s answer is grounded in real source material, it’s a single lookup-and-answer pattern, not a multi-step loop (more on when RAG is actually the right tool in RAG vs. fine-tuning vs. long context). Plain automation (an n8n flow, a cron job, a Zapier zap) follows a fixed, predetermined path with no model making judgment calls along the way. An agent sits apart from both: it uses a model to decide the next step dynamically, often calling RAG as one of its tools, and can diverge from a fixed path based on what it finds.

A simple taxonomy

Single-agent, tool-use loop. One model, a defined set of tools, a loop until done. The right starting point for most real use cases, and more robust than it sounds because there’s only one place decisions get made.

Multi-agent, planner-worker-critic. A planner breaks a goal into subtasks, one or more workers execute them, a critic checks the output before it ships. Earns its complexity when a task has genuinely distinct phases that benefit from different context or different scrutiny, not by default.

Human-in-the-loop vs. autonomous. Orthogonal to the above: does a person approve the action before it happens, or does the agent act and report after? Start human-in-the-loop for anything with real consequences, and only remove the human once the eval numbers earn that trust.

Six real agents, in production

Not demos. These are shipped and running:

• Driftpoint resolves 58% of e-commerce support tickets end to end, with a confidence threshold that hands off to a human for the rest.
• Scout, Atlas, Pulse, Vault, and Forge are five specialized HR agents inside EnrollVerse, each owning one domain (recruitment, leave, attendance, payroll, performance) and sharing context through an orchestrator.
• Fieldnote gives non-engineers a visual canvas to configure their own automations, with every run logged and replayable.
• Signalwell translates plain-English questions into validated SQL, with an automatic chart picker and a fallback to a human analyst when confidence is low.
• Larkwood coordinates live reservation state across nine locations from one shared system.
• Satchel runs categorization and a weekly plain-language digest without a human in the loop for the low-stakes parts of the job.

The most common mistake

Building an agent for something that didn’t need one. If a user already knows exactly what they want, a single button beats an open-ended agent nearly every time (we go deeper on this in why most “AI features” should be a button). An agent earns its complexity when the task is genuinely open-ended, multi-step, and benefits from a model making judgment calls a fixed script can’t.

How to tell if your idea actually needs one

Ask whether the task has more than one step that depends on what the previous step found, whether a fixed script could handle it instead, and whether getting it wrong is cheap enough to let the agent run with a human only reviewing the output after. If the answer to the first question is no, you probably want automation or a button, not an agent. If you’re not sure which, that’s a five-minute conversation, not a six-week build.