What an AI Agent Is and How It Differs from a Chatbot

The word “agent” now covers too much. In this guide it means one specific thing: a program that decides in a loop which tool to call next in order to get closer to a goal.

An agent versus a single model call

The difference is not prompt sophistication, it is the presence of a loop.

A single call. Text in, text out. The model does nothing to the world. Classifying a ticket, extracting fields from an email, rewriting a paragraph - one call, and an agent is surplus.

An agent. The model receives a task and a set of tools, picks a tool, sees the result, picks the next, and continues until done. It makes decisions as it goes rather than executing a predefined sequence.

The practical test: if you can draw the process as a flowchart in advance, you need a workflow, not an agent. A workflow is predictable, cheaper and easier to debug. An agent belongs where the next step depends on what the previous one uncovered.

A chatbot, in these terms, is a special case of a single call with message history. It answers; an agent acts.

What an agent is made of

Four parts, all of them mandatory.

A model. It makes the decisions. Different parts of the system can run on different models: analysis on a strong one, mechanical steps on a fast one - see the model router.

Tools. What the agent acts with: a database query, an API call, sending a message, writing a file. The underrated detail: tool descriptions matter more than the prompt. The agent picks a tool by its description, and a vague description means the wrong pick.

Memory. What the agent retains between steps and between runs. Context runs out sooner than people expect - see agent memory.

The loop and its bounds. How many steps are allowed, what counts as done, what happens on error. Without explicit bounds an agent either spins forever or stops halfway and reports success.

When an agent is needed and when it is surplus

Needed:

• The next step depends on the result of the previous one, and there are many options.
• Input arrives unstructured and must be interpreted before anything can be decided.
• The process involves search: finding the relevant thing among many, rather than processing a given one.
• The branch count is too large to express as conditions.

Surplus:

• The process is fully known and stable. That is a workflow - see n8n.
• There is one step. That is a model call.
• Errors are unacceptable and the result cannot be checked automatically.
• The task is a database query. This is the most common form of overengineering.

On cost specifically: an agent costs several times what a workflow costs, because every loop step resends the whole accumulated context. The difference does not show in a demo, it shows at volume.

What breaks in production

The demo almost always works. Other things break.

The agent lies about the result. It reports the task as complete when the tool returned an error. That is not rare, it is the default behaviour: the model completes the plausible ending. The fix is a verification layer that checks the fact rather than the report.

Constraints live in the prompt. “Do not delete data” in a system prompt is a wish, not a constraint. A real constraint is the absence of that tool or that permission. Covered in guardrails and in rollout.

Reruns repeat actions. The agent restarted and sent the email a second time. Idempotency does not appear on its own in agent systems - see idempotent pipelines.

Context runs out. A long task hits the window, part of the history is lost, and the agent proceeds on an incomplete picture without saying so.

Cost grows non-linearly. A task that finished in five steps in testing sometimes takes forty in reality. A step limit is mandatory insurance, not an option.

Where to go next

An order that saves time:

1. Building an agent: from prompt to production - the overall shape of the work.
2. A step-by-step walkthrough on a real case - what it looks like in practice.
3. Rollout: guardrails and verification - before you ship.
4. Memory and context and multi-agent designs - when one agent stops being enough.

If the question is money rather than technology: where agents pay off and where they do not. If you want a local stack: local agents and self-hosted models. On framing tasks for a model: prompt layers and the basics. On what agent development looks like as a piece of work.

What this looks like on a real project

A worked example: Megascope, where collection and parsing run automatically and the model handles the part that genuinely requires interpreting unstructured input, rather than the whole process. That is the usual working proportion: an agent inside the process, not instead of it.

If you need a system like that for your own problem, the terms are on the services page.

Neighbouring guides

These four topics describe one ecosystem, and each on its own solves half the problem.

• Claude Code - a development agent in the terminal: for when the machine should write and verify the code while you make the decisions.
• MCP servers - how to give an agent access to your data and systems in one way that works across tools.
• n8n - for when the sequence is known in advance and no agent is needed: workflows are cheaper, more predictable and easier to debug.