What agentic AI is, and how it differs from chatbots and automation

A working definition

"Agentic" has become a marketing word, so it helps to tie it to something you can check in a design. A system is agentic to the extent that a model, rather than a developer, determines what happens next. If you can draw every step and branch of a process before it runs, it is a workflow, even if a model writes some of the text along the way. If the model can look at an intermediate result and decide to search again, call another tool or stop, control has moved to the model.

That shift is the whole point, and also the whole risk. It lets software handle tasks whose steps cannot be listed in advance. It also means the path through your system varies between runs, and a wrong decision can lead to a wrong action instead of just a wrong sentence.

The loop at the centre of an agent

Most agents, whatever framework they use, repeat the same cycle:

1. Read the goal and the current state. This includes the request, what has been tried and what came back.
2. Choose an action. The model either requests a tool with specific arguments or decides that it can finish.
3. Act. Your application validates the request and, if it is allowed, runs it. The model never executes anything itself.
4. Observe. The result, including any error, is added to the state.
5. Repeat or stop. The cycle ends with a final answer, a request for human help or a limit on steps, time or spend.

The surrounding parts are ordinary engineering: well-designed tools, state and memory, permission checks, logging and stopping conditions. The model supplies judgement within that structure. It should not be the structure.

Agents, chatbots and automation compared

The three are often lumped together because all of them can sit behind a chat box or a button. They differ in who decides what happens and in what can go wrong.

The boundaries are not sharp. A chatbot that looks up an order through one tool has taken a step towards agency. An automated pipeline might use a model to classify each ticket and still follow fixed branches, which makes it AI-assisted automation and not an agent. Neither label is better. The right question is how much decision-making the task needs.

One request, three designs

Take a hypothetical request to an online shop: "My parcel arrived damaged, and I want my money back."

• A chatbot explains the returns policy, perhaps accurately, and tells the customer what to do next. Nothing changes in any system.
• Automation presents a form, checks that the order is within the returns window and creates a refund case. It is fast and predictable, but a customer whose situation fits none of the branches goes to a person or gets stuck.
• An agent might find the order, notice that it was split across two shipments, ask which one was damaged, read the relevant policy, then propose a refund for review. The order of those steps is not written down anywhere; the model works it out from the case.

If nearly all cases look the same, the automated version is the better product: cheaper, faster and easier to audit. The agent earns its place only if the variation is real and frequent enough to matter.

Autonomy is a dial, not a switch

Treating "agentic" as yes or no leads to poor decisions. You can set the amount of freedom separately for each part of a system:

• Model as a single step. A fixed workflow calls the model to classify or draft something, and code decides the rest.
• Model as a router. The model picks one of several known branches.
• Model with read-only tools. It can search and look things up in a loop, but it cannot change anything. Mistakes cost time rather than cause damage.
• Model with gated actions. It can propose changes, and a person or a policy check approves them. See human-in-the-loop approval.
• Model acting alone, within limits. It makes reversible or low-value changes without review.

Working down this list one level at a time is usually wiser than starting at the bottom. Each level gives you real runs to study before you widen the permissions.

When an agent is worth it

An agentic design tends to pay off when most of these are true:

• The steps depend on what is found along the way. Investigation and research tasks are typical, because the next question follows from the last answer.
• Enumerating the cases is impractical. A workflow would need more branches than anyone could write or maintain.
• Mistakes can be caught or undone. Reads are safe, and risky actions can pass through review.
• Some delay is acceptable. Several model and tool calls take longer than a single reply.
• You can tell whether it worked. Without a way to judge outcomes, you cannot improve the agent or know if it has regressed.

When something simpler is better

If the path is known, write the path. A fixed workflow with one model call is easier to test, cheaper to run and simpler to explain to whoever audits it. Other warning signs include:

• Exact, repeatable results are required. Calculations, compliance steps and anything needing an identical outcome each time belong in code.
• The task is really a question over documents. A RAG pipeline may answer it without any loop.
• Actions are irreversible and no reviewer is available. Moving money or deleting records on a model's sole judgement is a poor bet.
• Latency budgets are tight. Every extra turn adds time and tokens, and the number of turns varies. Controlling LLM cost and latency covers the budgeting side.

The risks that come with acting

Moving from answering to acting changes the kind of risk you carry, and four issues deserve design time from the start.

Prompt injection. An agent that reads web pages, emails or tickets is taking in untrusted text that may contain instructions. If it also holds powerful tools, a manipulated model can misuse them. Limit what tools can do in code, as described in LLM guardrails and prompt injection defence.

Runaway runs. Agents can repeat a failing call or wander from the goal. Hard limits on steps, time and spend should live outside the model.

Compounding errors. An early misreading can shape each later step, and the final answer may look perfectly reasonable. Keep the full trace of a run so that you can find where it went wrong.

Accountability. Decide in advance who owns the outcome of an action taken by software, and record enough to answer questions about it later.

What about multi-agent systems?

A multi-agent system divides work between several agents, for example one that researches and another that checks the result. This can help when tasks need different tools, permissions or instructions, but it adds coordination and more places to fail. A single agent with well-chosen tools is the sensible default. The comparison of single agent and multi-agent systems sets out when dividing is justified.

Where to start

Write down one task, what "done" looks like and a few real examples of it. Try to draw the steps. Whatever you can draw, implement as ordinary code, and use a model only for the parts that resist being drawn. If a loop is still needed, begin with read-only tools and a low step limit, then read the traces from your first runs before giving it anything more. For a code-level walkthrough, see how to build an AI agent in Python.

If you are weighing up an agentic system with several roles, the multi-agent systems page describes what I can help with.

Frequently asked questions

Is ChatGPT an agent?

It depends on how it is being used. Answering from a single prompt is chatbot behaviour. When a product lets the model plan steps, use tools and act on the results towards a goal, that part of its behaviour is agentic. The label describes a design rather than a brand.

Is agentic AI the same as generative AI?

No. Generative AI describes models that produce content such as text or images. Agentic AI describes a system design in which a model chooses actions in a loop. Most current agents use generative models for those decisions, but the two terms answer different questions.

Is an agent just automation with an LLM?

Not necessarily. If a model only fills in one step of a fixed process, that is automation with an LLM. It becomes an agent when the model decides at run time which steps to take, in what order and when to stop.

Do agents always need a framework?

No. The core loop can be written in a small amount of ordinary code. A framework becomes useful when you need features such as checkpointing, resumable runs or complex routing, so the decision should follow from your requirements.