AI agent is a phrase that now appears on product pages, in coding tools, and in ordinary chat interfaces. The label is useful only if it tells you what the system can do. A chatbot can answer a question. A workflow can run a fixed sequence of model calls. An agent can decide which steps and tools to use while pursuing a goal, then inspect what happened and continue.
The difference is not whether the interface looks conversational. It is where the next action comes from. If the developer writes the path in advance, you have a workflow. If the model chooses the next tool call from feedback in the environment, you have an agentic loop.
Start with one task, not the word agent
Imagine the request: “Find why the checkout test is failing and propose a fix.” A simple chatbot can explain a pasted error. A workflow can run a predefined sequence: read the test file, run the test, summarize the output, and draft a response. An agent can inspect the repository, choose which files to read, run a relevant command, react to the result, and decide whether more investigation is needed.
| System | How the next step is chosen | Typical strength | Typical limit |
|---|---|---|---|
| Chatbot | The user asks for another step. | Explanation and conversation. | Does not independently act on the environment. |
| Workflow | Predefined application code. | Predictability and repeatability. | Struggles when the task path varies. |
| Agent | The model selects actions from available tools and observations. | Open-ended, multi-step investigation. | Higher cost, latency, and compounding error risk. |
Anthropic’s engineering guidance makes the same architectural distinction: workflows use predefined code paths, while agents dynamically direct their own process and tool use in its guide to effective agents. It also recommends starting with the simplest solution that meets the need.
The loop has five moving parts
A practical agent is easier to understand when you follow one cycle:
- Goal: the user or application defines the outcome.
- Plan: the model proposes a next step or sequence.
- Tool: the system reads a file, calls an API, runs a test, or changes a record.
- Observation: the environment returns a result, error, or state change.
- Decision: the agent continues, asks for help, or stops.
while not finished:
plan = model(goal, current_context)
action = choose_tool(plan)
observation = run(action)
current_context = update(current_context, observation)
if needs_approval(action):
pause_for_human()This pseudocode is not a complete implementation. It exposes the risk: the agent can repeat an unproductive action unless the system provides stopping conditions, useful observations, and a way to escalate uncertainty.
What makes a tool usable by an agent
A tool is not merely a function name. It has a contract: purpose, inputs, outputs, errors, side effects, permissions, and examples. “Run command” is a dangerous description because it hides what the command can touch. “Run the project’s read-only test command in the repository root and return exit code plus output” is more constrained.
| Tool property | Beginner-friendly question | Failure if missing |
|---|---|---|
| Scope | What can this tool access? | The agent edits or reads more than intended. |
| Input schema | What values are valid? | Malformed calls create confusing errors. |
| Output | What evidence comes back? | The agent cannot tell success from silence. |
| Side effects | Does it write, send, delete, or charge? | A seemingly small action has an irreversible consequence. |
| Stopping rule | When should the agent ask instead? | The loop keeps guessing or repeats itself. |
OpenAI’s Agents documentation describes agents as applications that plan, call tools, collaborate across specialists, and keep state for multi-step work. It also distinguishes an application-owned loop from an SDK-managed loop with guardrails and approval flows in the official guide.
A controlled failure: the agent that keeps searching
Return to the failing checkout test. The agent searches for a selector named `.checkout-total`, finds two files, edits the first one, runs the test, and sees the same failure. It searches for a similar selector, changes another file, runs the test again, and repeats.
Nothing about the loop guarantees progress. A robust system needs a maximum number of attempts, a record of actions already tried, a requirement to report evidence, and a checkpoint where a human can approve a risky change. The agent should be able to say, “I found two candidate causes and cannot distinguish them without the browser fixture,” rather than inventing confidence.
Useful stop: “The test still fails after two read-only investigations. I need permission to edit `checkout-total.js` or more context about the expected currency format.”
Anthropic notes that agents gain ground truth from the environment at each step and should be able to pause for human feedback or blockers. The company also warns that autonomy can compound errors, which is why sandboxing, testing, and guardrails matter.
When a workflow is better than an agent
Suppose every support ticket must be classified, enriched with an account ID, checked against a policy, and placed in a queue. A deterministic workflow may be easier to test and cheaper to operate. An agent adds value when the number of steps varies, the environment needs to be explored, or the right tool cannot be predicted from the input alone.
| Task shape | Start with | Why |
|---|---|---|
| Fixed fields and fixed order. | Workflow | Easy to test and explain. |
| One answer from a well-scoped document. | Single model call with retrieval | Less orchestration is easier to debug. |
| Several independent checks. | Parallel workflow | Separate evaluations can run without a planner. |
| Unknown files or steps in a repository. | Agent with sandbox and limits | The environment determines the path. |
| Irreversible external action. | Workflow plus human approval | Predictability and control matter more than autonomy. |
Calling a system an agent because it has a large language model can make design discussions less precise. Ask which decisions are dynamic, which tools are available, and what the system does when it is uncertain.
The augmented model behind the loop
An agent is not only a model. It usually combines an LLM with retrieval, tools, memory, instructions, state, and an execution environment. Each addition creates capability and a new failure surface.
goal
+ instructions and policies
+ current conversation state
+ retrieved project context
+ available tools
+ observations from the environment
= agent runMemory, for example, can mean short-term conversation state, stored user preferences, or a record of previous actions. These are different designs with different privacy and correctness implications. A tool that reads the current file is not the same as a memory store that persists the file’s contents for future sessions.
Our article on GitHub Copilot shows a narrower coding-assistant workflow, while using Claude for coding discusses conversational and agentic modes. The point of this article is the architecture behind those experiences.
Observability turns a demo into a system
To improve an agent, record what happened: the initial goal, selected tools, tool inputs, observations, approvals, errors, duration, and final result. Without a trace, a developer sees only “the agent failed.” With a trace, the developer can ask whether the planner chose the wrong file, the tool returned incomplete data, or the stopping condition was missing.
Evaluation should include realistic tasks, not only easy examples. A coding agent can pass a syntax check while changing the wrong behavior. A support agent can produce a polite answer while updating the wrong record. Measure the outcome that matters and include cases where the correct action is to pause.
Questions that separate agents from chatbots
Does a chatbot become an agent when it uses tools?
Tool use is an important capability, but the defining question is how the process is controlled. A fixed tool call in a workflow is different from a system that dynamically chooses actions and continues from observations.
Do agents always plan several steps ahead?
No. An agent may choose one next action at a time. What matters is that the system can select and revise actions based on the task and environment rather than following only a hardcoded path.
Are multi-agent systems always better?
No. Multiple specialists add coordination, state, latency, and new failure modes. Start with one model and a simple workflow, then add delegation only when it improves a measurable outcome.
Should an agent be allowed to deploy code automatically?
Only when the environment, permissions, tests, rollback path, and approval policy justify that level of autonomy. For learning projects, a sandbox and a human checkpoint are safer defaults.
Use autonomy where it earns its complexity
An agent is a loop that can pursue a goal through tools, observations, and decisions. That makes it powerful for open-ended work, but it also makes failure less predictable than a single answer or fixed workflow.
Start with the smallest design that can complete the task. Add tools with clear contracts, record the run, cap the attempts, and make the agent ask before it crosses a risky boundary. The word “agent” should describe a controlled architecture, not decorate an ordinary chatbot.
Apply guardrails before giving an assistant more autonomy →
Evaluate the result, not the performance theater
An agent can produce a long trace, call several tools, and still fail the task. Another can complete the same task with one well-chosen action. Count of tool calls is not a quality metric. Define a success test before the run: the intended file changes, the expected test result, the allowed side effects, and the condition that requires a human to take over.
For a coding task, evaluation might compare the diff with the issue, run the existing tests, add a regression test, and inspect whether unrelated files changed. For a data task, it might check schema, source provenance, and a sample of records. For a support task, it might verify the account action against an approval log. The metric should describe the user’s outcome, not the agent’s confidence.
Recovery is part of the design. If a tool returns a timeout, the agent should know whether retrying is safe, whether the request may already have succeeded, and when to stop. If a file edit fails, it should reread the file rather than applying the same patch blindly. Every loop needs a response to uncertainty.
Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.