Chapter 1The nature of agentic systems

Software architecture is undergoing a structural shift. Traditional systems are built on deterministic control flow: explicit logic, predefined transitions, predictable state transformations. Agentic systems do not abandon any of this. They introduce a probabilistic reasoning layer inside the deterministic shell. Portions of the control flow are no longer fully encoded ahead of time, they are generated dynamically by reasoning components operating toward goals.

This is the architectural definition the rest of the book works from. It is not a marketing claim. It is a structural commitment with cost: the moment any control decision is made by a probabilistic component, the system has to be designed differently from a deterministic one. The book is about what those differences are and how to manage them.

The shift is comparable in scale to two earlier transitions in software architecture. The first was the move from monolithic, transactional, single-machine applications to distributed systems with partial failure, eventual consistency, and asynchronous communication. The pattern languages of that transition, represented best by Designing Data-Intensive Applications, addressed concerns that did not exist in the prior world: split-brain failures, message reordering, retry storms, consistency models. The second was the move from desktop applications with full local state to web applications with stateless servers and rich clients, which produced its own architectural literature on session management, caching, and idempotent design.

The third transition is now underway. The novel architectural concern is not distribution or statelessness; it is that some control decisions are made by a component whose behavior is not fully described at design time. The component is correct most of the time, plausible nearly all of the time, and occasionally wrong in ways that are hard to anticipate. The literature on how to build reliable systems around such components is still being written. This book is one entry in it.

What “agentic” names

The word agentic has been used to describe anything from a chat interface with a function-calling capability to a multi-agent swarm composing services through emergent negotiation. In this book the term names systems with two defining properties:

  1. They contain at least one agent as formally defined in Chapter 2.

  2. The agent’s decisions affect control flow, what runs, in what order, with what arguments, not only the content of an output.

To those two descriptive properties the book adds two architectural commitments, the claims it spends most of its length defending:

  1. The agent operates inside deterministic infrastructure that provides durable state, tool adapters, policy enforcement, and observability.

  2. The agent’s loop is bounded by explicit limits on iterations, cost, and risk, enforced from outside the agent itself.

The split between the two pairs is deliberate. Properties 1 and 2 are descriptive: they tell a reader whether the patterns in this book apply to their system at all. Commitments 3 and 4 are normative: they are the book’s thesis about what such a system needs to be reliable in production. A system with properties 1 and 2 but without commitments 3 and 4 is not a non-agentic system, it is an unbounded, ungoverned one, which is precisely the subject of the failure-mode catalog (Chapter 11) and the retrofitting guidance (Chapter 18), not a counterexample to the book.

The descriptive properties still do real work at the boundary. A pipeline that runs a model as a single deterministic step is not an agentic system, it is a workflow with a probabilistic component, because the model produces content, not control flow (property 2 is absent). A model that calls tools but carries no state across turns is closer to a stateless router than to an agent (property 1 is absent; see Chapter 2). Each is a useful construction, but the patterns that govern it are not the patterns of agentic systems, and applying them adds ceremony without benefit.

This narrowing matters because the patterns in the book are not free. Each pattern carries an implementation cost, an operational cost, and a cognitive load on the team. Applying them to systems that are not genuinely agentic produces complexity without payoff. Applying them late, after the system is already in production, produces incidents. The narrowing is also a service to the reader: a senior engineer reading the book should be able to ask, of their system, whether it has the two defining properties, and to receive a clear answer that determines whether the rest of the book applies.

The probabilistic layer inside the deterministic shell

The defining structural fact of an agentic system is that one or more decision points in the control flow are made by a probabilistic component: the model, not a static routing table, decides whether to call a tool or ask a human, whether to retry a failed step or route around it, and whether the task is finished. Everything else follows.

In a deterministic service, control flow is statically describable. Given an input, the path through the code can be enumerated. Errors are exceptional cases, situations the designer anticipated and handled. Tests assert exact outputs. Tracing is for diagnostics, not for design correctness. The hard parts of the system are about scale, latency, and correctness under concurrency; the patterns are about persistence, queuing, replication, and consistency.

In an agentic system, control flow is partially synthesized at runtime. Given an input, the path through the system is one of many possible paths, chosen by the reasoning component based on state, goal, tools, and prompt. The system can still be described, but the description is now over distributions of paths, not single paths. Errors are not exceptional, they are part of the operating profile. Tests assert properties (boundedness, policy compliance, action safety) more often than exact outputs. Tracing is now structural, it is the only complete record of what the system actually did, because the system’s behavior cannot be fully derived from its inputs and code.

This is the architectural reframing the book asks the reader to internalize. Once a probabilistic component is on the control-flow path, the surrounding system must:

Each of these is a deliberate engineering choice with a cost. None are optional in a reliable agentic system. The cost compounds, a small system that violates one or two of these can survive on luck and careful design; a system at scale violates them at its peril, and the operating bill is paid in incidents.

Why existing software patterns are insufficient

The Gang of Four, Fowler, and the data-intensive-systems literature describe patterns for deterministic systems. They remain valid for the deterministic substrate of an agentic system, the data stores, the queues, the API adapters, the transaction boundaries. They do not, however, cover the part of the system where the control flow is generated by a probabilistic component.

The shortfall has a specific shape:

Patterns for deterministic flow assume the decision-maker is known at design time. In an agentic system the decision-maker is a language model whose behavior can shift between releases. Architectural commitments must therefore be conservative about what the decision-maker is responsible for, and where the deterministic substrate is responsible for enforcing limits. The patterns of the deterministic literature assume “the application decides”; the patterns of the agentic literature assume “the model decides, within bounds the application enforces.”

Patterns for deterministic state assume a finite, enumerable state machine, a fixed set of states with predefined transitions between them. In an agentic system the transitions are open: the model can synthesize novel actions, combinations, and sequences, producing paths through the system that the designer never encoded. A deterministic application’s state space may itself be effectively infinite, any system that accepts free-form input has one, so the distinguishing problem is not the size of that space but the open set of transitions across it. Architectural commitments must therefore bound the envelope of permitted transitions rather than enumerate them. A bounded agent is not described by a finite state machine, it is described by a finite set of constraints, and the path it takes within them is open.

Patterns for deterministic error handling assume the failure modes are known. In an agentic system failure modes can emerge from the interaction between the model and the tools, and can vary by model version. A model upgrade can change which prompts are reliable and which fail subtly. The literature on testing such systems is younger than the literature on deterministic testing and accommodates this reality with replay-driven and property-based techniques (Chapter 12). The book devotes Chapter 11 to the taxonomy of failure modes specific to agentic systems.

Patterns for deterministic auditability assume reconstruction is straightforward. A deterministic system’s behavior can be reconstructed from its inputs and code; an agentic system’s cannot. Even with a pinned model version and temperature set to zero, provider-side nondeterminism and silent model updates mean the same inputs need not reproduce the same behavior, so the output is not reliably a function of the visible inputs. The trace becomes the system of record, not an auxiliary log; without it, an incident is unreconstructable.

The contribution of agentic design patterns is not to replace deterministic patterns. It is to add the layer above them that turns a probabilistic component into a system property: bounded, governable, observable, replayable. The deterministic patterns are still required underneath; they are not sufficient on their own.

A note on reasoning models and pattern erosion

The patterns of agentic systems fall into two categories that are easy to conflate. Cognitive patterns govern how a model reasons inside a single agent, how it is prompted to plan, act, reflect, and self-critique. Architectural patterns govern the system around the model, how it bounds, governs, persists, and observes that reasoning. The distinction matters because the two are moving in opposite directions, and the rest of this section is about that divergence.

Between 2024 and 2026 the architectural relevance of several once-canonical agentic patterns shifted. Patterns originally proposed as scaffolding around weaker models, explicit ReAct loops, externalized Plan–Execute, hand-rolled reflection cycles, have been partially absorbed into the models themselves. A modern reasoning model emits intermediate thought structure, plans across long horizons, and self-critiques without external orchestration code.

This does not make those patterns wrong. It moves them. What was once an architectural concern (writing the loop) is now a model concern (the loop is internal). What remains architectural is everything around the loop: bounding it, governing it, persisting its state, observing it, and recovering from its failures. That deterministic envelope around the loop is the harness, the term this book uses for the program that turns a model into an agent. Chapter 4 introduces it; Chapter 19 designs it in full.

The implication for the rest of the book is that emphasis goes to the structural patterns, bounded autonomy, governance, memory, skills, anti-patterns, trace discipline, and the cognitive layer is treated briefly, with deference to canonical sources for the patterns themselves. This is a deliberate response to the field as it stands in 2026, not an editorial omission.

There is also a forward-looking reading of this erosion: as models continue to internalize reasoning patterns, the architectural surface around agents stabilizes while the cognitive surface inside them keeps changing. A book that cataloged cognitive patterns at full depth would date quickly; a book that develops the architectural discipline, what is around the model, has a longer shelf life. The book is structured accordingly.

What this book does, and what it does not

The book defines an agent (Chapter 2), names the forces that agentic patterns must balance (Chapter 3), maps the cognitive layer briefly in Chapter 4, then proceeds through architecture (Part II), production discipline (Part III), and synthesis (Part IV). It treats the cognitive layer briefly because canonical sources cover that ground. It treats bounded autonomy, governance, the ingestion pipeline, the glass layer, enterprise SaaS integration, model routing, anti-patterns, trace discipline, and the Skills layer at depth because those are the topics where the existing literature is thin.

The book does not:

The book does:

A worked example: Concord

The book accompanies its architectural development with a single worked example, threaded throughout: Concord, a coding-assistant agent. Concord helps engineers make changes to a codebase: given a task (implement a feature, fix a bug, refactor a module), it proposes a change, runs the project’s tests against it, and submits the change for human review. It operates in a sandbox; it never commits, pushes, or deploys without explicit human approval.

Concord exists in this book for two reasons. First, the coding-assistant shape is the most widely-deployed class of agentic system in 2026, readers will recognize it. Second, Concord exercises the core architectural concerns the book develops: bounded autonomy on all six axes, a load-bearing governance layer, tiered memory, control structure, the Skills layer, failure-mode defenses, trace discipline, and operational practice. By Chapter 17 the reader will have seen Concord developed end-to-end with concrete artifacts (bounding YAML, governance pseudocode, skill manifests, trace excerpts, policy tables) that they can adapt to their own systems.

Concord is fictional. The shape is real and the artifacts are realistic. Where a chapter benefits from a concrete example, Concord is named; the full walkthrough is in Chapter 17.

Concord is the book’s single threaded example, chosen so that one system can be followed end to end as each layer is developed, but it is not the only concrete material. Chapter 16 sketches six other system shapes as vignettes (a research agent, a customer-support platform, an operations controller, and more), and Chapter 14 works through enterprise-integration scenarios in their own right. A reader whose system looks nothing like a coding assistant will find a closer match among those.

The shape of the argument

Chapter 2 fixes the term agent with a four-property definition and the boundary cases that the definition excludes. Chapter 3 names the architectural forces that agentic patterns must balance, the structural tensions that drive every later design decision.

Chapter 4 maps the cognitive layer in compressed form — deliberately brief, because erosion has moved much of it into the models — and introduces the harness concept. Chapters 5–10 develop the architectural discipline: bounded autonomy, governance, memory, the ingestion pipeline that feeds it, control and coordination, and the Skills layer. Chapter 5 and Chapter 6, in particular, are the load-bearing chapters of the book.

Chapters 11–15 turn to production discipline: failure modes, testing and trace discipline, the glass layer, enterprise SaaS integration, and model routing. Chapters 16–19 synthesize: system-architecture vignettes, the Concord worked example (Chapter 17), operationalization (Chapter 18), and the harness design (Chapter 19) that the earlier chapters attach to. The Glossary (Chapter 20) and Annotated Bibliography (Chapter 21) are reference; the bibliography is the single point of departure for readers who want the full hands-on or academic treatment of any pattern the book covers in compressed form.

Readers should expect to find themselves disagreeing with some of the book’s editorial positions. The book argues that multi-agent coordination is over-prescribed; that prompt-based governance is unreliable; that several once-canonical cognitive patterns have eroded; that Skills are subordinate to architecture rather than parallel to it. These are positions, not consensus. They are stated as positions so the reader can decide whether to accept them; where they hold, they shape what good architecture looks like, and the rest of the book follows.

The book’s core commitment The architectural commitment underlying the entire book can be stated in one sentence: probabilistic reasoning components are useful exactly insofar as their behavior can be bounded, governed, observed, and recovered from, by deterministic infrastructure around them. Everything that follows is an elaboration of that sentence.