What an Agent Actually Is

Consider two illustrative systems, both called agents.

The first takes a support ticket, classifies it into one of six categories with a model call, looks up the customer record, fills a response template, and sends it. It handles four thousand tickets a day at high accuracy. Its authors call it an AI agent, and their marketing page is not lying.

The second receives a request: “The January reconciliation for acme is off by four hundred dollars. Find out why.” It reads the settlement export, notices a date-range mismatch and queries the warehouse. It finds a duplicated batch and checks whether someone corrected it. No correction exists.

It drafts one, notices that the amount exceeds its authority and asks a human. The illustrative investigation takes forty minutes and thirty-one tool calls, chosen as evidence arrives.

The distinction is who decides what happens next.

The running example is Reference Agent, an illustrative enterprise work agent. Its scenarios and operating figures are illustrative unless a source states otherwise.

1.1The definition that survives contact#

An agent is a system in which a model decides, at runtime, which actions to take, observes their results, and continues until it judges the task complete or is stopped.

“A model decides” — the control flow is chosen by the model rather than written by you. The first system above has its control flow in an if statement. That is a workflow, and Chapter 7 argues it is frequently the better choice.

“At runtime” — not at design time. You did not enumerate the thirty-one tool calls; you could not have.

“Observes their results” — the loop closes. The model sees what happened before choosing again, which is what separates an agent from a system that plans once and executes blindly.

“Until it judges the task complete or is stopped”: termination is also a runtime decision. The harness must be able to stop the model independently.

Nothing in that definition mentions autonomy, reasoning, planning, memory or tools-as-such. Those are all things agents commonly have, and none of them is what makes something an agent.

1.2Agency is a spectrum, and the position is a decision#

The binary question “is this an agent” is less useful than the graded one: how much of the control flow is decided at runtime? That is a dial, and where you set it is one of the most consequential engineering decisions in the system.

Bounded loops and explicit plans occupy levels 2 and 3. Self-modification at level 5 remains a research frontier (Chapter 26).

More runtime discretion trades predictability, testability and auditability for capability on unfamiliar tasks. Those properties require explicit controls.

1.3What actually changed#

If you last looked closely at agents in 2024, four things are different, and only one of them is “the models got better.”

Tool use gained stronger API support. Native function calling already existed in June 2023, so it is not a new 2026 capability.² Current APIs support structured tool proposals and, for compatible models, parallel calls. Use those capabilities to reduce parsing code. Keep argument validation, authorization and effect verification in the harness. A smaller loop helps only when it preserves those controls.

Long context changed the shape of the problem, not its existence. Windows of hundreds of thousands to millions of tokens turned a feasibility problem — can this task fit — into an economics and precision problem. Chapter 8 makes the case that this is a real improvement and not a solution: retrieval and reasoning accuracy can vary with content and position, and retained input can be billed repeatedly, with provider-specific caching discounts.

The ecosystem converged and then institutionalised. Independent open-source harnesses arrived at recognisably the same architecture — event logs, permission tiers, skills, sandboxes, checkpoints — which Chapter 3 documents in detail. And the coordination layers moved to neutral governance: goose, the Model Context Protocol and AGENTS.md are now hosted under the Agentic AI Foundation at the Linux Foundation rather than belonging to individual vendors.¹ For an engineer that is mildly interesting; for enterprise procurement it materially changes the risk of building on them.

Evaluation began measuring repeated task completion. The June 2024 τ-bench evaluated multi-turn tool use against domain policies. Tested agents scored below 50% single-pass success, with retail pass^8 below 25%.³ These historical results do not estimate November 2026 capability. pass^8 requires success on all eight trials. pass@8 requires at least one success.

Meanwhile a systematic study of multi-agent failures built a dataset of over 1,600 annotated traces across seven frameworks and produced a taxonomy of 14 distinct failure modes in three categories — system design, inter-agent misalignment, and task verification.⁴ The field now has a shared vocabulary for how these systems break, which is a sign of maturity rather than of trouble.

1.4The arithmetic of a trajectory#

Single-step accuracy is a poor guide to agent reliability because an agent does not make one consequential choice. It makes a sequence of choices, and later choices depend on the state produced by earlier ones. The unit you operate is therefore the completed trajectory, not the model turn.

Start with an intentionally simple calculation. Suppose Reference Agent handles an account-reconciliation task in ten consequential steps: five model decisions, three reads whose results must be interpreted correctly, one proposed write, and one verification. Assume, for illustration, that each step has a 97% chance of being correct enough for the run to continue. If correctness at each step were independent, the probability that all ten steps are correct would be:

P(clean run) = 0.97^10 = 0.737

That is 73.7% clean trajectories from 97% reliable steps. At twenty steps the same arithmetic gives 0.97^20 = 54.4%. At thirty-one steps — the reconciliation from the opening — it gives 0.97^31 = 38.9%. A number that sounds excellent in a component review becomes unacceptable when compounded across a run.

Every number in this table is illustrative. Real agent errors are not independent. A poor early interpretation can poison several later decisions; an outage can make every call to one tool fail; one stale document can mislead the whole run. Correlation has no universal correction factor: a shared outage can cluster failures, while independent errors spread failures across more runs. Estimate joint success empirically. Verification, retries and recovery also mean that a failed intermediate step need not make the whole task fail. Chapter 24 replaces the toy assumptions with empirical trajectory evaluation. The lesson survives: measure the path you ship, not an imagined average turn.

The arithmetic also explains why “the model improved by two points” is not a complete business case. For a twenty-step trajectory, moving every consequential step from 97% to 99% raises the illustrative clean-run probability from 54.4% to 81.8% — a 27.4 percentage-point gain. That is substantial. But shortening the path can produce a comparable effect without changing the model: at 97%, cutting twenty consequential steps to ten raises the clean-run probability from 54.4% to 73.7%. A deterministic batch read that replaces six model-directed record lookups may be worth more than a smarter planning prompt.

Now add retries. Suppose the ten-step run contains one flaky read that succeeds 90% of the time, and the other nine steps remain 97% reliable. With no retry:

P(clean run) = 0.97^9 × 0.90 = 68.4%

Assuming independent attempts with the same 90% success probability, one retry makes the read succeed unless both attempts fail, so its effective success probability is 1 - (1 - 0.90)^2 = 99%. The trajectory becomes:

P(clean run with retry) = 0.97^9 × 0.99 = 75.3%

That 6.8-point gain is real only if retrying is safe. Retrying a read usually is; retrying “issue refund” is not unless the action carries an idempotency key and the state log can prove whether the first attempt committed (Chapters 5 and 22). Reliability arithmetic without side-effect semantics produces the most dangerous kind of optimisation: a higher completion rate bought by duplicated effects.

The final layer is verification. Assume the proposed correction step is wrong 3% of the time and an independent verifier detects 80% of those wrong proposals. The unobserved error rate for that step is not 3%; it is 3% × (1 - 80%) = 0.6%. But the verifier also has a false-positive cost: it may reject good work, trigger human review, or add a model call and two seconds. The operational question is not “should we verify?” It is where does verification buy the largest reduction in expected harm per unit of latency and cost? Verify the irreversible write, not every harmless read. Chapter 19 places a human at that seam; Chapter 24 shows how to score both missed errors and unnecessary escalations.

You can make that decision with expected-loss arithmetic. Suppose Reference Agent proposes 10,000 low-value record corrections each month. A wrong correction occurs on 3% of proposals, and the mean cost of detecting and reversing one after execution is £12. With no verification, the illustrative expected monthly loss is:

10,000 × 0.03 × £12 = £3,600

Now suppose a verifier costs £0.04 per proposal, catches 80% of wrong proposals, and incorrectly blocks 1% of correct proposals. Reviewing each blocked good proposal costs £2. The verifier’s direct cost is £400. Residual wrong corrections cost 10,000 × 0.03 × 0.20 × £12 = £720. False positives cost 10,000 × 0.97 × 0.01 × £2 = £194. Total expected monthly cost is £1,314 rather than £3,600 — an illustrative saving of £2,286.

That same verifier can be a bad choice at a different boundary. If the action is a reversible read whose wrong interpretation costs £0.05 to correct, the unverified expected loss across 10,000 actions is only £15. Spending £400 on verification increases cost before false positives or latency enter the calculation. “Add a verifier” is therefore not a safety principle. Place verification where probability multiplied by harm justifies it. The relevant probability is the chance that an error survives every earlier control, and the relevant harm includes recovery labour, customer impact and irreversible effects.

The arithmetic becomes more useful when you separate three rates that teams often compress into one success metric. Proposal error rate asks how often the model’s intended next step is wrong. Detection rate asks how often policy, validation or verification catches that error before effect. Recovery rate asks how often the harness restores the desired state after a detected or executed error. A system may improve its visible task completion rate while worsening all three — for example, by suppressing escalations and declaring partial outcomes complete.

Record those rates by task family and by transition type. A global 92% completion rate can combine harmless research dead ends with failed payments and tell you nothing operational. For Reference Agent, the useful slice is closer to “external mutation proposed after untrusted retrieval”: proposals, denials, approvals, executed effects, verified effects, compensations and unresolved outcomes. Every percentage needs a denominator and every denominator needs a boundary.

This decomposition tells you which lever to pull. A high proposal error rate points towards better context, clearer tools or less runtime discretion. A low detection rate points towards schemas, policy rules and independent checks. A low recovery rate points towards idempotency, compensation and durable state. Replacing the model may improve the first number and leave the other two untouched. Adding blanket human approval may improve detection while destroying throughput and training people to click through requests. The metric is useful only when it distinguishes these mechanisms. Give each intervention a predicted movement before you ship it — “reduce undetected wrong mutations from 0.6% to 0.3%” — then test that prediction on trajectories. If you cannot name the rate a proposed change should move, you have an intuition, not an engineering hypothesis.

Use the independence model to diagnose sensitivity to path length and weak transitions. Release evidence must come from repeated full trajectories on representative tasks, which expose correlated errors, state drift, recovery behaviour and bad stopping decisions.

1.5The harness thesis#

An agent is a model plus a harness, and the harness is where almost all the engineering lives.

Consider a bare loop:

while True:
    response = model.complete(messages, tools=tool_schemas)
    messages.append(response.message)
    if not response.message.tool_calls:
        return response.message.content
    for call in response.message.tool_calls:
        messages.append(tool_message(call.id, tools[call.name](**call.arguments)))

This schematic fragment omits its enclosing function and helpers. It is unoperable: it cannot be stopped, bounded, resumed, audited, permissioned or measured. It has no per-task cost control. It can repeat a side effect after a crash and has no enforced boundary against instructions hidden in a retrieved document. A better model may make fewer mistakes, but cannot supply missing durable records or application permissions.

Add durable state, permissions, budgets, provenance-labelled context, guardrails and tracing. The same model becomes easier to bound, inspect and recover.

There is a corollary about where to spend your time. Model capability improves on someone else’s schedule and lifts every competitor simultaneously. Harness quality improves on your schedule and is where durable advantage accumulates. Two teams using the same frontier model in six months, one having spent the quarter on prompt tuning and one on state durability, permissioning and evaluation: the second team has built controls that prompt tuning alone cannot provide. Both still need evidence that their model and harness work together.

1.6A failure that looked like a model problem#

Reference Agent receives a request to deactivate the accounts in a departure spreadsheet. The spreadsheet contains 120 rows. The agent reads it, resolves 118 employees, reports two ambiguous names, receives clarification, calls the identity tool repeatedly, and finishes with a polished summary: 120 accounts deactivated. The model’s reasoning trace looks coherent. The operator checks three records and finds them disabled. The run is marked successful.

The next morning, twelve former employees can still sign in.

The first assumption is that the model skipped rows. The team inspects the plan, increases the instruction emphasis around completeness, and adds a final prompt asking the model to count the results. That change cannot fix the incident. The trace already contains 120 deactivation tool results, and the final count is arithmetically correct.

The actual mechanism sits below the model. The identity API accepts a deactivation request asynchronously and returns a job identifier, not a completed deactivation. The tool wrapper converted every accepted request into the string success. Eight jobs later failed because the accounts were protected service identities; four were rejected by a downstream regional directory after the initial API had accepted them. The model observed 120 identical success-shaped messages because the harness erased the distinction between accepted and completed. It did not reason badly from the evidence. It was given false evidence.

First, the tool result becomes a typed state transition: accepted, with a job identifier and a resource identifier. It never says completed until the external system does. Second, the harness records those identifiers durably, so a crash between submission and polling does not lose the work or resubmit it (Chapter 5). Third, completion for this task is defined as 120 terminal job states, not 120 accepted requests. Fourth, protected identities become an ASK policy decision before submission rather than a late tool failure (Chapters 15 and 19).

The repaired trajectory submits 112 ordinary accounts, pauses on eight protected identities, receives a narrower approval for six of them, and leaves two unchanged. It then polls the 118 submitted jobs until 116 report completed and two report failed. Reference Agent retries one transient regional failure, escalates the persistent one, and reports the outcome as 117 deactivated, one failed, two deliberately unchanged. That answer is less fluent and more useful. It distinguishes what was requested, what was accepted, what took effect, and what remains unresolved.

The general lesson is that observation design constrains reasoning. “The model saw the tool result” proves nothing if the result collapsed a multi-stage external operation into a boolean. Agents are especially vulnerable because they use observations as premises for later decisions. A misleading result does not damage one line of output; it changes the remaining control flow.

There are five places to inspect before you change a prompt after an incident:

If the model chose correctly given the observation it received, telling it to “be more careful” adds tokens without restoring truth. The right repair is at the boundary that misrepresented the world. Chapter 13 builds result schemas, Chapter 22 handles partial failure, and Chapter 23 makes the lifecycle visible in a trace.

1.7What agents are actually good at#

Agents are good at tasks with an unpredictable path and a verifiable end. Debugging. Investigation. Research across many sources. Remediation from a symptom. What these share is that you cannot enumerate the steps in advance, and you can tell when the answer is right.

They are good at tasks where the work exceeds one context window and must be explored rather than read. Chapter 28’s research example: forty repositories, three wikis, a service catalogue.

They are good at long-tail work with high variance — where a workflow would need two hundred branches and the traffic is spread thinly across all of them.

And they are good at composition over existing systems, which is a large and under-appreciated category: pulling from four systems that have no integration, in a combination nobody built a report for.

They are bad, and Chapter 7 argues this at length, at tasks where you can enumerate the paths (write the workflow), where the input distribution is narrow (route to a handler), where latency is the product, where determinism is required, where the task is one tool call, and where you cannot state what done means — because an agent without a completion criterion runs until its budget expires.

The sharpest version of the trap: an agent used as a router. Every request paying for context assembly, a frontier model call and a trace, in order to produce one of four integers. Benchmark a constrained classifier against the loop on the same requests. A concentration of one-call trajectories is a reason to investigate routing, not proof that the agent adds no value.

1.8When agency is the wrong abstraction#

The strongest argument against building an agent is not that models make mistakes. Every production system makes mistakes. It is that runtime control flow introduces variance where your domain may need a stable, inspectable procedure. If the value comes from executing the same known steps correctly, agency is an expensive way to discard information you already possess.

Consider month-end invoice reconciliation. The established procedure is: load the ledger export, load the settlement export, join on invoice identifier, apply three documented tolerance rules, route four named exception classes, and produce a signed report. A team may describe this as “complex reasoning” because the spreadsheets are large and the exceptions matter. But complexity is not unpredictability. The path is known. Write it as a workflow, test each rule, and reserve a model for reading the small residue of genuinely unstructured exceptions.

The hybrid is usually stronger than either extreme. Suppose 10,000 invoices arrive each month. A deterministic join resolves 9,200. Explicit tolerance rules resolve another 600. A classifier routes 150 into four known exception handlers. Fifty remain novel enough to require investigation. An all-agent design spends runtime reasoning on 10,000 items. The hybrid spends it on 50 — 0.5% of the workload — while keeping the other 99.5% on paths whose behaviour you can enumerate.

Use illustrative unit costs to expose the decision. Assume the deterministic path costs £0.002 per invoice, classification costs £0.01 for each of the 200 unresolved after rules, and an agent investigation costs £0.80 for each of the final 50. The hybrid costs:

(10,000 × £0.002) + (200 × £0.01) + (50 × £0.80) = £62

An all-agent path at £0.80 per invoice costs £8,000. Even if batching and shorter easy trajectories cut the all-agent average to £0.20, it still costs £2,000. These figures are illustrative, but the ratio tells you where to look: pay for runtime discretion only on the residue that needs it. Chapter 7 gives the orchestration patterns for this split; Chapter 29 turns it into a rollout sequence.

Use a workflow when the procedure is itself evidence. A regulated calculation, a payroll run, or an access-removal checklist may need to prove that every prescribed step occurred. An agent can be traced, but a trace of runtime choices is not the same thing as conformance to a required procedure. Put the procedure in code and let the model help with inputs or exceptions.

Use a query when the answer already has a schema. “Show open invoices older than 60 days” is not an investigation merely because the user asked in natural language. Translate the request into a constrained query, validate it, run it, and render the rows. Adding a loop creates more places to be wrong without adding capability.

Use a classifier when the output is one of a fixed set. If the next action always belongs to one of six handlers, the open-ended agent loop is not buying discovery. It is hiding routing accuracy inside a larger system whose failures are harder to isolate.

Use a human-led tool when judgement is the product. In hiring, clinical care, disciplinary action and other consequential decisions, the goal is not merely to reach a verifiable state. The accountable person’s deliberation is part of the process. An assistant may gather evidence, check completeness and draft alternatives; giving it control of the path can quietly turn support into delegation.

Use no automation when the volume cannot repay the control surface. A rare task with high blast radius still needs permissions, audit, recovery, evaluation and on-call ownership if an agent performs it. Ten manual cases a month may be cheaper and safer than maintaining that harness. “The model can do it” is a capability statement, not an investment case.

The counter-argument also runs in the other direction. A workflow with hundreds of brittle branches is not automatically safer because its control flow is deterministic. If inputs continually fall outside the designed cases, engineers become the hidden runtime planner: reading failures, editing rules, rerunning jobs and handling exceptions by hand. That is agency performed slowly through the ticket queue. The correct boundary is empirical.

Measure three distributions by task family:

• path diversity — how many distinct action sequences appear, and how quickly new ones continue to appear;
• exception residue — what proportion remains after deterministic rules and narrow models have done their work;
• verification coverage — what proportion of outcomes can be checked independently of the process that produced them.

High path diversity, a material exception residue and strong verification coverage favour an agent. Low diversity, a small residue or weak verification favour a workflow, a specialist model, a human, or no automation. Do not average across task families: “research a competitor” and “disable an account” may enter through the same Reference Agent interface and deserve completely different positions on the agency spectrum.

1.9Reference Agent#

Reference Agent is a general-purpose enterprise work agent.

It is always on, reachable by text and by voice, and deployed multi-tenant inside a company. It does research, document work, data pulls, code changes and operational tasks. Speech-to-text and text-to-speech are existing infrastructure it consumes; its reasoning core is textual, which means voice changes its latency budget and interaction design profoundly and the core loop design less directly; transcription errors and missing vocal cues can still change its reasoning — a distinction Chapter 18 makes concrete.