What Is an AI Agent? (And Why Chatbots Are Not Agents)

A chatbot answers. An agent finishes the job.

Open a chatbot, type a question, read the answer. Type another. Back and forth, human leading, model following. Close the tab and it is gone — no memory of what you asked, nothing done in the world outside the text box.

That is a chatbot, and for a few years that was everybody's experience of AI. It is genuinely useful and it has a hard ceiling: every step still needs a person to start it, read the result and carry it to the next step. You are not delegating. You are typing faster.

An agent is what you get when the model is allowed to keep going. You hand over a goal instead of a prompt, and the software plans, acts, checks its own work and loops until the job is done or it tells you it is stuck. Traditional AI answers a question. An agent completes a mission. One is a consultant you phone; the other is a colleague you delegate to.

The four parts that make something an agent

A language model on its own is not an agent, however capable it is. Four things have to be bolted on before the word applies:

• A reasoning engine. Usually the model itself, doing the planning: given this goal and this situation, what is the sensible next step? This is the part that decides, and it is why model quality still matters more than framework choice.
• Memory. Working memory across the steps of one task, and longer-term memory across sessions. Without it the agent forgets what it has already tried and cannot build on its own progress — it starts every step from zero. How much memory a job actually needs is a design decision, not a maximum; the Memory Ladder is our way of choosing the rung rather than defaulting to the top.
• Tools. Web search, code execution, reading and writing files, API calls, sending an email, querying a database. Tools are the whole difference between a system that talks about the world and one that reaches into it. An agent's usefulness is capped by the tools you give it.
• A feedback loop. The ability to look at the result of its last action and change course. A search that returned nothing useful means try different terms. Code that threw an error means read the error and fix it. Take this away and you have a script that fails silently.

Get all four working together and the behaviour changes qualitatively, not just quantitatively. Miss one and you have something that demos well and breaks in week two.

Agentic AI is the same idea, named from the other end

"Agentic AI" is the term you will see in vendor decks, and it means an AI system you give a goal rather than a single prompt — it decides the steps, chooses the tools, handles obstacles and keeps going until the goal is met or it reports that it cannot finish. The word borrows from the philosophical sense of agency: the capacity to act in the world on your own behalf.

So "agent" describes the thing and "agentic" describes the property. If someone is selling you agentic AI, the question to ask is which of the four parts above it actually has. A great many products marketed as agentic are a chat box with a system prompt.

The agent loop: plan, act, observe, adjust

Every agent, whatever it is built with, runs the same cycle. Engineers call it the agent loop, and understanding it is the fastest way to stop being surprised by agent behaviour.

• Receive the goal. Not a question — an objective. "Find the cheapest flight from Karachi to London in July." "Answer every WhatsApp enquiry today and book the ones that ask for a table." That goal is the agent's mission until it is done or declared impossible.
• Plan. The reasoning engine breaks the goal into sub-tasks. Sometimes it writes the plan out first; sometimes it decides each next step as it goes. Both work, and the explicit version is far easier to debug.
• Act. It executes one step with one tool. Search. Read the file. Run the code. Send the message. One action at a time, chosen from where it currently stands.
• Observe. It reads the result. Did the search return anything? Did the code run? Did the API give back what was expected? That observation goes back into its context and updates its picture of the situation.
• Reflect and repeat. Is the goal met? If yes, deliver. If no, revise the plan and take the next action. Round again until finished, stuck, or a checkpoint you set hands control back to a human.

That is the entire mechanism. It is deceptively plain, and it is the reason an agent can attempt work that used to need a team: the model checks its own output and keeps working instead of handing it back to you half-finished.

Memory is what makes the loop worth running

Strip memory out of the loop and every pass starts blind. Keep it and the agent accumulates context as it goes — every search result, every file read, every error hit — and each decision is made with more information than the last. That accumulation is why the tenth step of a long task is usually better judged than the first.

Longer-term memory, held outside the conversation, is what lets an agent remember a customer between Tuesday and Friday, or remember that this supplier always ships late. It is also the part people most often over-build. Most business jobs need far less memory than the demos imply, and every rung you climb costs money and adds a way to be wrong.

Assistant, agent, AI employee — three words used interchangeably, wrongly

An AI assistant is reactive. ChatGPT, Siri, Alexa, the support chatbot on a bank's website. It waits for an instruction and answers it: writing content, summarising, translating, recommending. Excellent at communication, and it needs you standing over it.

An AI agent is proactive. Given a goal it plans, decides, uses software tools and executes a multi-step workflow to completion. Ask an assistant to "write an email to this customer" and you get an email. Give an agent the goal of filling the calendar and it finds the leads, researches them, writes to each one, tracks the replies and books the meetings.

The practical test, and the only one that matters when you are buying: does the system finish the job, or does it hand the work back to you?

An AI employee is our name for the third thing: an agent given one specific job in one business, with memory of that business and a channel its customers already use. Not a general-purpose assistant — a sales agent, a support agent, a booking agent. That narrowing is what makes the difference between an impressive demo and something a business will pay for every month. What is an AI employee? sets out the four parts and five worked examples.

Traditional AI and agentic AI, side by side

The same comparison, dimension by dimension:

• Input. One prompt or query, against one high-level goal.
• Output. One response — text, image, code — against a completed multi-step workflow.
• Memory. Limited to this conversation, against persistent across steps and sessions.
• Tool use. Minimal or none, against web, code, files, email, APIs and databases.
• Autonomy. None — it waits at every step — against self-directing until the goal is met.
• Error handling. Reports the error and stops, against detecting the failure and adapting.
• Your involvement. Required at every step, against required at the start and at the checkpoints you set.
• Risk. Low, because you review every output before it goes anywhere — against higher, because actions happen before you see them.
• Typical instruction. "Summarise this article" against "Monitor my competitors and tell me weekly what changed."

Read the last two lines together, because they are the trade. Autonomy is not a feature you turn up for free. An agent can send email, spend money and change files, and it does those things before anyone has looked. Scope its permissions narrowly and put a human checkpoint in front of anything expensive or irreversible.

When a chatbot is still the right answer

Plenty of work should not be given to an agent. Single-step, well-defined tasks where you want to see the output before it counts: drafting an email, summarising a meeting, translating a document, answering a factual question, generating an image. Clear, bounded, low-risk, reviewed by you. Reaching for an agent there adds moving parts and buys nothing.

Agents earn their keep on work that is multi-step, repetitive or slow, where the path from goal to result needs many small decisions: research, data gathering and reporting, customer enquiries that arrive at 2am, anything you currently do the same way forty times a week. If you cannot name the repetitive job, you are not ready to build the agent — the Agent Idea Filter is five questions that settle it in about ten minutes.

What one agent looks like in one real business

The generic version: you tell an agent to research your five nearest competitors, compare their pricing, find the gaps and put it in a deck. A chatbot helps with each of those if you ask for each one separately. An agent searches, reads the pricing pages, compares, spots the pattern, drafts the analysis, builds the slides and comes back when it is done or genuinely stuck.

The version that actually pays for itself is smaller and duller. A restaurant gets forty WhatsApp messages an evening, most of them asking about the same four things and a few of them wanting a table. The agent reads each message, answers from the menu and the opening hours it has been given, takes the booking, writes it to the sheet the floor staff already use, and escalates anything unusual to a human with the conversation attached. Nobody is amazed by it. It just means no message waits until morning.

Both are the same loop. The difference is scope, and narrow scope is what survives contact with real customers. Written down properly, that scope becomes the agent's standing instruction — the 7-Part Job Description is the format we use for it, because "be helpful to customers" is not an instruction a machine can follow.

Where agents break, and how you find out

The loop fails in four recognisable ways, and knowing them is most of what separates people who ship agents from people who demo them:

• Bad planning. It picks the wrong sub-tasks and pursues them competently. The output looks confident and answers a question you did not ask.
• Unreliable tools. A search that returns noise or an API that half-works poisons every downstream step. Most "the AI is hallucinating" reports are really this.
• Misread observations. It treats a failure as a success and moves on. This one is expensive, because it fails quietly.
• Spinning. It loops without progress, burning tokens, re-trying a variation of the same doomed step.

All four are design problems, not model problems, and all four are why you give an agent a small job, watch it do that job on real traffic, and only then widen the remit. When one agent's remit genuinely outgrows one context window, the answer is usually to split it — that is the argument in multi-agent systems, and it is a later problem than most people think.

Why this became possible when it did

Nothing here is a new idea; the agent loop is decades old in the research literature. Four things arrived at once and made it practical. Models got good enough to plan coherently across many steps instead of two. Tool-use interfaces were standardised, so a model could reliably call an external function rather than being coaxed into printing something a script could parse. Storage for long-term memory became cheap and ordinary. And the framework layer — LangChain, AutoGen, CrewAI, LlamaIndex and the model vendors' own tool-use APIs — meant you no longer rebuilt the plumbing every time. Our guide to the five frameworks covers which is worth your time and when you need none of them.

What to learn next

If you take one thing from this page, take the four parts and the loop: reasoning, memory, tools, feedback, running round until the job is done. Everything marketed as agentic either has those or is a chat box wearing a costume.

The next step is smaller than it looks. Instructions come first, because an agent is only as clear as the brief it was given — start with writing effective prompts, then pick one repetitive job in one business and build for that. In DSP AI Agent Mastery that is the whole arc: one agent, built, given memory and tools, deployed to a live URL, and put in front of a real user.