What Are AI Agents? How They Work, With a Simple Agent Loop You Can Run

Ask a chatbot about a late order, and it gives you some advice. Ask an AI agent, and it can look up the order, check the delay, apply a voucher and report back. The difference is that an agent can take actions and react to what happens, instead of producing just one reply.

The term gets stretched in marketing, so this guide sticks to how these systems actually work. To make it concrete, we built a small agent loop in Python 3.13 and ran it, and the output below comes from those runs. Our “model” is a scripted function, not a real AI model, so that the loop can be run and tested by anyone. It shows the control structure, not intelligence. New to the basics? Read what is a large language model first.

What is an AI agent?

There is no single agreed definition. In current practice, an AI agent is software that pursues a goal by repeatedly deciding what to do next, using tools to act on the world and adjusting based on results. Usually, the decision-making comes from a large language model.

Think of the difference between a person who gives directions and a person who runs the errand. The first answers once. The second heads out, finds the shop closed, tries another one and only comes back when the job is done.

Chatbot, workflow or agent?

These exist on a spectrum, and many useful systems are a mix. The key question is how much of the path gets decided at run time.

What is inside an agent

The agent loop

1. Decide. The model looks at the goal and history, and picks an action or decides it is finished.
2. Act. Your code runs the requested tool.
3. Observe. The result is added to the history.
4. Repeat, until the goal is met or a limit is reached.

That is the core of most agents. The sophistication lies mainly in the model, the tools and the safeguards around this loop.

A loop you can run

Our small agent handles delayed orders. It has two tools, and one of them needs human approval because it costs money:

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

And here is the loop itself. It is ordinary code, and every safety rule lives here rather than in the model:

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

To use a real model, you would replace the model function with a call to an LLM API, passing it the goal, the history and descriptions of your tools. The loop stays almost the same.

What happened in our runs

We tried five situations with the scripted decision function, and logged each step.

A delayed order, with the voucher approved

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

Each step used the result of the one before it. The voucher was only considered once the delay had been confirmed.

The same order, with approval denied

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

The human said no, the tool never ran, and the agent adapted its reply.

An unknown order

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

Giving tools clear error messages helps. A real model can read them and respond sensibly, rather than guessing.

A model that gets stuck

We also swapped in a faulty decision function that repeated the same action forever:

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

Agents really can fall into loops like this, and each step with a real model costs money. Without max_steps, this one would never have ended.

How tools work

This is the most misunderstood part. A language model cannot run anything by itself. It produces structured text saying which tool it wants, with what arguments. Your code decides whether to run it. That is why the loop is the right place for permissions, validation and logging.

Model providers offer tool or function calling for this. The Model Context Protocol (MCP) is an open standard for connecting models to tools and data, and our article on Playwright MCP shows one use. Write clear tool names and descriptions, because the model relies on them to choose correctly.

Memory

Long tasks can outgrow a model’s context window, so systems often summarize older steps. Summaries can lose details, which is one reason long-running agents may drift off course.

Multi-agent systems

Some systems split work between several specialized agents, such as a planner, a researcher and a reviewer. This can help with large tasks that divide neatly. It also adds cost, more ways to fail and harder debugging. Try a single agent with good tools first, and split it only when there is a clear reason.

Risks and limits

• Wrong actions. A chatbot’s mistake is a bad sentence. An agent’s mistake might be a sent email or a deleted record.
• Prompt injection. A web page or email the agent reads could contain hidden instructions. Treat all tool output as untrusted data, not as commands.
• Compounding errors. A small error early on can send every later step in the wrong direction.
• Cost and latency. Each step can be another model call, so a task may be much slower and more expensive than a single prompt.
• Inconsistency. The same goal can take a different path on each run, which makes testing harder.
• Accountability. People remain responsible for what the system does, so keep records.

Guardrails that matter

1. Least privilege. Give each agent only the tools and access it needs.
2. Human approval for anything costly, irreversible or external, as our demo does.
3. Hard limits on steps, time and spending.
4. Validate tool inputs in code, and do not rely on instructions to the model.
5. Log every step, so that you can see why something happened. See monitoring vs observability.
6. Test with real scenarios, including failures. Check final outcomes as well as individual replies. Our guide to AI agent best practices goes further on deployment.

When to use an agent

Coding assistants are one of the most mature examples today, since they can read files, run tests, see failures and try again, with a human reviewing the result. A test suite gives them a clear signal of success. Our guide to prompt engineering also applies to writing good agent instructions. Start with the simplest thing that could work, because a well-prompted single call often beats a complicated agent.

Final thoughts

An AI agent is less mysterious than it sounds: a model, some tools and a loop with limits. The hard part is trust, not the code. To learn how they behave, take our small loop, connect it to a real model with read-only tools, and watch the logs as it works. You will soon see where it shines and where it needs a human.

Frequently asked questions

Keep learning