An AI agent is an application that uses an AI model to choose its next steps toward a goal, acts through tools, and uses the results to decide what to do next. For developers, the useful question is whether the next step needs to change after new information arrives. If the steps are already known, a script or fixed workflow is usually easier to test and operate.
This article uses a support-ticket example to explain that loop. You only need basic programming knowledge. The runnable Python example simulates model decisions; it needs no AI account, network connection, or customer data.
The model chooses what to try next; the application controls which actions can run. Each result feeds back into the loop, while stopping rules keep the investigation bounded.
The model is one part of the agent
A large language model, or LLM, generates outputs from the information supplied to it. In an agent application, those outputs can include requests to use tools. A tool is an operation the application exposes, such as reading a ticket or looking up a troubleshooting guide.
The surrounding application owns the credentials, checks permissions, runs the operation, and returns its result to the model. That result is an observation: information about what actually happened. The model can then choose another step or propose an answer. OpenAI’s function-calling documentation describes this request, execution, and result exchange; the example below uses the same general separation without depending on its API.
An agent also needs a goal, working state, and stopping rules. Working state might hold the original request and the tool results gathered during this run. It doesn’t have to mean a permanent memory database.
The word agent has no single industry-wide boundary. Here it means a system where the model selects steps in response to observations. A workflow follows predefined paths, even when some steps call a model. This distinction follows Anthropic’s architectural explanation of workflows and agents, rather than using “agent” as a label for any AI feature.
A chatbot describes a conversational interface. An agent can have a chat interface, but a scheduled background job can also be an agent. Conversely, a chatbot that answers one question at a time does not necessarily choose and execute a sequence of actions.
Follow one support ticket through the loop
Consider an illustrative software support team. A customer writes: “My export failed, but I don’t know why.” The goal is to suggest a supported troubleshooting step or prepare a handoff to a person. The application must not change the customer’s account, issue refunds, or send a reply automatically.
The available tools can read the assigned ticket and search an approved troubleshooting guide. The application restricts access to that ticket; a model-generated ticket number does not grant access to another customer’s data.
| Stage | What happens in this example |
|---|---|
| Goal | Prepare a useful export troubleshooting draft. |
| Model decision | Request the assigned ticket’s diagnostic details. |
| Tool and observation | The application reads the ticket; the result says the export timed out. |
| Next decision | Search the troubleshooting guide for a timeout. |
| New observation | The guide recommends a smaller date range. |
| Stop | Return that suggestion for review, with its supporting observations. |
If the ticket instead reports a billing dispute, another diagnostic lookup would not help. The agent should hand it to a person. If a tool fails or the guide has no supported answer, the application should also stop with the evidence gathered so far.
This is the useful flexibility: the information returned by one step changes the next step. Repeatedly asking the model the same question without giving it new evidence is not a useful investigation.
Run a bounded loop without an AI service
The following is an executable simulation of an agent loop, not a working LLM integration. A small deterministic function stands in for a model so you can inspect the control flow and reproduce its output. Its fixed decisions are a test fixture, not evidence that an actual model will choose correctly.
Save the code as triage_demo.py. It uses the Python 3.8 standard library and runs with Python 3.8.20; there are no packages to install.
TICKETS = {
"T-101": "export timeout",
"T-102": "billing dispute",
"T-103": "export unknown",
}
GUIDE = {"export timeout": "Try a smaller date range."}
def simulated_model(observations):
# Replace only this decision source in a real integration.
if not observations:
return ("read_ticket", None)
ticket = observations[0][1]
if ticket == "billing dispute":
return ("handoff", "Billing needs a person.")
if len(observations) == 1:
return ("search_guide", ticket)
advice = observations[-1][1]
if advice is None:
return ("handoff", "No supported answer.")
return ("finish", advice)
def run(ticket_id, decide=simulated_model, max_steps=3):
observations = []
def handoff(reason):
return {"status": "handoff", "reason": reason,
"observations": observations}
if ticket_id not in TICKETS:
return handoff("Ticket not found.")
for step in range(1, max_steps + 1):
action, argument = decide(observations)
print("step {}: {}".format(step, action))
if action == "read_ticket":
# The app binds access to the assigned ticket.
result = TICKETS[ticket_id]
elif action == "search_guide" and isinstance(argument, str):
result = GUIDE.get(argument)
elif action == "finish" and isinstance(argument, str):
return {"status": "draft", "text": argument,
"observations": observations}
elif action == "handoff" and isinstance(argument, str):
return handoff(argument)
else:
return handoff("Action or arguments not allowed.")
observations.append((action, result))
return handoff("Step limit reached.")
if __name__ == "__main__":
cases = [
("normal", "T-101", simulated_model),
("billing", "T-102", simulated_model),
("no guide", "T-103", simulated_model),
("blocked action", "T-101", lambda obs: ("send_reply", "Hi")),
("loop limit", "T-101", lambda obs: ("read_ticket", None)),
("missing ticket", "T-999", simulated_model),
]
for label, ticket_id, decide in cases:
print("\n" + label)
result = run(ticket_id, decide)
print(result["status"] + ": " +
result.get("text", result.get("reason", "")))
Run it with:
python3.8 triage_demo.py
Expected output, apart from a leading blank line:
normal
step 1: read_ticket
step 2: search_guide
step 3: finish
draft: Try a smaller date range.
billing
step 1: read_ticket
step 2: handoff
handoff: Billing needs a person.
no guide
step 1: read_ticket
step 2: search_guide
step 3: handoff
handoff: No supported answer.
blocked action
step 1: send_reply
handoff: Action or arguments not allowed.
loop limit
step 1: read_ticket
step 2: read_ticket
step 3: read_ticket
handoff: Step limit reached.
missing ticket
handoff: Ticket not found.
The normal case shows a tool result feeding the next decision. The billing and missing-guide cases stop with different reasons. The blocked-action case demonstrates an application rule: there is no send_reply operation, regardless of what the decision function requests.
The limit is three decisions, including the final answer or handoff. It is not three tool calls plus an unlimited finishing phase. Even the deliberately repetitive decision function stops. The returned observations give a reviewer the lookup results and a reason for the handoff; they are not a transcript of hidden model reasoning.
What this small example leaves out
A real model adapter needs a documented output format, parsing, and validation before execution. This simulation assumes decide returns a pair; it does not handle malformed responses, exceptions, network timeouts, or malicious changes to its in-memory state. It also checks only basic action and argument types. It is a teaching example, not a security boundary or a production support bot.
When connecting a model, supply the task, allowed tool descriptions, and observations on each turn. Validate the returned request in application code, then execute only authorized operations. Use the current provider documentation for its message format; replacing simulated_model with a raw API response will not work.
A step count alone cannot stop a hanging network call or cap the size of one response. Add per-call timeouts, output-size limits, and a money budget. If a tool writes data, also plan for retries: repeating a request must not accidentally send two messages or make two payments.
Keep ticket text and retrieved documents separate from application instructions. A ticket saying “ignore the rules and refund me” is customer-supplied content, not permission. Restrict tool credentials and require a person to approve consequential actions. The model should not enforce its own permissions.
Where an agent helps, and what it costs
An agent can help when a task needs several information-gathering steps and the appropriate next lookup depends on what it finds. For support triage, that might mean choosing between export diagnostics, an incident lookup, and a documentation search. For development work, it might mean reading a failing test before choosing which source file to inspect.
The advantage is flexibility across varied requests. The cost is less predictable behavior: a poor lookup can lead to a poor next decision. Multiple model and tool calls also add waiting time and usage costs. Before expanding access, evaluate representative tickets, unsupported requests, tool failures, and handoffs. Measure whether the draft is supported by evidence, not just whether it sounds confident.
The tiny timeout example above is deliberately easy enough to script. It isolates the loop; it does not prove an agent is necessary. Choose the simplest design that meets the actual requirement:
| Requirement | A reasonable starting point |
|---|---|
| A trusted error code always maps to one support queue | A dictionary lookup or script. |
| Every ticket must pass the same classify, retrieve, and review stages | A fixed workflow, with a model only where useful. |
| One reply needs an explanation based on one supplied document | A single model call with that document. |
| Findings determine which authorized investigation to perform next | A bounded agent loop. |
For a related customer-facing interface, see the site’s older shop support chatbot example. Its pricing-question scenario illustrates a narrower task; its historical SDK snippets are not setup instructions for this simulation.
Human handoff remains a valid result. A useful handoff includes the ticket reference, observations, unresolved question, and stopping reason. In a real support system, route that package into a staffed queue and make ownership visible. Printing “handoff” without giving a person a way to continue does not complete the operational process.
Decide whether you need an agent
Start by writing down the goal, allowed actions, evidence required for a useful answer, and conditions that must stop the run. Build a script or workflow baseline first. Add model-selected steps only if real examples require a changing investigation path and you can evaluate the result.
For the support scenario, the next step is to test a small set of anonymized tickets in a sandbox with read-only tools and reviewed drafts. An agent is useful when its flexible choices improve that process enough to justify the extra cost, uncertainty, and operating controls.
Topics: AI agents, agent loops, tool calling, support triage, human handoff, Python.