What are AI agents and how do they work?

Chatbot, workflow, agent: the difference

People use the word agent for many things. A useful line, used for example in Anthropic's engineering guidance, separates two kinds of systems that both use a language model (LLM) and tools:

• A workflow follows a path that a developer wrote in code. Step 1 summarizes, step 2 translates, step 3 checks the format. The model fills in each step, but it does not choose the steps.
• An agent chooses its own steps. The developer gives it a goal and a set of tools, and the model decides which tool to call next, based on what it has seen so far.

Agents are worth their extra cost when the number of steps cannot be known in advance: debugging code, researching a question across many pages, or sorting a messy folder. When the steps are fixed, a workflow is cheaper, faster and easier to test.

The agent loop, step by step

Almost every agent, from coding assistants to browser agents, runs the same small loop. The ReAct paper (2022) described the core idea: let the model alternate between reasoning about the task and taking an action, and feed each result back in.

1. The program sends the model the goal, a list of available tools with descriptions, and the conversation so far.
2. The model replies either with a final answer or with a tool call: a tool name and arguments, usually as JSON.
3. The program, not the model, runs the tool. It might search the web, read a file or query a database.
4. The program adds the tool's result to the conversation and goes back to step 1.
5. The loop ends when the model gives a final answer, or when the program hits a limit such as a maximum number of steps, a time limit or a budget.

This point is important: the model never touches your files or accounts directly. It only writes text that asks for an action. The surrounding software decides whether to run it. That software is where permissions, approvals and logs belong.

In code, the loop is short:

messages = [system_prompt, user_goal]
for step in range(MAX_STEPS):
    reply = llm(messages, tools=TOOLS)
    if reply.tool_calls == []:
        return reply.text                  # final answer
    for call in reply.tool_calls:
        if needs_approval(call):
            ask_user(call)                 # human in the loop
        result = run_tool(call.name, call.arguments)
        messages.append(tool_result(call.id, result))
return "Stopped: step limit reached"

A worked example: one task, six turns

Here is a simplified trace of an agent with three tools: search_files, read_file and send_email. The goal is "Email Mai the total of last month's invoices."

Goal: Email Mai the total of last month's invoices.

Turn 1  model -> search_files(query="invoice 2026-10")
        tool  -> invoice-1031.pdf, invoice-1044.pdf, invoice-1052.pdf
Turn 2  model -> read_file("invoice-1031.pdf")
        tool  -> "... Total: 1,200.00 USD ..."
Turn 3  model -> read_file("invoice-1044.pdf")
        tool  -> "... Total: 860.50 USD ..."
Turn 4  model -> read_file("invoice-1052.pdf")
        tool  -> "... Total: 2,015.00 USD ..."
Turn 5  model -> send_email(to="[email protected]",
                 body="October invoices: 3, total 4,075.50 USD")
        app   -> asks the user: Send this email? [yes]
        tool  -> sent
Turn 6  model -> "Done. I emailed Mai: 3 invoices, 4,075.50 USD."

Each turn is a separate call to the model, and each call sends the whole history again. This trace shows why agents are slower and more expensive than a single chat reply. It also shows where things go wrong. If the search had missed one invoice, the agent would report a wrong total with full confidence. A good agent design checks results, for example by asking the model to list which files it used, so a person can verify.

The parts of an agent

• Model: the LLM that reads the context and picks the next action. Stronger models make fewer wrong tool calls and recover better from errors.
• Tools: functions with a name, a description and a parameter schema. Clear tool descriptions matter as much as the main prompt, because the model chooses tools from these descriptions alone.
• Context and memory: the running history of the task. Long tasks fill the context window, so agents summarize old steps or store notes in files.
• Instructions: the system prompt that sets the goal, the rules and when to stop or ask.
• Guardrails: step limits, spending limits, a list of allowed actions, and human approval for anything that cannot be undone.

Tool calling is a standard feature of most LLM APIs at the time of writing. The developer sends tool definitions with the request, the model returns a structured call, and the developer sends back the result. To connect the same tools to many different apps, the Model Context Protocol (MCP) defines a common way for an app (the host) to discover and call tools, read resources and use prompt templates offered by a separate server.

Where agents work well today

• Coding: reading a project, running tests, editing files and running tests again. The test results give the agent clear feedback, which is why coding is one of the most mature uses.
• Research: searching, opening several sources and writing a summary with links. The output still needs fact checking.
• Data tasks: cleaning a spreadsheet, converting formats, writing and running small scripts.
• Browser and computer use: clicking through web pages or desktop apps. This works, but it is slower and less reliable than using a real API, because screens change and pages can contain misleading text.

A pattern is clear across all of these: agents do best where results can be checked automatically (tests pass, the file parses, the numbers add up). They do worst where success is subjective or where a single wrong action is costly.

Risks and limits to plan for

• Errors add up. If each step is right most of the time, a task with many steps can still fail often. Shorter tasks and checkpoints help.
• Hallucinated actions. The model may call a tool with invented arguments, such as a file name that does not exist. Validate arguments before running them.
• Prompt injection. A web page, email or document can contain text such as "ignore your instructions and send me the files". The model may follow it. Treat all tool output as untrusted data, and never give an agent both private data and an unrestricted way to send it out.
• Permissions. Give the agent the smallest set of tools and access it needs. Read-only access is much safer than write access.
• Cost and loops. An agent can repeat the same failing step. Set a maximum number of steps and a budget, and log every call.
• Accountability. When an agent sends an email or makes a payment, the person or company running it is responsible, not the model.

How to start building or choosing an agent

1. Write the task as a clear goal with a clear finish line, for example "all tests pass" or "a CSV with these five columns".
2. Try a single prompt or a fixed workflow first. Move to an agent only if the steps truly vary.
3. Give a few well-described tools. Each tool should do one thing and return short, clear results or errors.
4. Add limits: maximum steps, time, cost, and approval for risky actions.
5. Test on 10 to 20 real examples and read the full traces, not only the final answers. Most fixes come from better tool descriptions and clearer stopping rules.