What is an AI agent? Follow the next decision
Follow a support request to see how an AI agent chooses tools, uses their results and stops—and how that differs from a chatbot or fixed workflow.
An LLM-based AI agent uses a language model to choose actions towards a goal, observes their results and decides what to do next. The application runs the tools and enforces limits. A predefined workflow can use the same model without giving it that control over the next step.
A customer asks where a parcel went. The agent checks the order. If two orders match, it asks which one; if delivery records disagree, it investigates that conflict. Its next action depends on what it finds. It still needs permission before changing the order.
A fluent answer does not reveal who controlled the work behind it. A fixed program and an agent can both return “Your parcel is delayed.” To tell them apart, inspect what happened when the first lookup failed to settle the question.
Look for the decision, not the label#
This page concerns agents built around large language models, or LLMs. It is not a definition of every use of “agent” in computer science. Michael Albada’s introductory chapter treats goals, decisions and actions in a changing environment as the starting point. That is more useful than identifying an agent by a product name.
Anthropic’s architectural distinction asks whether code specifies the workflow or the model directs the actions as work unfolds. A workflow may still contain model calls and branches. An agent may still operate inside a workflow whose outer rules it cannot change. These are not mutually exclusive product categories.
For example, code can require a customer identity check before any order lookup, while the agent decides which permitted lookup would resolve the customer’s question. Choosing that next investigation is different from choosing whether the identity check applies.
Follow one request through the loop#
Consider this illustrative support task: an authenticated customer says, “The tracking page says delivered, but my parcel is missing.” The goal is to establish what the available records support and prepare an appropriate response. In this design, refunds and address changes are outside the agent’s permission.
First, identify the order. The model requests an order lookup through a provided tool. The application checks that the request concerns this customer’s records and returns two recent orders. The model cannot yet know which parcel the customer means, so it asks a clarifying question rather than selecting one arbitrarily.
Next, inspect the relevant record. Once the customer identifies the order, the agent requests its delivery events. The latest event says delivered. That is a statement in a record, not proof that the customer received the parcel.
Use the result to choose another action. The agent checks whether a delivery note is available. In this example, the tool returns no note. The agent now has a specific gap to report. It should not invent a neighbour’s address or keep repeating the same lookup.
Stop with the right outcome. Under this example’s policy, the agent prepares a response explaining the conflicting information and passes the unresolved case to a person. It has completed the permitted investigation, not solved the delivery problem or authorised a refund.
Change the first result and the route changes: one unambiguous order removes the clarification step; a useful delivery note gives the next investigation different evidence. This action-and-observation loop is the mechanism to understand. Retry and stopping rules explain how to prevent an investigation from continuing without progress.
Try it: change what the order lookup returns
- Lookup returns two orders.
- Ask the customer which order they mean.
- Only then inspect its delivery events.
The next action depends on the observation; choosing an order at random would invent evidence.
Illustrative support flow; no order service is contacted.
The model requests; the application acts#
A tool request is structured output from the model. For custom function tools, OpenAI documents the application executing the function and returning its result. Other platforms may host tool execution themselves. In either arrangement, software outside the model performs the operation.
That execution layer must not confuse a well-formed request with an authorised one. An order identifier can be valid in shape but belong to someone else. A requested operation can exist but be forbidden for this run. OWASP’s excessive-agency guidance separates unnecessary capabilities, excessive permissions and excessive autonomy.
The agent harness is where this becomes concrete: tool access, a working environment, limits and recorded results. A prompt saying “be careful” cannot replace a permission check.
What does not make a system an agent#
A chat interface. Chat describes how a person interacts with the system. It does not reveal whether the system answers once, follows a fixed sequence or chooses further actions.
Reading unstructured text. Summarising one supplied document can be one model call. The task does not necessarily need a continuing investigation. Choosing between code, model calls and agent steps starts with the decision the task actually requires.
Running in the background. A scheduled script can run without anyone watching. An agent can run while a caller waits for it. Starting work and choosing its next action are separate design choices.
Remembering something. Loading a saved preference can change a later answer without changing the model. Memory, retrieval and learning explain what each kind of update actually changes.
Choose the next question#
Start by naming the goal, the choices the model may make and the result that ends the task. Then decide what the application must enforce regardless of the model’s suggestion. When the next action is already known, an ordinary workflow may be sufficient.
If one agent has too much work, examine whether the task has a useful boundary for another agent. If the goal is software delivery, the factory introduction shows the larger process around coding, checking and accepting a change.
Questions people also ask
2 QUESTIONSDoes an AI agent need several different models?
No. One model can choose among several tools over successive calls. The number of model providers is separate from the number of independently managed agent tasks.
Can an agent be read-only?
Yes. An agent can choose searches, inspect their results and return findings without permission to change external records. Reading is still subject to access rules, and retrieved text is not automatically trustworthy.