What an AI agent is, and how it decides what to do next

The definition, taken apart

Three parts have to be present before the word agent means anything. A model that can read a situation and choose. A set of tools it is permitted to call. And a loop that lets it call one, look at what came back, and choose again.

Remove any of the three and you have something else. A model with no tools is a chatbot: it can describe what should happen and cannot make it happen. A model with tools but no loop is a form with extra steps, because it gets one attempt and cannot react to what it found. Tools and a loop with no model is a workflow automation, which is frequently the right thing to build and should not be sold as an agent.

The word is applied loosely, so it is worth asking which of the three you are being shown. The demonstration looks much the same in every case. The maintenance, the risk and the price do not.

What a tool is, in practice

A tool is one specific capability, described in words the model can read, with defined inputs and a defined result. A capability, not a system.

That last one carries a rule easy to miss. WhatsApp Business API messaging runs on opt in, on templates approved in advance, and on a messaging window that closes after the customer's last reply, so an agent that can message customers is operating inside a platform's rules as well as yours.

Narrow descriptions produce good behaviour and broad ones produce surprises. A tool that runs any query against your database will eventually be called with a query nobody imagined, by a system with no way of knowing it was a bad idea.

• Find a customer by phone number and return their recent orders
• Check which delivery slots are free for a postcode on a given date
• Create a draft invoice with these line items, in draft state only
• Search the policy documents for passages relevant to a question
• Send a message using an approved template to a customer who has opted in

The loop, which is where the behaviour comes from

This is the part most explanations skip, and it is the part that accounts for everything people find surprising about agents.

A request arrives. The model sees the request, the conversation so far, and the list of tools it may call, each with a description of what it does. It picks one and supplies the arguments. The tool runs and returns a result. The result goes back to the model, which now knows something it did not know a moment ago, and decides again: call another tool, answer, or stop.

Everything follows from that. The agent can handle work where step two depends on what step one returned, which a fixed script cannot express unless somebody enumerated every path in advance. It can also loop for longer than you expected, reach for a tool you assumed it would never use, and finish early because it believed it had enough.

Why an agent is not a script, and what that costs you

A script was written by a person who decided the order in advance. You can read it and know what it will do. An agent decides the order while it runs, which is what lets it handle awkward cases and what makes it impossible to certify by reading.

So testing changes shape. You cannot check every path, because the paths are not enumerable. What you can do is collect real cases with known correct outcomes and rerun them whenever anything changes: the prompt, the model version, a tool description, or the data underneath. Build that set from actual traffic and keep the ugly ones. The message with three questions inside it. The one that switches language halfway through. The one where the customer is wrong about their own order number.

The second cost is visibility. If the log does not record which tools were called, with which arguments, and what each returned, then when something goes wrong you have a story rather than a record.

Four things to settle before one gets built

These are cheap to agree before a build and expensive afterwards, and not one of them is a technical question.

An instruction in a prompt is a request, not a permission. If the agent must never refund above a limit, the control is a tool that refuses amounts above that limit. Prompts are how you ask. Tools are how you decide.

• What it may read and what it may write, held as separate credentials rather than as an instruction
• Which actions require a person to confirm the exact change before it happens
• What gets logged and how long it is kept, so any single run can be reconstructed end to end
• Who reads a sample of runs every week, by name, indefinitely

Problems an agent makes worse rather than better

High volume work with an identical shape every time. An agent deliberates over each instance and a rule does not, so you are paying for judgement on a question that contains none, and you receive variability as a bonus.

Information that contradicts itself. An agent picks a version, acts on it, and leaves behind a record that looks authoritative. A chatbot in the same position only says the wrong thing, which is considerably easier to unwind.

Work where nobody can state what a correct outcome looks like. Testing requires a person willing to write down the right answer for a set of real cases, and without that you cannot tell drift from improvement. Every disagreement about the system then becomes an argument about impressions.

A fourth is worth naming because it is the most common of the four. If a well written rule would produce the same outcome, write the rule. Agents earn their complexity on work where the next step genuinely depends on what the last step returned, and nowhere else.

The fifth thing to settle, and who holds the loop afterwards

There is a fifth item for the list above, and it belongs first rather than fifth. Decide what the agent must never do alone, and write it down before anything is built. Money moving, a price being set, anything published in the business's name and any complaint that has turned serious all wait for human approval. Where the loop meets a situation nothing in its tool list covers, it should hand it to a person with the transcript attached rather than reason its way to a plausible action. An agent improvising around a missing tool is doing the one thing the loop makes it good at and the one thing nobody bought.

Ownership on an agent is more concrete than it sounds, because an agent is four things you can hold: the system prompt, the tool definitions, the credentials each tool uses, and the run traces. Kept in accounts under your own logins, you own the system and can hand the whole of it to another supplier or to your own developer. Kept inside somebody's product, what you own is a subscription, and the traces disappear when it lapses. The traces are the part people undervalue until the first time somebody asks why it did that.

Building one in-house is realistic for a business with a developer who will still be there next year, and the honest recommendation is to start with two read tools and one write tool rather than a fleet of specialists. Your own team holds the advantage that matters here, which is knowing which exception is real. Moiz Khan owns automation architecture at Wobble and decides what an agent may do without asking first. Wobble works from Karachi, bills month to month and carries 25 engagements across six countries.

Common questions

What is an AI agent in simple terms?

An AI agent is a program that uses a language model to decide what to do next, and a set of tools that let it actually do it. Ask it where an order is and it chooses a lookup tool, reads what comes back, and answers. The model is the judgement and the tools are the hands, and both have to be present for the word to mean anything.

What is the difference between an AI agent and automation?

A workflow automation runs steps in an order a person decided in advance, and you can read it to know exactly what it will do. An agent picks the order at the moment of running, based on what each step returns. That flexibility is the point of an agent, and it is also why you cannot certify one by reading it.

What are tools in an AI agent?

Individual capabilities the agent is permitted to use, each with a description, defined inputs and a defined result: look a customer up by phone number, check free delivery slots, create a draft invoice. Narrow, well described tools produce predictable behaviour. One broad tool that can run anything eventually gets called with something nobody imagined.

Why does an AI agent answer the same question differently on different days?

Because each step is a judgement rather than a rule, so the route through the tools can differ even when the input does not. That variability is the capability you bought. It also means quality has to be measured across a set of recorded cases rather than confirmed by trying it once and being impressed.

How do you test an AI agent?

With a stored set of real cases, each with the correct outcome written down by a person, rerun every time the prompt, the model, a tool description or the underlying data changes. Take the cases from actual traffic and keep the awkward ones, because a small set of difficult examples teaches you more than a large set of easy ones.

Do we need an agent, or would something simpler do?

Something simpler will do unless the next step genuinely depends on what the last step returned. If the work has one correct path, a workflow automation is cheaper, faster and readable. If the answer already exists in writing and nothing needs to change in a system, a chatbot over good content is enough.