AI agents and tool use

An AI agent is a system that uses a language model to decide what actions to take, executes those actions, observes the results, and iterates until a goal is achieved. The key distinction from a simple LLM call is the loop: an agent reasons about what to do next based on what has happened so far, rather than producing a single response.

This loop creates both the power and the risk of agents. The power is autonomy: an agent can break a complex task into steps, use tools to gather information, and adapt its approach when something fails. The risk is compounding errors: each step in the loop can introduce mistakes that propagate through subsequent steps, and the agent may not recognise when it has gone off track.

The ReAct (Reason + Act) pattern, introduced by Yao et al. in 2022, interleaves reasoning traces with actions. At each step, the model produces a Thought (explaining its reasoning), an Action (a tool call or API request), and an Observation (the result of that action). The next thought incorporates the observation, creating a grounded reasoning chain.

ReAct outperforms pure chain-of-thought prompting on tasks requiring external information because the reasoning is anchored to real data rather than the model's training distribution. When a ReAct agent needs to know today's weather, it calls a weather API rather than guessing from training data. When it needs to verify a fact, it searches rather than hallucinating.

The limitation is that ReAct agents are only as good as their available tools. An agent with access to a calculator, a web search API, and a code interpreter can solve problems that require all three. An agent with only web search cannot reliably perform calculations, no matter how sophisticated its reasoning.

Function calling is the mechanism that enables LLMs to use structured tools. Instead of generating free-text that a parser must interpret, the model outputs a structured JSON object specifying which function to call and with what arguments. The runtime executes the function and returns the result to the model as a new message.

The quality of an agent depends heavily on schema design. Each tool must have a clear name, a precise description of what it does and when to use it, well-typed parameters with descriptions, and explicit error formats. Ambiguous tool descriptions cause the model to select the wrong tool; missing parameter descriptions cause it to pass incorrect arguments.

The Model Context Protocol (MCP), an open standard for connecting AI models to external tools, standardises this interface. MCP defines a client-server architecture where the model (client) discovers available tools, reads their schemas, and invokes them through a consistent protocol. This means a single agent can use tools from multiple providers without custom integration code for each one.

Multi-agent systems use multiple specialised agents that communicate and coordinate to solve problems that exceed the capability of any single agent. A coding agent might work alongside a testing agent and a deployment agent, each with its own tools and system prompt.

The key design decision is orchestration: how do agents communicate, who decides what happens next, and how are conflicts resolved? Two patterns dominate. Orchestrator-worker uses a central agent that decomposes tasks and delegates to specialised workers. This is simpler to debug but creates a single point of failure. Peer-to-peer allows agents to communicate directly, enabling more flexible collaboration but making the system harder to reason about.

Multi-agent complexity is justified only when the task genuinely requires different capabilities that cannot be provided through tools alone. A single agent with a code interpreter, a web browser, and a file system can handle most tasks. Adding a second agent is warranted when the task requires fundamentally different reasoning strategies (e.g., adversarial red-teaming alongside cooperative problem-solving) or when the context window of a single agent cannot hold all necessary information.