An AI agent takes a goal, decides which steps to take, uses tools to carry them out, checks the result, and repeats until it finishes. One word carries the weight: decides. If you fix the steps in advance, you built a workflow, not an agent, and a workflow will usually serve you better.
What separates an AI agent from a chatbot?
A chatbot finishes one exchange. You send a message, it sends a reply, the interaction ends. An agent receives an outcome instead of a message, then keeps working until it reaches that outcome or gives up. The loop makes the difference.
Try it concretely. Ask a chatbot for a good subject line and you get a subject line. Hand an agent the goal "get this email opened by our lapsed customers" and it pulls the customer list, splits it into segments, drafts a variant per segment, and reports back. Nobody told it how many segments to make. It worked that out.
That freedom explains both the appeal and the risk. You gain a system that handles messy problems. You lose the ability to predict exactly what it will do.
What separates an agent from a workflow?
Most articles skip this distinction, and it decides your architecture. Anthropic's engineering team draws the line cleanly:
Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
Anthropic, Building effective agents
Put plainly: in a workflow you choose the order of operations and the model fills in the blanks. In an agent, the model chooses the order of operations.
| Workflow | Agent | |
|---|---|---|
| Who picks the next step | You, in code | The model, at runtime |
| Number of steps | You know it upfront | It emerges as the run goes |
| Cost per run | Predictable | Varies, sometimes wildly |
| When it breaks | You see which step failed | You reconstruct what it chose, and why |
| Good fit | Summarise, classify, extract, transform | Research, triage, multi-system tasks |
| Testing | Same input, same path | Same input, different path |
That last row causes more trouble than teams expect. An agent can solve a task on Monday and fail the identical task on Tuesday, because it picked a different route. Plan your testing around behaviour, not exact output.
Anthropic's original essay still holds, and the authors now point readers to their later work on Claude Managed Agents. A managed runtime can host the loop for you. It does not change who picks the next step. If the host still lets the model choose the path, you have an agent with someone else's harness. If you pre-wire the path, you have a workflow even if the vendor labels it an agent.
OpenAI's current agent docs make the same split operational: a code-first Agents SDK when you own the loop, and a managed Agents API when you want a hosted harness for long-running sessions. Neither option is a reason to skip the flowchart test. If you can draw the steps, you still should.
What can an AI agent do today?
- Support triage. It reads an incoming ticket, searches the help centre, answers when the answer exists, and otherwise routes the ticket with a summary attached.
- Research. It decides what to look up, reads several sources, and returns a structured answer with citations.
- Codebase chores. Give it "upgrade this dependency" and it finds the usages, edits them, runs the tests, and fixes what broke.
- Data questions. It works out which tables matter, writes the query, runs it, and explains the result.
One pattern runs through all four. The goal reads clearly, but nobody can count the steps before the work starts.
When should you skip the agent?
Most of the time, honestly. If you can sketch the steps on a whiteboard before you start, encode those steps. A workflow that always does the same four things runs faster, costs less, tests cleanly, and explains itself when it breaks at 2am.
Three signs point away from an agent:
- You can draw the flowchart. Then build the flowchart.
- A wrong answer costs real money. Agents fail unpredictably, so put a person in the loop before anything irreversible.
- You cannot define "done". An agent without a stopping condition keeps going until it exhausts its budget.
A useful gut check: if you would feel comfortable letting a new hire run this task unsupervised on day one, an agent can probably handle it. If you would want to review their work first, build that review into the system.
How do you stop an agent running away?
Four constraints prevent most of the damage, and none of them require anything exotic.
- A step budget. Cap the loop. Ten steps, then stop and report what it managed.
- A tool allowlist. The agent calls only the tools you handed it, and nothing else.
- A checkpoint before anything irreversible. Sending, paying, deleting, publishing. Ask a human first.
- A written trace. Log what it chose and why. Without that log you cannot debug it, you can only guess.
How do agents reach your tools?
The industry converged on a standard for this faster than most people noticed. The Model Context Protocol still describes itself as "an open-source standard for connecting AI applications to external systems". Think of it as the plug shape rather than the appliance. Expose your tools that way and an agent discovers them without bespoke glue code.
This page stays on the definition of an agent. The protocol, the server, and the security surface belong on What Is an MCP Server?. If you already run a server, point the MCP Server Tester at it. It connects over Streamable HTTP and lists exactly what an agent would see, which catches the common mistake of shipping tools with descriptions too vague for a model to choose between.
What does an agent actually cost?
Teams budget for the model and forget the rest. Three costs surprise people.
Tokens multiply. A workflow makes one model call per step you wrote. An agent makes a call to decide, another to act, another to check, and repeats. A ten-step run costs far more than ten times a single call, because each turn carries the growing history with it.
Debugging takes longer. When a workflow fails you read the stack trace. When an agent fails you read a transcript and infer intent. Budget engineering time for that, not just compute.
Evaluation never really finishes. Because the same input can take different paths, you test distributions rather than outputs. Teams that skip this ship something that worked in ten demos and fails in the eleventh.
How do you start without building anything?
Write the system prompt before you write code. The prompt forces you to answer the questions the architecture depends on: what the agent owns, what it must never touch, and what it should do when it lacks information.
The AI Agent Prompt Builder turns a description of the job into that structured prompt, including the uncertainty rules most people forget. When you want running code, the Prompt-to-Agent Scaffold produces a starter you can execute and edit.
For grounded behaviour, Document Chat shows the standard to aim for. It answers only from the document you gave it, and it tells you plainly when the document does not contain the answer. An agent that admits a gap beats an agent that fills it confidently.
The short version
An agent is a loop with judgment in it. Pay for that judgment when nobody can know the path in advance. Skip it when you already do. In 2026 the vendors will sell you a managed harness; buy the harness if it saves you ops work, but still start with the workflow and reach for the agent only when the flowchart stops fitting.