2.1 The Agent Stack

A language model alone gives probabilistic recommendations. A harness turns some of them into actions. A governed engineering environment interposes between capability and consequence: it decides which recommendations become actions, and which actions become the system. Part 1 derived why the substrate demands that interposition; this Part builds it.

The building material comes in three kinds. Soft conditioning aims the reasoner — prompts, briefs, models, examples, playbooks. Hard authority binds it — tool interfaces, permissions, schemas, lints, gates, validators. Feedback closes the loop — results made machine-legible, so the agent can repair its own miss. In one line: soft guidance goes in, deterministic guardrails constrain the actions, and a deterministic envelope governs what gets admitted out.

If governing an agent means conditioning where it searches, the practical question follows at once: where do you reach in to do it? There are four places, stacked one atop another, and each gives you a different kind of grip. Once you understand the stack, every mechanism in this book resolves into the same move: pick a layer, inject a constraint. Figure 2.1-1 draws the stack; this chapter walks it from the bottom up.

2.1.1 First, four definitions

Before the walk, I owe you four definitions — engineering, software engineering, agent, and model — and, before we leave them, one adjective the last of them will come to lean on: structured. Ordinary words, all of them, and every reader arrives with a working sense of each. But this book derives its argument from these definitions and the relations between them, so a working sense will not carry the weight. Let us fix them now. The stack will keep.

Engineering. The discipline of developing operable technological artifacts to solve problems, and of analytically identifying and assessing the competing means to those solutions, each with distinct trade-offs.

Take the definition in halves. The first half says engineering produces something that works: a technological artifact, with human operators, addressing a real problem. The second half separates the engineer from the technician: if you cannot articulate the trade-offs, you are not engineering — you are a technician. An engineer weighs competing architectures and designs against the properties the solution must have.

A third property hides inside "analytically assessing": an engineer can model and predict the outcomes of the decisions they are about to make, from the architecture and design they propose, prior to building. Prediction-before-construction is the engineering move. Hold onto it, because the definition of model below exists to serve it.

Software engineering. Software development produces a functioning artifact. Software engineering predictively selects a software artifact according to its desired properties.

Development asks: does it function, and does it meet the requirements? Engineering asks: of the artifacts that would function, which one ought we build, given the properties we want? — and answers before building it. That is why this is a book about software engineering and not software development. And agents sharpen the distinction rather than blunting it: when implementation is cheap, you can afford to build more than one — in Fred Brooks's words, to build one to throw away — and to select among them. Selection needs a basis for prediction, and the basis is a model.

Agent. A controllable intelligence capable of independent reasoning over a knowledge base.

Intelligence I will not attempt to define in full; a working sense will do. Given a set of constraints and a goal, an intelligence can devise a means of satisfying the goal without violating the constraints. Think of a raven dropping pebbles into a jar to raise the water high enough to drink. Goal: a drink. Constraint: the beak cannot reach the bottom. Means: pebbles. A raven Archimedes. Eureka.

Controllable is the adjective everything else in this book hangs on, and it does not say controlled. A controllable intelligence responds to its handler: change its environment and the knowledge available to it and it does different things, and it will generally follow orders. But controlled means perfect guarantees of behavior, where controllable means probabilistic ones. The stronger your mechanisms, the tighter the distribution — never a guarantee. That one adjective is why governance takes up so much of this book. If agents were controlled, we would not need the governance at all.

Independent reasoning rules out the parlor trick. The agent genuinely reasons in response to a query; it is not retrieving stored answers, and it is not pattern-matching its way to something that merely looks like one. (The next section takes up the evidence for this claim, and the evidence is stronger than you might expect.) Finally, the knowledge base names the thing it reasons over. For this book, that clause is the hinge: the models are the knowledge base.

A footnote for the reader with a textbook nearby. This definition departs from Russell and Norvig deliberately. For them, an agent is anything that perceives its environment through sensors and acts on it through actuators, and a rational agent acts to maximize an expected performance measure. That perceive-and-act framing is the right one for building an agent. This book is about governing one, so it foregrounds a different property: controllability, in the cybernetic sense of behavior you can steer but not perfectly determine. The gap between controllable and controlled is no hedge. It is the reason this book exists.

Model, first pass. A useful approximation of a phenomenon — simplified, but good enough to predict — and, as this book uses the word, a blueprint: a prescriptive description of a system to be built, which the built system is bound to realize. The formal definition arrives once its last ingredient, structured, is on the table.

The reader likely knows the first sense already: a model as a simplified description, prized because it predicts, not because it is exact. Think f = ma, which neglects friction and is useful anyway; George Box's aphorism — all models are wrong, some are useful — is the canonical statement. Models in this sense come in kinds: mathematical, qualitative, relational, data-flow. And their fidelity trades against cost: the coarser the model, the cheaper it is to reason about, and yet the wider the error bars on what the reasoning tells you. How much fidelity you need is in the eye of the application. "It processes information serially" may do to sketch a system, while reasoning about security or privacy wants a model much closer to the real thing.

The second sense is the one I embed here. A blueprint does not approximate an existing building; it specifies one that does not yet exist, and the builder is bound to it. That is the sense this book leans on: a model as a prescriptive description of the system you intend to build. A system built to a model may elaborate on the model, but it may not diverge from it. (The approximation sense is Box's. The blueprint sense — a description that specifies rather than describes — is what semiotics calls signification, a sign standing for its object; blueprint is the engineer's word for it, and the one I use.)

The blueprint sense is what lets a model serve as an agent's marching orders. Handed to an agent, a model is three things at once: a constraint, bounding what may be built; a blueprint, saying what to build; and, because the agent reasons over it, the knowledge base for the artifact under construction.

One caution before moving on. In these pages the word does double duty: the foundation model at the bottom of the stack is itself a model in the first sense, a learned approximation of language and the world, while the models this book teaches you to write are blueprints in the second. Context will say which is meant.

And one adjective before we go, because every blueprint in this book carries it: structured.

Structured. Said of a model: written in an explicit, declared shape a machine can read and validate — a schema, not prose. The declared structure is what lets a machine hold the system up to the model: read the shape, check it for drift, query it, reason over it, enforce it. Prose can be a model; only a structured model can be checked.

The word is broader than a programming manual's typed. A variable has a type; that is the narrow sense, and type-checking is its sharpest case. The sense this book strains on is wider: the model has a shape, the shape is written down — fields, states, relations, all explicit — and a checker can validate any instance against it. Structured is the word I use, over typed, because it names that whole span. A type is one way to declare a shape; a schema, a state table, or a registry will do as well. Free prose fails the test not because it is vague but because a machine cannot act on it: it can pattern-match the words, but it cannot hold the code up to them and prove the two agree.

Watch what the adjective carries. Prose can be a model — simplified, predictive, even prescriptive; the first half of the model definition asks no more. But every promise this book makes about models — that they can be read, drift-checked, queried, reasoned over, enforced, that a gate stays red until the map tells the truth again — is a promise about structured models. The structure is what admits the machine. Drop the adjective and the drift gate has nothing to read; keep it and the model stops being documentation and becomes something the build can act on.

Drift gate. A build-time check that fails when a model and the code it describes disagree, so the model cannot silently go stale; Part 3 builds it in full.

The pieces are now on the table — a model approximates, a blueprint prescribes, structure admits the machine — and they assemble into the definition the rest of this book holds a candidate model to. The book will call many things models: registries, graphs, manifests, state machines, typed records, topology descriptions. The word needs a boundary, or everything structured gets the name and the claim dissolves. Here is the boundary.

Model. A deliberately reduced, machine-readable representation of system intent, structure, behavior, policy, or evidence that supports reasoning, derivation, or checking, and whose relationship to the implemented or observed system is mechanically maintained.

Every clause earns its place. Deliberately reduced excludes the codebase itself; the territory is not its own map. Machine-readable excludes ordinary prose. Of intent, structure, behavior, policy, or evidence names what is represented, so a data structure with no referent does not qualify. Supports reasoning, derivation, or checking demands the model do work. And mechanically maintained is the sharpest gate: a diagram nobody checks fails it the day the code moves. The next chapter builds that last clause into a discipline, and Part 3 admits a whole zoo of representations because each clears all five.

Now hold the four together, because the relations between them tell you the whole book in a nutshell. Engineers love models: prediction without excess cost is their bread and butter. An agent is a controllable reasoner in want of a knowledge base, and a model is a knowledge base that constrains and specifies. Hand one to the other and you have the method. The book's job, then, is fourfold: to describe the kinds of models useful to agents; to show how agents interact with them; to keep the models consistent with the artifact as it is built; and to help engineers construct models, assess them, and use them to predict prior to construction. So much for definitions. Now, the stack.

2.1.2 The four layers

At the bottom sits the foundation model. It comes from a commercial vendor or an open-weight release, and it is a general language reasoner, able to induce an understanding of your environment — though that induction is expensive, and it happens fresh every time. The game at this layer, then, is to spare the model that cost: tell it, up front, where to look. Sometimes you tell it deterministically, with an executable program; sometimes softly, with written-down pseudocode — the algorithm to follow, the playbook for a root-cause analysis; often it is a hybrid of the two. The more reasoning you hand the model up front, the shorter the chain it must construct on its own — and the shorter the chain, the less likely it is to go wrong along the way. If each step goes right with probability 1 − p, an n-step chain reaches the end intact only with probability (1 − p)ⁿ, so the chance of a wrong answer climbs with every step you did not spare it:

P(wrong) = 1 − (1 − p)ⁿ

Every stretch of reasoning you hand the model, rather than making it re-derive, is one fewer step in n; the error probability falls with it.

What you control in the model. The foundation model has three parts, and you steer each one differently.

• Its reasoning is a grade you buy. Pick the tier, and size each task to a model that can reach the end of its chain — or let the orchestrator route the task to the model that fits.
• Its training data you do not touch. This book assumes you run the model as it ships. Bending the weights to your domain is a real lever, but a resource-intensive one, and in the main it is much more cost-effective to optimize the context window and revisit at the next generation of foundation models. (A later chapter treats training data as the novelty axis: how far your system sits from what the model has seen decides how hard you must condition it.)
• Its context window is fixed the moment you choose the model. You cannot buy more of it. What you can change is how much meaning each token carries.

So the window bounds the fleet — but not the way it first looks. You cannot widen it; you can pack it denser. A model is a higher-abstraction representation, more meaning per token, so the same window holds more of the system. That is the Modeling Thesis (derived in Why MAGE Follows from the Machine) aimed straight at the window bound: the fleet scales on two capacities, its reasoning grade and its window.

To the extent you control model choice, make it; if you have the resources to tune, it may help. But this book's position is that controlling the context window is the key, and modeling is the path we take.

This whole layer rests on one claim: the model reasons. It is not retrieving stored answers or matching surface patterns — it builds an internal model of the world it is working in and reasons over it. Think of a model trained only on the move sequences of the board game Othello. Nowhere in its training does it see a board; it sees strings of moves and nothing else. Yet interpretability work found a recoverable representation of the board state living inside the network. More telling still, the model does not merely read out that representation; it causally intervenes on it. Flip the encoded state of a square and the model's predictions change to match the altered board, exactly as they would if you had made a real move. The representation drives the behavior. This is the Othello-GPT "emergent world representations" work ¹1. Kenneth Li et al., “Emergent World Representations: Exploring a Sequence Model Trained on a Synthetic Task,” 2022, https://arxiv.org/abs/2210.13382., and it is one example, not a lone toy: follow-up work generalized the finding — probing and steering learned world-models — across setting after setting, and it agrees with what anyone who works with these models day to day already sees. So we treat the model as a reasoner, because it is one, and the job at this layer is to equip it to reason well — to supply the context it needs so its reasoning starts from your world instead of a guessed one. Equipping it is a concrete act: you package that context as a skill, a body of knowledge and judgment the model reaches for. Appendix E gives the recipe for building one.

On top of the model sits the agentic harness — Claude Code, OpenCode, and their kin. The harness takes your prompts, feeds them to the model, and manages the context window: the fixed budget of tokens the model can hold. Exceed the budget and the harness must compact — a lossy compression of everything that has happened so far. The harness is also where two of the most useful mechanism points live, and the line between them is sharp: a hook is a thing the agent has to do; a skill is a thing it can choose to do.

The field has begun to name this layer with some care. A working taxonomy separates the framework that composes agents and tools from the harness, the full runtime around an agent — context, memory, permissions, failure recovery, verification — and from a broader agent OS that schedules and allocates across the whole stack ²2. Gurbinder Gill, “The Rise of the Agent OS: Comparing Harnesses, Runtimes, And Orchestration Layers for LLM Agents,” LinkedIn, July 15, 2026, https://www.linkedin.com/pulse/rise-agent-os-comparing-harnesses-runtimes-layers-llm-gurbinder-gill-72c9c/.³3. Aishwarya Naresh Reganti, “The AI Agent Stack in 2026,” The Nuanced Perspective, April 29, 2026, https://thenuancedperspective.substack.com/p/the-ai-agent-stack-in-2026.. The analogy that keeps returning is exactly that: the harness is the operating system, supplying the interrupts and interfaces to the outside world and managing the agent's processes and memory ⁴4. Han Lee, “Hidden Technical Debt of AI Systems: Agent Harness,” May 8, 2026, https://leehanchung.github.io/blogs/2026/05/08/hidden-technical-debt-agent-harness/.. Meta-harnesses now sit above several such runtimes and orchestrate across them ⁵5. Matei Zaharia et al., “Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents,” Databricks, June 13, 2026, https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents.. This book says harness for the runtime layer throughout, and treats the agent OS as the same idea drawn wider.

• Skills are soft mechanisms. A skill has trigger criteria and a body of guidance: "about to touch a PDF? enter this skill." Inside, it holds instructions — pure prose ("be careful editing PDFs"), or a mix of prose and code. The code half is a tool: a library or command-line entry point that lets the model take a deterministic action — add a page, delete a page, rewrite a run of text — instead of guessing.
• Hooks are hard mechanisms. Before or after the harness does something — passing a prompt, dispatching a sub-agent, calling a tool — you can run a deterministic program that inspects the action and, if it likes, forbids it. A hook can look at an outbound network call and refuse it; catch an email about to go out with a typo, or with sensitive information in it, and block the send. Run after the fact, the same hook logs what happened. Either way, you hold authoritative control over the agent's behavior at the moment it acts.

Above the harness sits the engineering environment — the tools and conventions your team already uses. Jira holds the tickets. Git holds the code. A named server is where you deploy; a named node is the head of your compute cluster. Engineers carry all of this in their heads, of course; an agent arrives with none of it, so for agents it must be written down. This layer also holds your processes: the standard operating procedures for handling a bug report, running a design review, triaging an incident. And it, too, offers a concrete injection point. Git has hooks on every command — before and after commit, pull, push. The classic use is a pre-commit hook that runs a fast quality check before a change is allowed into the tree, moving feedback as far left as it will go. Above that, your CI pipeline is another set of stages where mechanisms attach.

Learn more about this governance mechanism: pre-commit hook.

At the top sits your application — the product code itself, which can carry governance of its own: models describing how it is supposed to work, and static analyses that check the code against them. A static analysis at this layer is where a whole class of mistakes can be made structurally impossible. The companion catalogue's sharpest examples live here: a ban-lint that routes all mutation of a document format through a single structured model, so that no agent can reach the raw library and silently corrupt the file. The rule is enforced once, at the one gateway, and it holds for every agent that ever touches that code.

Learn more about this governance mechanism: one structured model per format.

2.1.3 Every layer is a place to steer

Read the stack as a list of opportunities, because that is what it is. The harness noticing it is near its context limit and writing out a reliable summary of state and plan, instead of waiting for a lossy compaction, is an opportunity to help the model reconstruct less after the window resets. The pre-commit hook is an opportunity to catch a defect while everything that produced it is still fresh in the model's window, rather than surfacing it from a failed test three compactions later. The CI pipeline turning a failure into a message the agent can read is an opportunity to point it back toward the fix.

The single goal underneath all of it never changes. At every layer, you are trying to prevent the agent from making a bad choice, and to narrow its search toward the choices you want. This matters more than it first appears, because the context window is too small to hold any serious system — think of the US tax code, or a real web application — all at once. Give the model no structure and it must induce the structure as it goes, burning most of its window just working out the rules of the road; the more structure you hand it, the more of that window is left for the work itself. Every mechanism you place on the stack is a rule of the road you handed it for free.

One thing the stack does not show: the mechanisms you install at these layers do not act in isolation. They run together, and the interactions between them have to be governed too — two that touch the same thing at the same moment pull against each other and confuse the very agent they were meant to steer. Governing each layer is not enough; the interplay is its own problem, and a later chapter takes it up.

The stack is where the two theses get their footing. A model handed to a layer enacts the Modeling Thesis; a hook or lint installed at a layer enacts the Alignment Thesis (derived alongside the Modeling Thesis in Part 1). The two chapters that follow take one thesis each.