Ask an AI agent to "book a flight to Chicago under $400 and add it to my calendar," and a plain chatbot stops at the first sentence — it can describe how you'd do that, but it can't actually check fares, make a decision between options, or touch your calendar. An agent is the version of that system built to close the gap between describing a task and finishing it: it plans a sequence of steps, calls tools to execute them, checks its own results, and adjusts when something doesn't go as expected — with no human re-prompting it at each step.
A conversational chatbot is fundamentally reactive: you send a message, it sends one back, and the loop repeats until you stop. It has no ability to act on the world beyond generating text, and no persistent plan connecting one exchange to the next. An agent adds three things a chatbot lacks: tools it can actually call (search the web, run code, query a database, send an email), memory or state that persists across steps within a task, and a loop that lets it evaluate its own output and decide whether to continue, retry, or stop. The underlying language model is often the same technology in both cases — what changes is the scaffolding wrapped around it.
That loop is what people mean by "agentic" — the system isn't just producing an answer in one pass, it's iterating against real feedback from its own actions until the task is actually done, or it determines it can't be.
| Use case | What the agent does |
|---|---|
| Coding assistants | Reads a codebase, writes changes, runs tests, fixes failures |
| Research tasks | Searches multiple sources, cross-checks claims, synthesizes a summary |
| Customer support triage | Reads a ticket, checks account data, resolves or escalates appropriately |
| Data pipeline monitoring | Detects an anomaly, investigates the cause, files or fixes the issue |
The common thread across all four: the task has a clear success condition (tests pass, the ticket is resolved, the summary answers the question) that the agent can check itself against, which is what makes the "act, observe, decide" loop actually work rather than drift.
Agents fail in fairly predictable ways. Long task chains compound small errors — if each step has a small chance of a mistake, a ten-step task has meaningfully worse odds of ending up correct than a two-step one, since errors don't average out, they accumulate. Ambiguous success criteria are another common failure mode: an agent given a vague goal ("make this code better") has no reliable way to know when it's done, and can loop indefinitely or stop prematurely. And agents given broad tool access without guardrails can take actions a human would have caught as clearly wrong — which is why most production agent systems today constrain what tools an agent can call and require human approval for higher-stakes actions like sending money or deleting data.
A single agent handles one task end to end. A multi-agent system splits work across several agents with different roles — one plans, one researches, one writes, one reviews — passing work between them. Multi-agent setups can handle more complex tasks by dividing responsibility, but they also introduce coordination overhead: agents can miscommunicate, duplicate work, or disagree about what's already been done. As a rule, the added complexity of a multi-agent system is worth it once a single agent's context window or tool scope genuinely can't cover the task alone — not before.
Not every problem benefits from agentic scaffolding, and adding it where it isn't needed just introduces unpredictability without a corresponding benefit. A task is a good candidate for an agent when it has a clear success condition the system can check itself, requires more than one tool call or step to complete, and the exact sequence of steps can't be fully predicted in advance — if you already know the fixed sequence, a regular script will be faster, cheaper, and more predictable than an agent making the same decisions dynamically every time. Conversely, a single well-crafted prompt to a language model is often sufficient when the task is a single transformation — summarizing a document, classifying a piece of text, drafting a reply — with no need to call external tools or verify intermediate results.
A useful gut-check: if you can write out the exact steps a human assistant would follow, in order, without any "it depends," you probably don't need an agent — you need automation, which is simpler to build, test, and debug. Reach for an agent when the steps genuinely depend on what happens at each stage, in a way that's impractical to pre-script.
Because agent errors can compound across steps, well-built systems constrain what an agent can actually do, rather than trusting the model's judgment unconditionally. Common patterns include an explicit allowlist of tools scoped narrowly to the task at hand rather than blanket access, spending or rate limits on any tool that costs money or sends external communication, a required human approval step before irreversible actions (deleting data, sending payments, publishing content externally), and logging every action the agent takes so a human can audit what happened after the fact. None of this eliminates the value of agentic systems — it just reflects that "autonomous" and "unsupervised" aren't the same thing, and the best current systems are deliberately designed to keep them separate.
No. Traditional automation follows a fixed, pre-written sequence of steps — if the input changes shape, it breaks. An agent uses a language model to decide its own steps dynamically based on the goal and what it observes along the way, which lets it handle situations the original designer didn't explicitly script for, at the cost of being less predictable than a fixed script.
Technically yes, and many production systems run that way for low-risk, easily-reversible actions. For higher-stakes actions — anything involving money, irreversible deletions, or external communication sent on someone's behalf — most well-designed systems insert a human approval step specifically because agent errors compound and aren't always easy to catch after the fact.
Three ingredients: a language model capable of following multi-step instructions, a defined set of tools it's allowed to call (even a small set — web search and a code execution sandbox covers a surprising amount), and a loop that feeds each tool's output back into the model's context so it can decide the next step. Most current agent frameworks (LangChain, the OpenAI Assistants API, Claude's tool use) exist to handle that loop so you don't have to write it from scratch.