AI Agents & Tool Use

A language model on its own does one thing: you give it text, it gives you text back. An AI agent is what you get when you wrap that model in a loop and give it tools — the ability to take actions in the world, observe what happens, and decide what to do next. The shift from answering a question to acting to accomplish a goal is the whole idea, and it's the frontier where most of the current excitement (and risk) in AI lives.

It's worth understanding properly because agentic tools are rapidly entering everyday workflows — and because the same things that make them powerful make them dangerous if used uncritically. This page builds the agent up from the loop, covers the pieces (tools, planning, memory), and is honest about the hard parts — drawing on the LLM, RL, and retrieval threads from this section.

From answering to acting

The defining leap is agency: an agent doesn't just produce a final answer in one shot, it pursues a goal over multiple steps, deciding its own actions along the way. Ask a plain LLM "what's the weather in Adelaide and should I bring an umbrella?" and it can only guess from stale training data. An agent calls a weather API, reads the result, and answers from real, current data — then maybe checks your calendar and drafts a reminder.

That autonomy is what unlocks genuinely useful work — research, automation, coding, operating software — but it also means the system is now doing things, not just saying things, which raises the stakes of every error. Understanding the loop is how you keep that power useful.

The reason-act-observe loop

The heart of nearly every agent is a simple cycle, popularised as ReAct (Reason + Act): the model reasons about what to do, takes an action (calls a tool), observes the result, and loops — reasoning again with the new information — until the goal is met.

The agent loop. The LLM reasons about the next step, acts by calling a tool, observes the result, and feeds that back in to reason again — repeating until the task is done. The model is the brain; the tools are the hands; the loop is what turns a single answer into a multi-step task.

This is what turns a one-shot text generator into something that can tackle a task it can't solve in a single response. Each turn of the loop, the model gets to see the consequences of its last action and adjust — exactly the feedback structure of the agent-environment loop from reinforcement learning, here driven by an LLM's reasoning rather than a learned policy.

Tool use: grounding the model in real capabilities

Tools are what give an agent its powers. Through function calling, the model is told what tools are available (a search engine, a calculator, a database query, a code interpreter, an email sender) and can choose to invoke one, with arguments it generates, instead of answering directly. The tool runs, and its output comes back into the model's context.

This solves the LLM's core weaknesses at a stroke. It can't do reliable arithmetic? Give it a calculator. Its knowledge is stale or it hallucinates? Give it search over real documents (this is RAG as a tool). It can't act in the world? Give it an API. Tools ground the fluent-but-unreliable model in capabilities that are exact, current, and real — which is why "what tools does it have?" matters as much as "which model is it?"

Planning & memory

Two further pieces turn a reactive loop into something that can handle real complexity:

Planning — for a multi-step goal, the agent first decomposes it into a sequence of sub-tasks ("to book this trip: find flights, then a hotel, then add to calendar") rather than improvising one step at a time. Better planning is much of what separates an agent that finishes a complex task from one that wanders.
Memory — the loop's working context is short-term memory (and it's bounded by the context window). For anything longer, agents need long-term memory — an external store (often a vector database) it can write to and retrieve from, so it can recall earlier findings without holding everything in context at once.

Multi-agent systems

A natural extension is to use several agents together, each specialised — a "researcher" agent that gathers information, a "writer" that drafts, a "critic" that checks — coordinating to solve a problem one generalist agent would struggle with. It mirrors how a human team divides labour, and the "critic" or "verifier" role is especially valuable because it builds checking into the system. It's a promising pattern, though it multiplies the cost and the coordination challenges, and isn't a free win.

Why it's hard — and must be bounded

Agents are powerful and genuinely unreliable, and the honesty here matters more than the hype:

Common pitfall

Errors compound. Each step has some chance of going wrong, and over a long chain those probabilities multiply — a 95%-reliable step is only ~60% reliable over ten steps. A small early mistake (a misread tool result, a wrong assumption) can send the whole run off the rails, and the agent may confidently pursue a broken plan. Add the inherited LLM problems — hallucination, the reward-hacking tendency to satisfy the letter of a goal not its intent — plus real cost and latency (every loop is another model call) and the fact that agents are hard to evaluate (success is fuzzy and multi-step). The conclusion is practical: agents must be bounded (limited tools, limited steps, permission gates on consequential actions) and verified, with a human in the loop for anything that matters. Autonomy is a dial, not a default.

Where it shows up in my work

Useful, with the guardrails on

Agentic tools are increasingly part of how I research and automate — an agent that can search, read, run code, and chain steps does real work a single prompt can't. The understanding that pays off is knowing it's an LLM in a loop with tools, so its power comes from the tools (grounding it in real, current capability) and its danger comes from compounding errors and inherited hallucination.

In an accountable government setting that makes the discipline non-negotiable: bound what it can do, verify what it produces, and keep a human in the loop for any consequential action — an autonomous agent acting on a confident mistake is exactly the failure mode to design against. It's the operating manual for the AI frontier this section has been building toward — and the same verify-don't-trust mindset that runs through the responsible-practice pages applies in full.

Refresh in 60 seconds

An agent = an LLM in a loop with tools — it acts toward a goal over multiple steps, not just answers once.
The core is the reason → act → observe loop (ReAct) — reason, call a tool, read the result, repeat until done.
Tools / function calling ground the model: calculator, search (RAG), database, code, APIs — fixing its stale-knowledge and can't-act weaknesses.
Planning (decompose the goal) and memory (short-term context + long-term external store) handle complexity. Multi-agent systems specialise and add a critic/verifier.
The hard part: errors compound over long chains, it can pursue a broken plan confidently, plus hallucination, cost/latency, and hard evaluation.
So bound it (limited tools/steps, permission gates) and verify with a human in the loop. Autonomy is a dial, not a default.

The ReAct loop, tool-use/function-calling, planning-and-memory architecture, and the error-compounding/verification cautions reflect current AI-agent references alongside hands-on use.