AI Agents and Tool Use

From chatbot to agent

A chatbot answers. An agent gets things done: it reads your repository, runs the tests, notices a failure, edits a file and runs the tests again, all from one sentence of instruction. The model inside is the same kind of language model. What changed is what we wrap around it.

What is an agent?

An AI agent is a language model placed in a loop where it can take actions, see their results and decide what to do next, until it judges the goal is met. Anthropic’s engineering team draws a useful line: in a workflow, your code decides the sequence of model calls and tools; in an agent, the model decides.

Four ingredients turn a chatbot into an agent:

• A model that can reason about what to do next and express it in a structured form.
• Tools: functions the model may call, such as search, a code interpreter, a database or a web browser.
• A loop: call the model, run the tool it asked for, append the result, call the model again.
• Memory: the growing transcript in the context window, and often a longer-term store it can write to and read from.

How does it work?

The loop itself is a few lines of ordinary code. Send the conversation to the model along with a list of available tools. If the reply contains a tool call, run that function, append its output to the conversation and send everything again. If the reply is a plain answer, stop. Everything clever happens inside the model’s choice of the next action; everything dangerous happens in the tools you let it call.

messages = [goal]
while True: reply = model(messages, tools) if reply.tool_call is None: return reply.text # done result = run(reply.tool_call) # your code acts messages += [reply, result] # model sees what happened

The core of almost every agent framework, in pseudocode.

Why does it matter?

Language models are frozen snapshots that cannot see today’s data, cannot do exact arithmetic reliably and cannot change anything in the world. Tools fix all three. By 2025 the loop had moved from research demos into products people use daily: coding agents that open pull requests, research agents that read dozens of sources before writing a report, and assistants that operate a browser. The hard part stopped being “can the model do a step?” and became “can it do fifty steps in a row without going off the rails?”. That question runs through the rest of this lesson.

Key takeaways

• An agent is a model in a loop: it chooses an action, your code runs it, and the result becomes the next input.
• Model + tools + loop + memory. The loop is simple code; the judgement lives in the model; the risk lives in the tools.
• Workflows fix the sequence in code. Agents let the model choose it. Pick the least autonomy that solves the problem.

Reason, act, observe

In 2022 a team from Princeton and Google showed that the simplest possible agent recipe works surprisingly well: let the model think out loud, take an action, read the result, and think again.

What is ReAct?

ReAct (Reason + Act) prompts a model to produce an interleaved trace of Thought, Action and Observation lines. Thoughts are free-form reasoning (“I need the distance first”). Actions are tool calls in a fixed format. Observations are the tools’ outputs, pasted back in by the harness. The model only ever writes Thoughts and Actions; the Observations come from the world.

With one or two worked examples in the prompt, ReAct beat imitation and reinforcement learning baselines on the ALFWorld text game and the WebShop shopping task by 34 and 10 absolute percentage points of success rate. On question answering it reduced hallucination by grounding answers in retrieved Wikipedia text rather than in the model’s memory.

How does it work?

The thought step lets the model decompose the task and keep track of progress. The action step reaches out for information it does not have. The observation step is the crucial one: the next thought is conditioned on real evidence, so the model can notice a failed search and try different words, or notice that a number is in seconds when the user asked for minutes.

Modern models do this without the literal “Thought:” text. APIs return structured tool calls, and reasoning models do much of their thinking in hidden reasoning tokens. The shape of the loop is unchanged.

Notice two things. First, the arithmetic is never done “in the head”: dividing 227,900,000 by 299,792.458 is exactly the kind of step where language models make small slips, and a calculator costs nothing. Second, the context counter keeps climbing. Every observation is pasted back in, so long agent runs are expensive and eventually hit the context limit, which is why memory management becomes its own topic.

Teaching models to call tools

ReAct used prompting alone. Toolformer (Meta, 2023) went further, letting a model annotate its own training text with API calls and keeping only the calls that made the following text easier to predict. Today’s frontier models are trained heavily on tool-use trajectories, often with reinforcement learning on tasks where success can be checked automatically, such as passing unit tests.

Key takeaways

• ReAct interleaves Thought, Action and Observation. The model writes the first two; the world supplies the third.
• Observations let the model recover: a failed search or a wrong unit shows up in the next step, where it can be fixed.
• Offload exact work (maths, lookups, dates) to tools. The cost is context: every observation stays in the prompt.

Function calling and MCP

A model cannot press a button. It can only write text. Function calling is the contract that turns a particular kind of text into an action your code is willing to run.

What is function calling?

You describe each tool with a name, a natural-language description and a JSON Schema for its arguments. The model is trained to reply with a structured call such as {"name": "convert_units", "input": {…}} when a tool would help. Your code parses it, checks it, runs the function and sends back a tool result. The major model APIs all use this shape, with small differences in field names.

How does it work in practice?

The description is a prompt. The model decides whether and how to call a tool almost entirely from the name, the description and the parameter descriptions, so these deserve the same care as documentation for a new colleague. Enums prevent invented values; required fields prevent half-formed calls; clear error messages let the model repair a bad call on its next turn. Some APIs can also constrain generation so the output is guaranteed to match the schema.

Every failure mode shown here happens in production: numbers sent as strings, invented enum values, extra arguments and tools that do not exist. The fix is not to trust the model more, but to validate at the boundary and hand back an error it can act on.

The Model Context Protocol

If every app defines tools in its own way, every integration is written N times. Anthropic released the Model Context Protocol (MCP) in November 2024 as an open standard: write a GitHub or database integration once as an MCP server, and any MCP-capable host can use it. Servers expose three kinds of things: tools the model can call, resources (data the application can pull into context) and prompts (reusable templates). Messages are JSON-RPC, carried over standard input/output for local servers or HTTP for remote ones.

Adoption was fast. Within a year the maintainers reported over 97 million monthly SDK downloads and around 10,000 active servers, with client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and VS Code. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a new Linux Foundation fund co-founded with Block and OpenAI, so the protocol is now governed as neutral open infrastructure.

Key takeaways

• A tool is a name, a description and a JSON Schema. The model writes a structured call; your code decides whether to run it.
• Validate every call at the boundary and return precise errors. Good descriptions and enums prevent most bad calls.
• MCP standardises tools, resources and prompts across apps. Since December 2025 it is governed by the Linux Foundation’s Agentic AI Foundation.

Planning, reflection and memory

A ReAct loop is greedy: it only ever thinks one step ahead. For longer tasks, agents need to plan, to learn from their own mistakes and to remember what matters beyond the current context window.

What is planning?

Planning means writing down the steps before taking them. A plan-and-execute agent first produces a list (“1. find the failing test, 2. read the function it covers, 3. …”), then works through it, revising the list when an observation invalidates it. Coding agents commonly keep a visible to-do list for exactly this reason: it survives when the detailed history gets long, and it tells the user what the agent intends to do next.

Reasoning models, trained to think at length before answering, made planning much stronger in 2024 and 2025. They are better at decomposing a problem and at noticing that an early step was wrong, which matters more for agents than for chat.

How does reflection help?

Reflexion (Shinn et al., 2023) asks the agent to write a short verbal critique after a failed attempt (“I assumed the list was sorted; it was not”) and keeps those notes for the next attempt. No weights change; the lesson lives in the prompt. On the HumanEval coding benchmark this lifted pass@1 to 91%, against 80% for GPT-4 on its own at the time. The general pattern, generate, evaluate, revise, is one of the most reliable ways to buy quality with extra compute, provided the evaluation signal is trustworthy. Unit tests are; a model grading its own essay is less so.

Short-term and long-term memory

Generative Agents (Park et al., 2023), which simulated 25 characters living in a small town, gave a clear recipe for retrieval. Every memory gets a score that adds three normalised terms: how recent it is (decaying by a factor of 0.995 per hour), how important the model rated it on a 1 to 10 scale when it was stored, and how relevant it is to the current situation (embedding similarity). The top-scoring memories go into the prompt.

Each term is min-max normalised to [0, 1] across memories. The paper used equal weights of 1.

With the paper’s equal weights, the dinner request retrieves the recent pasta chat and the satay memory, and the months-old allergy just misses the cut. Turn importance up and it comes back. This is how real assistants fail: not by forgetting, but by failing to retrieve. Embeddings and Retrieval covers the retrieval half of this problem in depth.

Key takeaways

• Planning writes steps down before acting and revises them as observations arrive; it keeps long tasks on track.
• Reflection turns failures into written lessons for the next attempt. It works best when a trustworthy check says what failed.
• Short-term memory is the context window; long-term memory is a store plus retrieval. A memory that is not retrieved does not exist.

Coding, browsing and teams of agents

Agents stopped being demos in 2025. The clearest successes share a trait: an environment where actions are cheap to try and results are easy to check.

What are coding agents?

Coding agents such as Claude Code, OpenAI’s Codex and GitHub Copilot’s agent mode are ReAct loops whose tools are a shell, a file editor and search over a codebase. Software suits agents unusually well: the environment is text, actions are reversible with version control, and tests give an objective signal after each change. A typical run reads the relevant files, forms a plan, edits, runs the tests, reads the failures and edits again.

How do computer-use and browser agents work?

A computer-use agent sees the screen as a screenshot and acts with mouse and keyboard commands: “click at (412, 230)”, “type ‘quarterly report’”. Anthropic released computer use as a public beta in October 2024, and OpenAI followed with its Operator browser agent in January 2025. This is the most general interface imaginable, because any software built for humans becomes a tool, and the most fragile, because pixels are ambiguous, pages change and one misclick can submit a form. It depends on strong multimodal perception to read the screen.

Why use more than one agent?

A multi-agent system splits a task across several model instances. The most common pattern is orchestrator and workers: a lead agent plans, spawns sub-agents that each explore one part of the problem in their own fresh context window, and combines their findings. Anthropic reported that its research system, with a Claude Opus 4 lead and Claude Sonnet 4 workers, outperformed a single Claude Opus 4 agent by 90.2% on its internal research evaluation, while using about 15 times more tokens than a chat. That trade is typical. Parallel agents help most on broad, separable tasks like research; they help least on tightly coupled work such as editing one file, where agents step on each other’s changes.

Key takeaways

• Coding is the flagship agent domain: text in, text out, reversible actions and tests that check every step.
• Computer-use agents act through screenshots, clicks and typing. Maximally general, and fragile for the same reason.
• Multi-agent systems buy breadth with tokens. They shine on separable tasks and struggle on tightly coupled ones.

Why reliability compounds

A model that gets each step right 95% of the time sounds excellent. Ask it to complete 20 steps in a row and it finishes the whole task only about 36% of the time.

What is compounding error?

If each step succeeds independently with probability p, a task of n steps succeeds with probability pⁿ. Exponentials are unforgiving: 0.95²⁰ ≈ 0.36, and 0.99¹⁰⁰ ≈ 0.37. Real steps are not independent (one early mistake can doom everything after it, or a good agent can notice and repair it), but the arithmetic explains why agents that dazzle in a two-minute demo stumble on a two-hour task.

How do you bend the curve?

Three levers, in rough order of power: make tasks shorter (fewer steps, or steps that do more), make each step checkable (tests, schema validation, assertions on tool outputs) and retry when a check fails. With a verifier that catches a fraction v of failures and up to k attempts, the effective per-step success becomes:

q = (1 − p)·v is the chance that an attempt fails and the failure is caught, triggering a retry. Uncaught failures slip through.

With p = 95% and 3 attempts behind an 80%-effective verifier, per-step success rises to about 99%, and the 50% horizon stretches from about 14 steps to over 60. Retries without detection do nothing: slide the verifier to 0% and the curves coincide. This is why the most reliable agents live where checking is cheap.

How agents are measured

Agent benchmarks put a model in an environment and check whether the end state is right, not whether the prose sounds good.

• SWE-bench (2023): 2,294 real GitHub issues from 12 Python repositories. The agent must produce a patch that makes the hidden tests pass. At launch the best model resolved under 2%; a 500-task, human-validated subset (SWE-bench Verified) became the standard coding-agent score in 2024 and 2025.
• GAIA (2023): 466 questions that are simple for people but need browsing, file reading and multi-step reasoning. At release humans scored 92% and GPT-4 with plugins 15%.
• τ-bench (2024): simulated customers talk to an agent that must follow airline or retail policies through API tools. It introduced pass^k, the chance of succeeding on all k repeated trials. GPT-4o solved under 50% of tasks, and its retail pass^8 fell below 25%.
• OSWorld (2024): 369 tasks on real desktop operating systems. Humans completed 72.36%; the best model at publication managed 12.24%.

METR proposed a different yardstick: the length of task, measured in how long it takes a skilled human, that an agent can complete with 50% reliability. Across models from 2019 to 2025 that time horizon doubled roughly every seven months. It is a trend line, not a law, and it is measured mostly on software tasks, but it is the clearest single picture of how fast agents are improving.

Key takeaways

• Independent step success p over n steps gives pⁿ. Long tasks punish small per-step error rates.
• Shorter tasks, cheap checks and retries bend the curve. Retrying without detection changes nothing.
• Agent benchmarks check end states: SWE-bench, GAIA, τ-bench (pass^k), OSWorld, and METR’s task-length horizon.

Prompt injection and permissions

The moment an agent reads a web page, an email or a document, whoever wrote that text gets to speak to your model. Some of them will try to give it orders.

What is prompt injection?

Prompt injection is text inside data that the model treats as instructions. Direct injection comes from the user. Indirect injection, described by Greshake et al. in 2023, arrives through content the agent retrieves: a hidden line on a web page, a comment in a code repository, a sentence in a calendar invite. Models process instructions and data as one stream of tokens, so no amount of prompting fully separates them.

How do you reason about the risk?

Simon Willison’s lethal trifecta is the most practical rule of thumb: an agent that combines access to private data, exposure to untrusted content and the ability to communicate externally can be tricked into sending your data to an attacker. Remove any one leg and that attack is gone. Note that “communicate externally” is broader than it sounds: loading an image from a URL that encodes data is enough.

Why does it matter, and what works?

Agents are increasingly given email, calendars, company documents and payment tools. Defences that rely on the model behaving (“ignore instructions in documents”) reduce attack success but never reach zero, and an attacker only needs one success. Defences that constrain what is possible hold up better:

• Least privilege. Give each agent only the tools and scopes its task needs. Read-only by default.
• Sandboxing. Run code and browsers in isolated containers with no credentials and a network allow-list.
• Human in the loop for irreversible or outbound actions: sending, paying, deleting, merging. Keep approvals rare so people actually read them.
• Separate planning from reading. Designs such as CaMeL fix the plan from the trusted user request before any untrusted data is read, so injected text can fill in values but cannot change which tools are called.

Key takeaways

• Anything an agent reads can contain instructions. Models cannot reliably tell your commands from a stranger’s text.
• Private data + untrusted content + an outbound channel = the lethal trifecta. Break one leg by design.
• Prefer structural defences (least privilege, sandboxes, allow-lists, approvals) over asking the model to be careful.

When not to build an agent

The best agent is often no agent. Every step of autonomy costs latency, money and a slice of reliability, so spend it only where it buys something.

What are the alternatives?

Anthropic’s guide recommends starting with the simplest thing that works and adding complexity only when it clearly helps. In order of increasing autonomy:

• A single model call, perhaps with retrieval. Enough for most question answering and drafting.
• A workflow: a fixed chain of calls written in code, such as “extract fields, validate, then summarise”, or a router that sends each input to one of several specialised prompts. Predictable, testable and cheap.
• An agent, when the number and order of steps genuinely cannot be known in advance, as in debugging an unfamiliar codebase or open-ended research.

How do you decide?

Ask four questions about the task:

• Can you write down the steps? Then write them in code and call the model inside each one.
• Is the output one choice from a fixed set? Then it is classification, not generation.
• How bad is a wrong action, and can it be undone? Irreversible actions need a human or a much narrower tool.
• Can success be checked automatically? If not, you cannot build the retry loops that make agents reliable.

Why does this matter now?

A lot of what gets built as an “agent” is really a sequence of small decisions: which queue should this ticket go to, is this document relevant, does this transaction need review. Asking a text generator to write out each decision and then parsing its prose is slow and brittle. Decision models, such as TypeSafe’s Jev released in September 2026, return a typed choice with a calibrated probability directly, and a whole lesson covers when they beat a language model. A good architecture often combines the two: a fast decision model makes the routine calls and hands the genuinely open-ended cases to an agent.

Key takeaways

• Start with one call, then a coded workflow. Reach for an agent only when the steps cannot be known in advance.
• Fixed choices are classification problems. Decision models and classifiers are faster, cheaper and calibrated.
• If you cannot check success automatically or undo a mistake, keep a human in the loop or narrow the autonomy.

Check your understanding

Six scenarios. Each asks you to apply an idea from the lesson to a design decision you could face this week.

Your support agent answers refund questions correctly 97% of the time per step, and a typical refund takes 12 steps (look up order, check policy, compute amount…). Roughly how often does a whole refund go right, assuming independent steps?

References and further reading

Papers, engineering write-ups and announcements cited in this lesson. Agent tooling moves quickly; this lesson was last checked in September 2026.

References

1. [1]

   Building effective agents(opens in a new tab)

   Erik Schluntz and Barry Zhang (Anthropic), 2024

   Distinguishes workflows (predefined code paths) from agents (models directing their own tool use) and catalogues common patterns.

2. [2]

   ReAct: Synergizing Reasoning and Acting in Language Models(opens in a new tab)

   Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, 2022

   Interleaves reasoning traces with tool actions; ICLR 2023.

3. [3]

   Toolformer: Language Models Can Teach Themselves to Use Tools(opens in a new tab)

   Timo Schick et al., 2023

4. [4]

   Introducing the Model Context Protocol(opens in a new tab)

   Anthropic, 2024

   Announcement of MCP, an open standard for connecting AI applications to data sources and tools (25 November 2024).

5. [5]

   MCP joins the Agentic AI Foundation(opens in a new tab)

   Model Context Protocol maintainers, 2025

6. [6]

   Linux Foundation announces the formation of the Agentic AI Foundation(opens in a new tab)

   The Linux Foundation, 2025

   MCP, goose and AGENTS.md become founding projects of a neutral foundation co-founded by Anthropic, Block and OpenAI (December 2025).

7. [7]

   Reflexion: Language Agents with Verbal Reinforcement Learning(opens in a new tab)

   Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao, 2023

8. [8]

   Generative Agents: Interactive Simulacra of Human Behavior(opens in a new tab)

   Joon Sung Park, Joseph C. O’Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, Michael S. Bernstein, 2023

   Memory stream with retrieval by recency, importance and relevance.

9. [9]

   Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku(opens in a new tab)

   Anthropic, 2024

10. [10]

    How we built our multi-agent research system(opens in a new tab)

    Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford (Anthropic), 2025

11. [11]

    SWE-bench: Can Language Models Resolve Real-World GitHub Issues?(opens in a new tab)

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan, 2023

12. [12]

    GAIA: a benchmark for General AI Assistants(opens in a new tab)

    Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, Thomas Scialom, 2023

13. [13]

    τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains(opens in a new tab)

    Shunyu Yao, Noah Shinn, Pedram Razavi, Karthik Narasimhan, 2024

14. [14]

    OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments(opens in a new tab)

    Tianbao Xie et al., 2024

15. [15]

    Measuring AI Ability to Complete Long Tasks(opens in a new tab)

    Thomas Kwa, Ben West, et al. (METR), 2025

16. [16]

    Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection(opens in a new tab)

    Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, Mario Fritz, 2023

17. [17]

    The lethal trifecta for AI agents: private data, untrusted content, and external communication(opens in a new tab)

    Simon Willison, 2025

18. [18]

    Defeating Prompt Injections by Design(opens in a new tab)

    Edoardo Debenedetti et al., 2025

    CaMeL: separates control flow from untrusted data so injected text cannot change what the agent does.