AI Agents Explained: When an LLM Gets to Use Tools

Quick Answer

An AI agent is a large language model running in a loop: you give it a goal and a set of tools, and on each turn it either calls a tool or declares it is done. Your code runs the tool, feeds the result back, and the model takes another turn. This reason-act-observe cycle lets it break a task into steps, gather information it did not start with, and correct course. The cost is control - agents can loop, wander, or run up a bill without a firm stop condition.

Agent versus single call

A plain API call is one round trip: prompt in, answer out. It cannot look anything up, run code, or check its work - it responds from training plus whatever you put in the prompt. Ask it "how many open issues are in our repo" and it cannot answer.

An agent adds a loop and tools. Give it a list_issues tool and the goal, and it calls the tool, reads the JSON, counts, and replies. The model is identical; the wrapper around it is what makes it an agent. Use an agent only when the task genuinely needs several steps you cannot script in advance - if you already know the exact sequence of calls, write that sequence as ordinary code. It will be faster, cheaper, and easier to debug than letting the model decide each step.

The reason-act-observe loop

Each turn: the model receives the conversation so far and the tool list, and outputs either a final answer or one or more tool calls. Your code detects a tool call - the response comes back with a "tool use" stop reason - executes the real function, and appends the result to the message history as a tool-result message. Then you call the model again. It observes the result and decides the next move.

This repeats - sometimes twice, sometimes twenty times - until the model returns a plain answer or you hit a limit you set. The pattern is often called ReAct (reason plus act). Models are measurably better at multi-step tasks run this way than when asked to plan everything up front, because a real tool result corrects a wrong assumption immediately instead of letting it compound through an imagined plan.

How tools are defined

A tool is a name, a description, and a JSON Schema for its inputs. The description is a prompt - it is how the model decides when to reach for the tool - so write it like documentation, including when not to use it.

{
  "name": "get_order_status",
  "description": "Look up the current status of a customer order by its ID. Use when the user asks where their order is.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "The order ID, e.g. ORD-4821" }
    },
    "required": ["order_id"]
  }
}

The example above is Anthropic's shape. OpenAI calls the schema parameters instead of input_schema and, in its Chat Completions API, nests it under a function key - but it is the same three pieces: name, description, typed inputs. The model never runs anything. It returns a structured call - name plus arguments - and your code executes the real function and hands back the result as a tool-result message. Note that OpenAI returns the arguments as a JSON string you must parse, while Anthropic returns them as a ready-made object.

A minimal agent loop

Stripped of frameworks, the whole thing is a loop with a hard cap. This is pseudocode, but every mainstream SDK maps onto it almost line for line:

messages = [ system_prompt, user_goal ]
for step in range(MAX_STEPS):
    reply = model.create(messages, tools=TOOLS)
    messages.append(reply)
    if reply.stop_reason != "tool_use":
        return reply.text            # model gave a plain answer: done
    for call in reply.tool_calls:
        result = run_tool(call.name, call.input)   # your code runs it
        messages.append(tool_result(call.id, result))
# fell out of the loop: hit the step cap without finishing
return "gave up after MAX_STEPS"

The two things that make it an agent rather than a chatbot are on lines 3 and 8: the model is handed a tool list, and its output is fed back in so it can react to what happened. Everything a framework adds - retries, structured logging, running parallel tool calls concurrently, human approval prompts, history compaction, tracing - hangs off this skeleton. If you understand these ten lines you can read what any agent library is doing under the marketing.

Context is the real constraint

Every turn resends the whole history - the system prompt, the goal, every tool call, and every tool result so far. A tool that returns a 5,000-line log dumps all of it into the context, and it stays there for the rest of the run, resent every turn and billed every turn.

Long agent runs hit the context window and get slow and expensive well before they hit any logical limit. Practical responses: have tools return summaries rather than raw dumps; cap how much of a result you feed back; and for long tasks, periodically compact the history into a short state summary. An agent's effectiveness degrades as its context fills with old, low-value tool output - it starts losing track of the original goal.

Where agents go wrong

• No stop condition. Without a hard cap on iterations, a confused agent loops - call a tool, dislike the result, call it again, forever, spending money each turn. Always set a maximum step count.
• Compounding errors. A wrong value in step 2 gets treated as fact in steps 3 through 10. Single mistakes propagate through the rest of the run.
• Not knowing it is done. Agents sometimes keep "improving" a finished answer, or stop with the task half done. A clear definition of done in the system prompt helps.
• Unsafe tools. The model can call any tool you give it with any arguments it generates. A delete_file or send_email tool will eventually be called with inputs you did not expect - gate destructive actions behind a confirmation step.
• Hallucinated calls. The model can invent a tool name you never defined or supply arguments the user never gave. Validate every call against the schema before executing, and return a clear error instead of crashing.

Frequently Asked Questions