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 keep all of that. What they add is 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, and it carries a cost the moment it is adopted. The instant 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 definition is a structural commitment. The commitment is what makes the patterns that follow necessary rather than ornamental.

A shift of this scale has happened before

The transition is comparable to earlier movements in software architecture, each of which produced its own pattern language for failure modes that had not existed in the prior world. The move from monolithic, transactional, single-machine applications to distributed systems brought partial failure, eventual consistency, and asynchronous communication. Its pattern language, represented best by Designing Data-Intensive Applications, addressed split-brain failures, message reordering, retry storms, and consistency models. The move from desktop applications with full local state to web applications with stateless servers and rich clients produced its own literature on session management, caching, and idempotent design. The pattern repeats across time-sharing, object orientation, virtualization, and cloud. A new class of failure appears, and the discipline takes a generation to catch up.

The transition now underway is of that kind. Its novel architectural concern 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 we mean by agentic

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 denotes 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. The properties are descriptive: they tell a reader whether the patterns in this book apply to their system at all. The commitments are normative: they are the book’s thesis about what such a system needs to be reliable in production. A system can satisfy both properties and still lack the commitments. It is then agentic, but unbounded and ungoverned, which is precisely the subject of the failure-mode catalog (Chapter 11) and the retrofitting guidance (Chapter 18).

The descriptive properties still do real work at the boundary. A pipeline that runs a model as a single deterministic step is a workflow with a probabilistic component: the model produces content without affecting control flow. A model that calls tools but carries no state across turns is closer to a stateless router than to an agent (see Chapter 2). Both constructions are useful. Applying agentic-system patterns to them adds ceremony without benefit because neither closes a stateful, goal-directed loop.

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 from that fact.

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, because it is the only complete record of what the system actually did. The system’s behavior cannot be fully derived from its inputs and code.

Once a probabilistic component is on the control-flow path, the surrounding system has five load-bearing concerns, and none is optional. Boundedness becomes an explicit property the harness must establish rather than a default of the runtime (Chapter 5). Governance, the validators, policy gates, and oversight that gate dispatch, becomes load-bearing structure instead of bolt-on safety (Chapter 6). State becomes a first-class memory architecture rather than a side effect of the prompt (Chapter 7). Failure modes become part of the design surface rather than bugs to be fixed after the fact (Chapter 11). Traces become the system of record rather than an auxiliary log (Chapter 12). Each is a deliberate engineering choice with a cost. The cost compounds. A small system that violates one or two can survive on luck; a system at scale that violates them pays in incident frequency and severity.

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 cover the part of the system where the control flow is generated by a probabilistic component.

The shortfall has a specific shape. Consider the decision-maker first. Deterministic patterns 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.”

State has a related gap. Deterministic patterns 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, since 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 finite set of constraints describes a bounded agent’s permissible behavior, while the path it takes within them remains open.

Error handling diverges in the same direction. Deterministic patterns 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.

Auditability breaks the same way. 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 but 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. 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 appear to have been partially absorbed into the models themselves. These include explicit ReAct loops, externalized Plan-Execute, and hand-rolled reflection cycles. A modern reasoning model emits intermediate thought structure, plans across long horizons, and self-critiques without external orchestration code. This is a field-state observation, not a defended claim: the dating is approximate, and the book cites the canonical pattern sources (Chapter 21) rather than asserting that it observed the migration.

That shift does not make the eroding 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. 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. A forward-looking reading of the erosion supports the choice: as models 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.

Scope and limits

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.

Frameworks and vendor SDKs appear only where unavoidable; the book endorses none of them. Patterns are architectural and outlive frameworks; naming the framework-of-the-month would date the book faster than anything else in it. Prompt engineering has its own fast-moving literature, so the book stays above the prompt layer. Gulli (2025) and the CSIRO catalog (2025) already enumerate the patterns; this book treats the subset that admits structural analysis and references the rest. The book treats autonomy as a means to reliable execution. The book consistently argues for less autonomy than the team is tempted to grant, and for bounding the rest. Safety depends on operating discipline as much as on architecture; the book provides the architectural substrate and points to the operational practice (Chapter 18), but no architecture is safety on its own.

The book does insist on a formal definition of agent that excludes a great many systems currently labeled as such. It places the governance layer on the path every consequential action traverses. It develops failure modes and trace discipline as architectural concerns. It places the Skills layer, dynamic capability loading, of which the agentskills.io standard is one implementation (Chapter 10), in its architectural context, and argues that skills remain subordinate to architecture. Where the literature is unclear or split, it states and defends its editorial positions.

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, and 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, but 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. It 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 to 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 to 15 turn to production discipline: failure modes, testing and trace discipline, the glass layer, enterprise SaaS integration, and model routing. Chapters 16 to 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 rather than consensus, 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.