Patterns That Hold Up

You will forget which model you used. You will not forget the shape of the system you built around it. Build the shapes that outlast the models.

The last chapter made a single model call legible — its cost, its speed, its limits. This chapter is about everything you build around that call, and it opens with a warning: the field will throw a new framework at you roughly every month, and chasing them is a treadmill that produces motion without progress.

So this chapter teaches patterns, not frameworks. A pattern is a shape — a way of arranging model calls, tools, and data that keeps making sense even when the model underneath doubles in capability and the framework you used to implement it is deprecated. Learn the shapes and every framework, or none, becomes legible. That is how you build things that survive the next release instead of rebuilding them for it.

Patterns over frameworks

Start from the primitive you already understand: the single call. One input, one output, done. Everything in this chapter is composition on top of that — chaining calls together, giving them tools, grounding them in your data, letting them loop. Nothing here is exotic. It’s arrangement.

The reason to think in patterns rather than frameworks is durability. Frameworks are implementations; they come, they get popular, they get abandoned, they get replaced by the next one that does the same thing with different names. The popular agent frameworks of this year are useful, and you may well use one — but the value they encode is a handful of patterns you can name in an afternoon. Learn the patterns and a framework becomes a convenience rather than a dependency; you can pick one up, put it down, or swap it, because you understand the shape it’s implementing. This is Chapter 3’s anti-lock-in instinct pointed at your application layer instead of your model.

There’s a lens that runs through the whole chapter: durable versus hype. A pattern holds up if it still makes sense after the model got twice as good and the framework got deprecated. Most of what gets marketed as “the future of AI” is a framework or a product. Most of what actually holds up is a small set of patterns — and the discipline to reach for the simplest one that works.

Context engineering

The first pattern is really a discipline, and it has quietly renamed itself, which tells you something.

For three years the hyped skill was prompt engineering — crafting the perfect instruction. That skill has been largely absorbed into a broader one the field now calls context engineering: the deliberate design of everything the model sees on every single call. The models got good enough at reading intent that clever phrasing matters less than it did; what matters now is what information is in the window when the model runs.

The framing that stuck is an analogy: the model is a CPU, and the context window is its RAM. Your job is to be the operating system — loading exactly the right working memory for each task and nothing else. And “everything the model sees” is more than the prompt. It’s the system instructions and the output contract, the user’s input, the documents you retrieved, the conversation history, the definitions of the tools it can call, and anything it has remembered from before. Context engineering is the deliberate assembly of all of that, per call.

Here is the diagnosis that makes this the central skill: in production, most failures are no longer model failures — they’re context failures. The model was capable; it just wasn’t given the right things to see. The asymmetry proves it. A brilliant prompt sitting in a poorly assembled context still fails, while a mediocre prompt in a well-assembled context often succeeds. If failures live in context assembly, that’s where your engineering effort belongs.

There’s a compact way to think about the moves involved: write the instructions and state clearly; select the right context to bring in for this specific call; compress it so you’re not wasting tokens (which, from Chapter 5, is both a cost and a quality decision — remember context rot); and isolate unrelated context so it doesn’t distract the model. A governing principle sits underneath all four: just-in-time retrieval beats pre-loading everything. Don’t pour the whole world into the window and hope the model finds the relevant part. Decide what enters the attention span, and when.

This is the direct continuation of Chapter 5. There we learned the context window has an effective ceiling and quietly rots as you fill it. Context engineering is the discipline of building deliberately within that ceiling — and, per Chapter 4, of treating the assembled context as a versioned, testable asset rather than a string someone typed once.

Structured outputs: the contract at the boundary

The second pattern is the one that makes all the others composable, and it’s easy to underrate.

A raw model returns free-form text. That’s fine when a human reads it, and a disaster when code has to. Parse prose with hand-rolled heuristics and you’ve built your system’s most important seam out of guesswork — the exact place non-determinism does the most damage. The pattern that fixes this is the structured output: constrain the model to return data in a defined schema, typically JSON with specified fields and types, enforced so the shape is guaranteed. Providers now support this directly — schema-checked results your code can rely on.

What that buys you is bigger than convenience. It turns a probabilistic text generator into a component with a typed interface. The model can still be creative inside the fields, but the envelope around it is contractual. You’ve tamed non-determinism at precisely the point it matters most: the boundary where AI hands its output to the rest of your system. Everything downstream in this chapter — tools, pipelines, multi-step agents — depends on each step producing something the next step can consume without hoping. Structured output is the connective tissue that makes composition possible instead of fragile.

The working habit is the one you already use for any interface: define the contract first. Decide the fields, the types, and what “done” looks like, then build the call to fill it. Contract-first, exactly as you’d design an API — because that’s what you’re doing.

Tool use: hands, via an open standard

The third pattern gives the model the ability to act, not just talk. With tool use, the model can call a function, query a database, hit an API, or run code. The loop is simple: the model decides which tool to call and with what arguments, your code executes it, the result comes back, and the model continues with that result in hand. This is what turns a text box into something that can actually do work in your systems.

The mechanism underneath is function calling — the model emits a structured request to invoke a named tool with typed arguments. Notice that a tool call is a structured output, which is why the last section came first: tool use is structured output pointed at your systems.

What changed recently, and durably, is standardization. The Model Context Protocol — introduced by Anthropic in late 2024, since donated to the Linux Foundation and adopted across the major providers — is an open, vendor-neutral way for tools to describe themselves and for models to discover and invoke them. It’s often called “USB-C for AI.” Before it, every tool-to-model connection was bespoke; now a tool exposed once through the protocol works across models and hosts, and an agent’s tool layer becomes simply “the union of the tool servers it’s connected to.”

Three reasons this book cares about the open part specifically. First, lock-in: this is Chapter 3’s argument arriving at the tool layer — your integrations aren’t welded to one vendor’s proprietary format. Second, governance: it’s Chapter 4’s shift-left made concrete, because a standard tool layer is where you put audited, permissioned, least-privilege access to internal systems, instead of copy-pasted context or one-off connectors nobody reviews. Third, composition: standard tools snap together.

But hold the most important caveat firmly, because it’s where teams overspend and underdeliver: the protocol is integration, not intelligence. Connect a powerful tool to a vague prompt and you get an agent that has tools and doesn’t know when to use them. The capability comes from the tool; the competence comes from context engineering around it — naming the goal, spelling out which tool applies when, defining the output contract, and planning what happens when a tool fails. Integration and context engineering are a pair. Connectivity is not competence.

One flag for later: tools are power, and power needs least privilege and active defense against tool-targeted attacks. That’s Chapter 11’s territory; just don’t wire an agent to your production database on the strength of a demo.

Grounding: RAG as a pattern

The fourth pattern answers the two problems Chapter 5 left open. A model relying only on what it memorized during training is working from knowledge that is generic, frozen at a cutoff, and prone to confident invention — and stuffing everything it might need into the window just triggers context rot. Grounding fixes both. Instead of trusting the model’s memory, you retrieve the relevant information at query time, place it in the context, and then generate. Retrieve, then generate — commonly known as retrieval-augmented generation, or RAG.

This is the answer to hallucination, because the response is anchored to real sources you can cite. It’s the answer to context rot, because you bring in only what’s relevant rather than everything. And it’s how you give a model access to your private, current, proprietary data without retraining anything. The shape is straightforward: a query arrives, you find the relevant pieces of your data, you assemble them into the context, and the model answers grounded in them — ideally citing what it used.

There’s a natural marriage with the previous pattern: retrieval as a tool call. Rather than always pre-fetching, you can let the model decide when it needs to look something up and what to look for — retrieval becomes just another tool in the union. This “agentic RAG” is increasingly the default shape.

Grounding is where most genuinely useful enterprise AI lives, which is why it gets its own chapter. Here it’s enough to hold it as a first-class pattern; the mechanics — how you turn documents into something retrievable, how you keep it fresh, how you govern it — are Chapter 7.

Workflows and agents: the progression, and the discipline

Now the pattern everyone is shouting about, handled with the restraint the evidence demands.

There are two ways to build a multi-step AI system, and the difference is simply who holds the steering wheel. In a workflow, you define the control flow in code, with model calls at specific steps. It’s predictable, testable, cheaper, and traceable, because you decided the path. In an agent, the model decides what to do next at runtime. It’s flexible and handles genuinely novel situations, but it’s harder to control, more expensive, and less predictable, because you handed it the wheel. Both are “agentic systems.” The engineering implications are worlds apart.

The rule that has held up through a year of hype is conservative, and you should adopt it as a default: start with workflows, and graduate to agents only when the task genuinely requires dynamic decision-making that you cannot express as a fixed flow. Most real systems settle somewhere in between — structured enough to be reliable, flexible enough to absorb variance.

The workflows themselves are built from a small kit of composable patterns worth knowing by name. Prompt chaining breaks a task into a sequence of steps, each feeding the next — the simplest pattern, and often the right first choice. Routing classifies the input and sends it down the appropriate path or to the appropriate model — the multi-model routing of Chapters 3 and 5, now as an application pattern. Parallelization runs independent subtasks at once and aggregates them. Orchestrator-workers has a lead call decompose a job into subtasks dispatched to worker calls. Evaluator-optimizer pairs a call that generates with a call that critiques and improves, a feedback loop. On top of these sit capability patterns: reflection, where the model critiques its own work; planning, where it plans before executing; and multi-agent collaboration, where specialists cooperate — which you add only when specialization clearly helps, not because a framework makes spawning agents easy.

One insight is worth internalizing because it’s counterintuitive and it saves money: wrapping a weaker, cheaper model in the right loop — reflection, verification, a second pass — can outperform a stronger model used in a single shot. Often the loop, not the model, is the lever.

To keep yourself honest, design in three layers. Workflow patterns decide how the system thinks and executes. Capability patterns extend what it can know and do — tools, memory, retrieval. Production patterns keep it safe and reliable — guardrails, human-in-the-loop at high stakes, verification, retries, circuit breakers, bounded execution, and tracing on from day one. An impressive prototype has the first two layers. A system that survives production has all three, and the gap between them is exactly where most pilots die.

Which brings us to the discipline at the heart of this whole chapter: introduce complexity only in response to a real failure mode, and use the minimum control mechanism that addresses it. Don’t add an agent because a framework makes it a one-liner. Don’t add a second agent unless specialization demonstrably helps. Every moving part you add is a part that can fail and must be observed and debugged. Complexity should be earned by a problem, not adopted for a demo.

Because here is the uncomfortable truth about the loudest story of 2026: agents mostly fail in production not because the model was too weak, but because the system had no structure — which is why a large share of agentic projects are forecast to be cancelled before they deliver anything. The maxim that emerged from the teams who actually shipped is “agents aren’t hard; the harness is hard.” The harness — the constraints, the vetted tools, the verification, the observability, the recovery paths — is the real work. And that harness is nothing other than the engineering discipline this entire book is about. Building the agent is a weekend. Building the harness that lets it run on Monday is the job. Deploying that harness is Chapter 8; proving it works and debugging it when it doesn’t is Chapter 9.

The patterns, in the end, are few and stable. The skill is knowing which one a problem actually needs — and having the restraint not to reach for more than that. That restraint is not timidity. It’s the thing that makes AI which survives contact with reality.