What Is an Agent? — Hadley Wickham's Ground-Up Framework for LLM Tool-Using Systems¶
Source: What Is an Agent? \ Date Published: June 5, 2026 \ Author: Hadley Wickham
TL;DR¶
Hadley Wickham (of tidyverse fame) builds a precise, ground-up definition of AI agents — moving from basic vocabulary to a complete framework. Key concepts: a Turn (user-assistant pair), a Round (full sequence to resolve a request), a Tool (a function that runs on YOUR computer), and a Harness (the wrapper that connects an LLM API to tools and manages conversation state — examples include ellmer and Claude Code). An Agent is an LLM plus a harness plus a tool-using loop: it calls tools repeatedly, deciding which to invoke next based on the result of the last call. Wickham distinguishes two tool types — Read tools (observe the world) and Write tools (change the world) — and centers the core challenge on safety: giving an LLM the ability to delete files or send email creates a fundamental tension between usefulness and trust. Local mitigations include sandboxing, git, and backups.
Defining the Vocabulary¶
Wickham starts from first principles, building up a shared vocabulary that the AI agent field has lacked:
- Turn: A single exchange — one user message and one assistant response. The basic unit of conversation.
- Round: The complete sequence of turns required to resolve a user's request. A round can involve many turns if the assistant needs to make multiple tool calls, interpret results, and refine its approach.
- Tool: A function that executes on YOUR computer — not in the cloud, not in the LLM provider's infrastructure. A tool has a name, description, input parameters, and performs a real-world action (read a file, query a database, send an HTTP request).
- Harness: The software wrapper that connects an LLM API to tools, manages conversation state, handles tool call dispatching and result collection, and controls the overall loop. Examples: Wickham's own ellmer package, Claude Code, ChatGPT with plugins.
- Agent: An LLM + a harness + a tool-using loop. The agent calls tools repeatedly, deciding the next step based on the result of the previous step. This feedback loop is the key characteristic that distinguishes an agent from a simple LLM prompt.
Read Tools vs. Write Tools¶
A critical distinction:
| Type | Purpose | Examples | Risk |
|---|---|---|---|
| Read | Observe the world without changing it | Read file, search web, query database, list directory | Low — information may leak, but nothing is destroyed |
| Write | Change the world | Edit file, delete file, send email, post to API, modify database | High — actions can be destructive or irreversible |
Read tools are relatively safe. Write tools are where the risk lives. The distinction maps neatly onto the classic security concern: read access risks confidentiality, write access risks integrity and availability.
The Core Tension: Usefulness vs. Safety¶
Wickham's central insight: there is a fundamental, irreducible tension between how useful an agent can be and how much you can trust it. An agent that can only read files is safe but limited. An agent that can delete files, send email, and execute arbitrary code is vastly more useful — and vastly more dangerous.
This is not a problem that can be engineered away with better prompts or smarter models. The tension is structural: the more agency you give a system, the more damage it can do when it makes a mistake — or when it is deliberately exploited.
Practical Mitigations¶
Rather than despairing at the safety problem, Wickham catalogues practical mitigations that can reduce risk to acceptable levels for specific use cases:
- Sandboxing: Run the agent in an isolated environment (container, VM) where the damage it can do is bounded.
- Version control (git): If the agent modifies files, every change should be tracked. Rollback becomes trivial.
- Backups: For filesystem operations, automated backups before write operations provide a safety net.
- Permission layers: Require human approval for certain categories of write operations. Delete commands might need explicit confirmation; read commands might not.
- Read-only modes: For exploratory or analytical use cases, restrict the agent to read tools only.
The practical takeaway is not "agents are too dangerous to use" but rather "design your agent interactions with the appropriate level of containment for the risk you are accepting."
Why This Matters Now¶
Wickham's framework arrives at a moment when the term "agent" has been stretched to cover everything from a simple API call wrapper to fully autonomous coding systems. By providing a precise, composable vocabulary, he gives the field a shared language to discuss design choices, safety properties, and capability boundaries. This is the kind of conceptual groundwork that separates mature engineering from hype-driven development.
Key Takeaways¶
- An agent = an LLM + a harness + a tool-using loop — the feedback loop (deciding next steps based on prior results) is what distinguishes agents from simple LLM calls.
- Tools divide into Read (observe) and Write (change the world) categories, with fundamentally different risk profiles.
- There is an irreducible tension between agent usefulness and agent safety — more capability means more potential damage.
- Practical mitigations (sandboxing, git, backups, permissions, read-only modes) can reduce risk to acceptable levels.
- Shared vocabulary (turn, round, tool, harness) gives the field a precise language for discussing agent design and safety.
- The goal is not perfect safety (impossible) but appropriate containment for the risk level of your use case.