What an Agent Is

A language model answers questions. An agent takes actions: it reads files, runs commands, calls services, and keeps going, deciding step by step what to do next until the work is done or something stops it.

Agent = Model + Harness

The model supplies reasoning. The harness is everything wrapped around it: which tools it may call, what enters its context window, when the loop stops, what happens on failure. Research supports treating the two as independent contributions to success; a study of agent performance found model capability and scaffold quality contribute additively, meaning a better harness lifts results without touching the model, and a weak harness wastes a strong model. A good rule of thumb is when an agent misbehaves, audit the harness before blaming the model. Part II is devoted to this layer; The Harness and the Agent-Computer Interface chapters carry the authoritative treatment.

The five levers

Everything you can change about an agent falls into five places:

1. Prompt: how the task and its constraints are stated. Covered next, in Instructing an Agent.
2. Model: the capability ceiling and the cost floor. Covered in Working With Models.
3. Context: what the agent knows at the moment it acts. Introduced here, treated fully in Context.
4. Tools: what actions are available and how they are described. Covered in Giving an Agent Tools.
5. Harness: the execution environment that contains the other four. The subject of Part II.

The weighting between them has shifted over time. When models were weak, model choice dominated. As frontier models converged in capability, the other levers took over: today two teams on the same model routinely get wildly different results, and the difference is almost always context, tools, and harness.

More is usually worse

The single most counter-intuitive lesson of the field: adding things degrades agents. More tools mean harder tool selection and wasted tokens. More context means the signal drowns; recall degrades as the window fills, a phenomenon covered properly in Runtime Context Management. More freedom means analysis paralysis. A focused agent with five tools, a dense context, and explicit constraints outperforms an agent with fifty tools and a dumped wiki. The design instinct to bring is subtraction.

The seven early mistakes

Nearly every team’s first agent fails the same seven ways. Stated once here so the rest of the book can build on them:

1. Unstructured context: pasting everything in and hoping. Context must be curated, not accumulated.
2. Trusting output without verification: agents declare success prematurely, and errors compound downstream. Verification is the deepest treatment of this in the book.
3. Tool flooding: every tool costs tokens and decision quality even when unused.
4. Vague prompts: “make it better” produces confident, arbitrary changes. Success criteria must be named.
5. Inconsistent structure: agents key on format; erratic formatting produces erratic behaviour.
6. Excessive freedom: unbounded option spaces stall agents. Constraints are what make autonomy usable.
7. Insufficient detail: relying on the agent to discover unstated requirements raises failure rates. Say what you know.