Foundations & Concepts

Agentic systems begin with one shift in perspective. Instead of asking a language model for an answer, we ask it to pursue an outcome — and then give it the room, the means and the time to pursue it. An AI Agent is the system built around that shift: a model placed in a setting where it can look around, choose what to do next, do it, see what happened, and choose again, continuing until the work is finished or a limit is reached. The ideas collected in this opening section are the vocabulary of that arrangement. Each of them returns later, in the architectures, the tooling and the safety work, so it pays to meet them together first.

What distinguishes such a system from an ordinary program is Agency (Agent Concept): the capacity to originate a course of action rather than follow one written in advance. A spreadsheet formula recalculates when you change a cell; an agent decides that a cell is worth changing. How much freedom it has in those decisions is its Autonomy (Agent) — a dial rather than a switch, running from a system that proposes every step for approval to one that works unsupervised for hours. Freedom on its own would only produce drift, so the other half of the picture is Goal-Directed Behaviour: every choice is made in service of a stated objective, which gives the agent something to measure progress against and a reason to stop.

Those choices are always made somewhere. The Environment (Agent) is that somewhere — a code repository, a web browser, a ticketing system, a robot's surroundings — the part of the world the agent can inspect and change. It reaches that world through two narrow channels. An Observation (Agent) is what comes in: the contents of a file, the result of a search, an error message, the state of a page. An Action (Agent) is what goes out: the edit, the query, the click, the message. Everything an agent knows arrives as an observation and everything it achieves leaves as an action, which is why designing those two channels well matters more than almost any other decision.

Joining them gives the engine of the whole field, the Agent Loop: observe, reason, act, then observe the consequences and go round again. Each pass is cheap and fallible; the power comes from repetition, because a mistake made in one turn becomes an observation in the next and can be corrected there. A single pass is a guess, while a loop is a method — and nearly every pattern described in this chapter is a variation on what happens inside that cycle.

This is what lies behind the distinction captured by Agent vs Assistant. An assistant answers: you ask, it replies, the exchange closes, and you decide what to do with the reply. An agent acts: you state a goal, it takes many turns by itself, and it comes back when the goal is met. The difference is not intelligence but control — who holds the loop. That is also where the trade sits, since a system that can act without being asked each time is more useful and more consequential in the same breath.

In practice agents rarely work alone or unbounded. An Agentic Workflow embeds one or more agents inside a larger process with fixed stages, checkpoints and handovers to people: autonomy where judgement is genuinely needed, ordinary software where predictability is worth more. Most systems that reach production look like this, and the sections that follow fill in the pieces such a workflow needs — how to structure an agent, how to let it reason and remember, how to give it something to act with, how to coordinate several of them, and how to evaluate and contain what they do.

Agent Design & Reasoning

Once the basic loop is in place, designing an agent comes down to three questions. How are its parts wired together? How does it think before it moves? And what can it carry forward from one step to the next? This section takes those questions in order — first the architectures that give an agent its shape, then the reasoning strategies that decide its moves, then the memory that stops every cycle from starting over in ignorance. The three are not independent: an architecture that plans far ahead needs somewhere to keep the plan, and a critique step is only worth having if the agent remembers what it criticised.

Agent Architectures

The simplest and by far the most common design is LLM-as-Agent, in which a language model sits in the driver's seat: it receives the goal, it decides each move, and the surrounding code merely carries those decisions out and reports back. Nothing about the model itself changes — what changes is its position, from answering questions to steering a process.

From there, the first choice is how many minds to use. A Single-Agent System keeps one decision-maker with one view of the task, which is easier to follow, cheaper to run and far simpler to debug. A Multi-Agent System spreads the work across several agents with separate roles and separate views, trading that simplicity for specialisation and parallel effort. The second choice is the shape of each decision-maker's cycle, and three patterns dominate.

The ReAct Pattern interleaves thinking and doing: a short piece of reasoning, one move, the result of that move, then reasoning again. Because the agent commits to only one step at a time it adapts well to surprises, though it can wander on long tasks. The Plan-and-Execute Agent inverts the emphasis, drawing up a full plan first and then working through it; this keeps a long task on course but copes less gracefully with the unexpected, since a plan written before the first step is the plan that knows least about the problem. The Reflexion Pattern adds a third beat to either of them: after an attempt, the agent judges its own result, writes down what went wrong, and tries again with that note in hand — turning a failure into usable information rather than a dead end.

These patterns were not derived on paper; they were discovered in public. AutoGPT and BabyAGI were early open experiments that handed a model a goal and simply let it loop. Both were fragile, prone to repeating themselves and to chasing tangents, and both were enormously instructive: they showed that a looping model can genuinely make progress on its own, and that without limits, structure and memory it will also happily spin forever. A great many of the constraints introduced later in this chapter are answers to something those experiments exposed.

Reasoning & Planning

Inside the loop, the agent's real work is deciding what to do next, and the simplest way to improve that decision is to let it think in writing. Chain-of-Thought (Agent) reasoning asks the model to work a problem through in explicit intermediate steps instead of jumping to a conclusion. In an agent this earns its keep twice over: the reasoning improves the choice, and it leaves a readable trail of why the choice was made.

Large goals, though, cannot be reasoned about all at once. Task Decomposition breaks an objective into smaller pieces that can be tackled one at a time, and Subgoal Generation is the act of naming those pieces as goals in their own right, each with its own finish line. How far ahead this is worth doing is the agent's Planning Horizon: plan too narrowly and it loses the thread of the larger task; plan too far and it spends effort on steps that early results will invalidate. Where several routes to a subgoal look plausible, Tree-of-Thought Reasoning explores more than one branch before committing, comparing partial lines of attack rather than following the first idea to its end.

The remaining strategies are about improvement rather than choice. Self-Critique has the agent examine its own output against the goal and say what is weak or missing. Reflection (Agent) widens that gaze from the output to the attempt, asking what the approach itself got wrong. Iterative Refinement (Agent) then feeds those findings into another pass, and another, so quality climbs across several drafts. This is how agents cope with being imperfect at every individual step: not by being right first time, but by noticing and repairing. The catch is that criticism without memory is wasted, which is where the next part comes in.

Memory Systems

An agent's attention is finite, so it needs deliberate ways to hold on to what matters. Short-term Memory (Agent) is the immediate record of the current task — the recent steps, results and messages the agent can still see. Within it sits Working Memory (Agent), the small, actively used set of facts the decision at hand actually depends on: the goal, the plan, the last error. Long-term Memory (Agent) reaches beyond the current task, keeping what should survive after it ends.

Long-term storage is usually divided by the kind of knowledge it holds. Episodic Memory (Agent) keeps particular experiences — this task, these steps, this outcome — so that a similar situation can be recognised later. Semantic Memory (Agent) keeps general facts distilled out of those experiences, such as how a system behaves or what a user prefers. Procedural Memory (Agent) keeps know-how: the sequence that worked, the recipe worth repeating. The division matters because each kind is recalled differently and is useful at a different moment.

Storing is the easy half; the hard half is bringing the right fragment back at the right time. Memory Retrieval (Agent) selects, out of everything recorded, the few pieces relevant to the decision being made — too little and the agent repeats old mistakes, too much and the relevant piece is buried. The usual implementation is a Vector Memory Store, which holds each remembered fragment alongside a numerical representation of its meaning, so that a current situation can fetch past fragments similar in substance rather than merely matching in wording.

All of this competes for the same scarce space, and managing that space has become a discipline of its own. Context Window Management is the practical work of staying within the fixed amount of text a model can attend to at once, deciding what stays, what goes and in what order. Context Engineering is the broader craft of assembling what the agent sees on each pass — goal, relevant history, retrieved memories, current state — on the view that behaviour is shaped as much by what is put in front of a model as by the model behind it. When a long run inevitably outgrows the window, Context Compaction compresses the accumulated history into a shorter form that keeps the parts still needed, and Summarisation Memory makes that compression lasting, storing condensed accounts of earlier work as the durable record of a run too long to hold in full. Together they let an agent work for far longer than its attention span — which is exactly what the frameworks, runtime controls and evaluations in the rest of this chapter take for granted.

Tools & Interoperability

An agent that can only produce text can only ever describe the world. What turns description into action is a tool: a named capability the agent is allowed to invoke, whose result comes back as fresh input for its next turn of thinking. Everything in this part of the subject follows from that one idea, and it splits into two halves. The first is the mechanics of a single call — how a capability is declared, chosen, invoked, combined and recovered from when it goes wrong. The second is interoperability: the shared conventions that let an agent use tools nobody wired into it by hand, and let agents built by different people address one another at all.

Tool Use & Function Calling

Function Calling is the move everything else rests on. Instead of replying in prose, the model replies with a request: this capability, with these arguments. The program around the model performs the request, hands the result back, and the model carries on. Notice what this buys in safety as much as in power — the model never reaches into the outside world itself. It asks, and a layer you control decides whether and how to act.

For such a request to be machine-readable, every capability is declared in advance, and the declaration has two halves that are easy to confuse. The Tool Schema is the formal half: the tool's name, the arguments it accepts, which of them are required, and what type each one holds — enough structure that a request can be validated before anything runs. The Tool Description is the plain-language half, and it carries more weight than it appears to, because it is the only thing that tells the model what the tool is for and when reaching for it is sensible. A flawless schema with a vague description yields a tool the agent either ignores or misuses. Both halves depend on the model's ability to produce Structured Output (Agent): argument values that fit the declared shape exactly, rather than a sentence some parser has to interpret.

Once more than a handful of capabilities exist, choosing between them becomes its own skill. Tool Selection is that judgement — matching the step at hand to the one capability that actually advances it, and recognising when none of them does. Because each declaration occupies room in the agent's prompt, and a long menu makes the choice harder rather than easier, large collections are often handled with Dynamic Tool Loading: only the tools plausibly relevant to the current task are placed in front of the model, and the rest stay out of sight until something calls for them.

From there, calls grow wider and deeper. Parallel Tool Calls let an agent issue several independent requests in a single turn — three lookups that do not depend on each other need not wait in line — which cuts both the waiting and the number of thinking steps a task consumes. Multi-Tool Composition is the harder ability: feeding one tool's result into the next, so a goal that no single capability covers is reached by a short, deliberate chain of them.

Three kinds of tool recur so often that they deserve naming. API Integration (Agent) wraps a service that already exists, so booking, searching or filing becomes one more callable capability. A Code Execution Tool goes further and hands the agent a confined interpreter, which is how arithmetic, data wrangling and file work get done by computation instead of by guesswork. And since any call can fail — a service down, an argument rejected, a script that raises — Tool Error Handling decides what the agent is shown when it does. Returning the failure to the model as an ordinary observation, rather than letting it end the run, is precisely what lets an agent correct itself: it reads the complaint, repairs the argument, and tries again.

Communication & Protocols

Everything above assumes that someone connected each tool to each agent by hand. That works for one agent and a few capabilities, and collapses as soon as there are many of both: every new tool needs adapting to every runtime that might use it. A protocol replaces wiring with a convention. Model Context Protocol is the most widely adopted convention of this kind — one open way of describing what a capability is and how to invoke it, so any agent that speaks it can use any tool that speaks it, with no bespoke glue in between.

Its shape is a simple two-sided one. An MCP Server is the side that owns a capability — a file store, a database, a calendar, an internal system — and exposes it in the agreed form. An MCP Client lives inside the agent's runtime and connects outward to such servers on the agent's behalf. Between them sits the MCP Transport, the channel the messages travel over, whether the server is a process on the same machine or a remote service across a network. Because the conversation is identical either way, moving a tool from a laptop to a shared server changes nothing about how the agent calls it.

A server offers more than functions to run. MCP Resources are readable content it makes available — documents, records, files — material the agent pulls in as context rather than acts upon. MCP Prompts are reusable instruction templates the server suggests, which lets the people who understand a system best ship the wording that uses it well, instead of leaving every agent author to rediscover it. And the Tool Catalog (MCP) is what a client asks for the moment it connects: the current list of what this server can do. That single question is what makes capability discovery happen while the agent is running, rather than being fixed when it was built.

Tools are not the only thing worth standardising. As systems grow into several cooperating agents, those agents need to address each other as peers rather than each pretending the other is a tool. Agent2Agent is a protocol for that peer relationship: how one agent sends another a task, follows its progress, and receives a result. It is made practical by the Agent Card, a small published description stating who an agent is, what work it will take on, and how to reach it — so an agent can find a suitable collaborator much as a client finds a tool. Alongside these open conventions sit hosted ones, where a vendor supplies the whole arrangement: the OpenAI Assistants API packages the loop, the tool wiring and the conversation state as a managed service, trading away some control in exchange for far less to assemble yourself.

Multi-Agent Coordination

A single agent is limited by a single thread of attention: one set of instructions, one view of the task, one line of reasoning that must cover everything. Splitting the work across several agents lifts that limit. Each one can carry a narrower brief, hold its own context, and work at the same time as the others. The price is coordination. The moment there is more than one agent, three questions appear that a lone agent never faces — who talks to whom, who decides, and how disagreement is brought to an end. The patterns below are the accumulated answers.

Underneath all of them sits Multi-Agent Communication: the arrangement by which agents exchange anything at all. What is exchanged is usually not raw thinking but messages — a request, a finding, a result — and the design questions are unglamorous and decisive. Does a message go to one named recipient or to everybody? How much context travels with it? Is the exchange a conversation agents take turns in, or a space they all write into? Almost every coordination failure in practice turns out to be a message that was too vague, too large, or sent to the wrong agent.

The lightest structure is simply passing the work along. An Agent Handoff transfers a task from one agent to another together with enough of the history that the receiver can continue rather than restart — a support agent passing a billing question to a billing specialist, carrying the customer's account and what has already been tried. Task Routing (Agent) is the decision one step earlier: given an incoming request, which agent should receive it in the first place. Routing well depends on knowing what each agent is good at, which is why a system's description of its own members matters as much as their abilities.

Where the work is large rather than merely varied, hierarchy helps. In the Orchestrator-Worker Pattern one agent holds the goal, breaks it into pieces, hands each piece out, and assembles what returns. Each Worker Agent sees only its own piece, which keeps its context small and its behaviour easy to judge, and reports back without needing a view of the whole. Stack that arrangement more than one level deep — orchestrators that manage orchestrators, each layer summarising upward — and you have a Hierarchical Multi-Agent system, the usual answer when a task is too big for one manager to track. The Blackboard Pattern takes the opposite stance: no manager, just a shared workspace that every agent can read and write. Each agent watches for a state it knows how to improve, contributes, and leaves the result for others. Coordination emerges from the shared space instead of from instructions, which is flexible but makes progress harder to guarantee.

A second family of patterns uses several agents not to divide labour but to improve judgement. Multi-Agent Role-Play assigns each agent a stated role and perspective, so that considerations one voice would have skipped — the cautious one, the critical one, the one who speaks for the user — actually get spoken. Multi-Agent Debate sharpens this by having agents argue competing answers to the same question; a weak claim tends to fall apart under a peer's objection faster than it would under self-review. Agent Negotiation applies when the agents genuinely want different things, acting for different parties or under different constraints, and must trade their way to an arrangement all of them can accept. Each of these needs a stopping rule, which is the job of a Consensus Mechanism: a majority, a required threshold of agreement, a designated agent who adjudicates. Without one, deliberation does not converge — it simply runs until the budget does.

Scale all of this up and it stops resembling a program. An Agent Society is a population of persistent agents with standing roles, shared conventions and a history of interaction, where the interesting behaviour belongs to the group rather than to any member. It is both the most speculative idea here and a useful corrective: once agents coordinate, what you are designing is a small social system, and it should be judged on how the whole of it behaves.

Building & Operating Agents

There is a wide gap between an agent that works once in a demonstration and an agent that runs every day without supervision. Closing it is an engineering job, and it has four concerns. You need something to build on, so you are not reimplementing the loop from scratch. You need limits, because an autonomous process that decides its own next step will otherwise run further and cost more than you intended. You need durability, because real tasks outlast a single process. And you need visibility, because an agent that behaved oddly is impossible to improve if nobody can see what it did.

Agent Frameworks

A framework supplies the parts every agent needs and nobody enjoys writing twice: the loop that keeps calling the model until the goal is met, the plumbing that turns a declared capability into a real call, somewhere to keep state between steps, and hooks for limits and logging. The options differ less in what they can do than in how much of the loop they expect you to own — and that, rather than a feature list, is the thing to choose on.

• LangChain is the earliest broad toolkit of this kind, built around composing model calls and tools into reusable pipelines, with a large library of ready-made connectors.
• LangGraph comes from the same family but models an agent as an explicit graph of states and transitions, which makes cycles, branches and pause-and-resume points first-class rather than emergent.
• LlamaIndex Agents grew out of tooling for searching large document collections, and suits agents whose main job is to reason over a body of text.
• AutoGen (Microsoft) treats a conversation among several agents as the basic building block, so collaboration is the default shape rather than something you add.
• CrewAI organises work around roles and goals: you describe who is on the team and what each member is for, and the framework handles the delegation between them.
• Semantic Kernel is aimed at embedding agent behaviour inside conventional business applications, with capabilities registered as plugins that ordinary application code can call.
• OpenAI Swarm was published as a deliberately minimal, experimental sketch — little more than lightweight agents and handoffs between them — intended to show the idea rather than to run production work.
• OpenAI Agents SDK is its supported successor, carrying the same small core into a library meant for real deployments, with tracing and guardrails included.
• Claude Agent SDK packages the loop, tool permissions and long working sessions for agents built on Claude, including unattended runs.
• Vertex AI Agents is a managed cloud offering, where the hosting, scaling and identity concerns are the platform's problem rather than yours.
• Pydantic AI puts types first: you declare the shape of what you expect back and the framework validates it, which keeps an agent's output safe to pass into other software.
• smolagents is intentionally tiny and favours agents that write short programs to accomplish a step, trading breadth for a core small enough to read in an afternoon.

Runtime Control & Cost

An agent decides for itself whether to take another step, which means that left alone it can keep going indefinitely — and every step costs money and time. Control begins with a Termination Condition: an explicit statement of what finishing means, whether that is a result in the required shape, a check that passes, or a question answered. Agents that lack one tend not to stop; they drift, polishing work that was already done.

Because a stated goal can always be missed, the condition is backed by blunter limits. A Step Limit (Agent) caps how many times the loop may turn, guaranteeing an end even when nothing else triggers. Loop Detection (Agent) catches the more insidious failure: an agent that is still acting but no longer progressing, calling the same tool with the same arguments and receiving the same result. Spotting the repetition early and interrupting it — or telling the agent plainly that it is repeating itself — saves most of a wasted run.

Cost needs its own ceiling, because a step that reads a long document is far more expensive than one that does not. A Token Budget (Agent) bounds the total material a run may process, and Cost Control (Agent) is the wider discipline around it: choosing a cheaper model for routine steps, keeping the prompt lean, caching what will be asked again, and measuring spend per completed task rather than per call. Finally, Retry & Backoff (Agent) governs transient failure — retrying a step that failed for reasons unrelated to the agent's judgement, with a growing pause between attempts and a firm limit on how many, so that a struggling service is given room to recover instead of being hammered.

Deployment & Durability

Short tasks hide a problem that long ones expose immediately. A Long-Running Agent may work for hours or days, across restarts, deployments and outages — so its progress cannot live only in the memory of one process. Durable Execution is the answer: the run's state is persisted as it advances, so that a crash costs the current step rather than everything. Agent Checkpointing is the mechanism, writing down where the agent got to and what it knows at chosen points, and Agent Resumption is the payoff, picking the work up from the last checkpoint instead of from the beginning. The same pair makes deliberate pauses possible, which is what lets an agent wait on a slow service or a human reply without holding a process open. A Headless Agent is the deployment shape all of this serves: an agent with no interactive session behind it, started by a schedule or an event, which must therefore carry its goal, its limits and its reporting in its configuration — because there is nobody present to answer a question it asks.

Observability & Tracing

An agent's output is a poor record of its work. Two runs can produce the same answer after wildly different journeys, and a wrong answer says nothing about which step went astray. Agent Tracing captures the journey itself as structured data: each step recorded in order, nested so a tool call sits inside the reasoning step that requested it. The unit of that record is the Trace Span (Agent) — one operation with a start, an end, and its inputs and outputs attached — which is what makes a trace searchable rather than merely long.

Trajectory Logging keeps the full sequence of observations, decisions and actions a run went through, and that stored sequence has uses beyond debugging: it is the material for judging whether the agent's route was sensible, and the raw data for improving it. Trajectory Replay runs a recorded path again, either to reproduce a failure exactly or to see whether a changed prompt or model would have handled the same situation better. Agent Telemetry aggregates across runs instead of within one — step counts, durations, failure rates, spend — which is how a slow regression becomes visible before users report it. Tools exist to hold all of this: LangSmith is a widely used hosted service for collecting traces, inspecting individual runs and tracking how changes affect them over time.

Evaluation & Safety

Autonomy raises two questions at once, and they are easy to mistake for a single one. Evaluation asks whether an agent is any good: does it finish the work, and does it get there sensibly. Safety asks what it may be trusted to do unsupervised: which actions it can take alone, which require a person, and what record remains afterwards. A capable agent with no safeguards is a hazard, and a thoroughly fenced agent that cannot complete anything is merely a slow way of doing nothing, so the two are developed together.

Evaluation

The first measure anyone reaches for is Task Success Rate: of a set of tasks attempted, what fraction ended in the required outcome. Its virtue is that it is honest about the only thing a user cares about. Its weakness is that it is a single bit per task, which tells you nothing about how close a failure came or how wasteful a success was.

Agent Trajectory Evaluation looks at the route instead of the destination, asking whether the steps taken were reasonable: were the right capabilities chosen, was effort repeated, did the agent recover from its own errors, did it reach the answer by a path you would endorse. This matters because an agent can arrive at the correct result through luck, and such a run will fail quietly as soon as the task shifts. Judging routes by hand does not scale, which is why LLM-as-Judge (Agent) is so common: a model scores the output or the trajectory against a written rubric, cheaply and consistently enough to run on every change. It is an approximation of human judgement, with the biases that implies, and it is best kept honest by periodically checking its verdicts against a few judged by people.

Beyond your own tasks sit shared benchmarks, which exist so that claims can be compared. AgentBench gathers many kinds of agent task into one suite, giving a broad if shallow picture of general competence. GAIA Benchmark poses questions that are simple to state and impossible to answer without several steps of tool use, which exposes the difference between knowing things and doing things. SWE-bench draws on real reported software defects and asks for a change that makes the project's own tests pass — a rare case of a task with an unarguable verdict. Tau-bench turns to service work, measuring whether an agent can handle a customer interaction while honouring the rules it was given, which is as much about compliance as capability.

A further family tests agents that operate interfaces rather than text. WebArena provides self-contained websites an agent must actually use to complete errands, so results are reproducible in a way the live web never is. Mind2Web goes the other way, spanning tasks across a wide range of real sites to test whether skills generalise beyond the pages an agent was tuned on. BrowseComp concentrates on hard search: questions whose answers are genuinely buried and demand persistent, well-directed browsing. OSWorld widens the stage to a whole desktop, with files, windows and applications, where a task may need several programs used in sequence. Each of these is a narrow slice, and the practical lesson is to read a benchmark as evidence about one slice rather than as a verdict on an agent overall.

Safety & Alignment

Giving a system the ability to act changes the nature of its mistakes: a wrong sentence can be ignored, a wrong action has already happened. The threats start with the input. Prompt Injection (Agent) is the central one, and it is structural rather than incidental — an agent reads pages, documents, messages and tool results, any of which may contain instructions aimed at the agent instead of information for it. Because the agent cannot easily tell content apart from command, text it merely read can end up steering what it does. Agent Jailbreak is the related attempt to talk an agent out of its own rules, and it is more consequential here than in a chat setting, because the reward is not forbidden words but forbidden actions.

The sturdiest defences assume such attempts will sometimes succeed and limit what follows. Agent Sandboxing confines execution: a bounded filesystem, restricted network access, a disposable environment, so that a damaging command damages only the box. Permission Scoping (Agent) narrows reach in the same spirit, granting an agent exactly the capabilities its task requires and no more — read access where reading suffices, one account rather than the whole system. These two are the architecture of agent safety, and they hold whether a bad action came from an attacker or from the agent's own confusion.

Inside those bounds, policy does the finer work. A Guardrail (Agent) is a check sitting across the loop, inspecting what the agent is about to do or about to say and blocking what falls outside the rules. Action Confirmation interposes a person at the moment of consequence, showing exactly what is about to happen and waiting for assent — the difference between an agent that sends the message and one that drafts it for you to send. An Approval Gate formalises this as a defined checkpoint a run must pass before continuing to a sensitive phase, rather than a prompt attached to each individual act.

The broadest framing of these is Human-in-the-Loop (Agent): deciding deliberately which decisions stay with people and which the agent may make alone, and recognising that the line should move as evidence accumulates. Its companion is Escalation to Human, the agent's own judgement that it has reached its limit — ambiguous instructions, a risk it cannot assess, repeated failure — and should hand over rather than press on. An agent that escalates well is more trustworthy than one that never admits difficulty. Underpinning everything is the Audit Trail (Agent): a durable record of what the agent did, when, on whose behalf and with what result. It is what makes an incident explainable after the fact, and what makes granting an agent more freedom a reversible decision instead of an act of faith.

Specialised Agents & Applications

General patterns become useful when they meet a particular job. The moment an agent is pointed at one kind of work, its design stops being abstract: the tools it needs, the way success is judged, and the amount of freedom it can safely be given all follow from the domain. The groups below move from agents defined by the tools they hold, through agents defined by the field they serve, to the uses that are putting all of this to work today.

Coding Agents

Software is where autonomy landed first, and not by accident. A Coding Agent works in an environment that is unusually kind to it: code is text it can read and write, and the environment answers back. Compilers reject mistakes, tests pass or fail, and version control makes an error undoable. That feedback closes the loop without a person in it, which is exactly what an agent needs in order to improve its own attempt.

Three projects show how differently the same idea can be shaped. SWE-agent came out of research into whether an agent could resolve real reported defects on its own, and its contribution was a deliberately simple interface for reading and editing a repository — demonstrating that the way an agent is given access to a codebase matters as much as the model behind it. Devin was presented as a far more ambitious product: an autonomous engineer with its own workspace, taking a task description and working at length with little intervention. Aider takes the opposite and quieter position, pairing with a developer at the command line on their own checkout, proposing changes as commits the person reviews — a reminder that collaboration, rather than replacement, is often the more useful setting.

Computer & Browser Agents

Not every system offers a clean way in. When no programmatic access exists, an agent can fall back on the interface a person would use. A Computer-Use Agent operates a machine the way a human does: it looks at the screen, decides where to click and what to type, and acts through the same keyboard and pointer. That generality is the appeal — anything a person can do becomes reachable — and the drawbacks are equally plain, since progress depends on reading a picture correctly and interfaces change without warning.

A Browser Agent narrows the stage to the web, where it can work with page structure instead of pixels alone, navigating, filling forms and extracting results. The narrowing makes it considerably more reliable, which is why so much practical work sits here rather than at the level of the whole desktop. Anthropic Computer Use was the first widely available capability of this kind from a major model provider, letting a model take screen actions directly and turning the idea from a prototype into something ordinary applications could build on. Everything in this area carries a heightened safety burden, because an agent that can click anything can also click something irreversible.

Domain-Specific Agents

Other agents are defined less by their tools than by the shape of the work. A Research Agent pursues a question it cannot answer in one step, searching, reading, following what it finds and assembling an account with its sources — the hard part being not retrieval but knowing when the picture is complete enough to report. A Data-Analysis Agent works against datasets, writing and running code to clean, aggregate and chart, which suits an agent well because every intermediate result is checkable and a wrong turn shows up quickly in the numbers.

A Voice Agent faces a different constraint entirely: a conversation in real time, where a long pause is itself a failure and there is no screen to fall back on. Pace and interruption become design problems, and the agent must often commit to a response before it has everything it would like. An Embodied Agent goes furthest, acting in the physical world through a robot or vehicle, where an action cannot be retracted and the environment is never fully observed. It is the sharpest form of a lesson running through all of these: the more irreversible the consequence, the more conservative the autonomy.

Applications

Set against those capabilities, the uses now in production tell you what the technology is actually ready for. Autonomous Software Development is the most advanced, with agents taking defined pieces of work — a fix, a migration, a set of tests — through to a reviewable change, succeeding precisely because the result can be verified before anyone depends on it. Workflow Automation is the broadest in reach: the many processes that are mostly routine but not quite rule-based, where a step depends on reading a document or judging an exception. Agents fit there because they can handle the irregular middle that fixed automation stalls on.

Customer Support Automation was an early and natural fit, since resolving a request usually means consulting records and acting on them, not merely replying — and it illustrates the whole subject in miniature, needing tools, a memory of the conversation, firm limits on what may be changed, and a clean route to a human when the case warrants one. The Personal Agent is the most anticipated and least settled: an agent that handles an individual's errands across their own accounts and services. The obstacles there are only partly technical — it requires trust with private data and standing permission to act on someone's behalf, which is why this remains the application most often described and least often delivered.