1 The agent paradigm shift

This chapter introduces a shift in how software is designed when an AI model, rather than a developer, chooses actions at runtime. It opens with the lesson that a seemingly reasonable agent can still make the wrong architectural choice, such as rebuilding an existing rollout utility instead of reusing the authoritative one. That example motivates the book’s central idea: building agents is not just about writing prompts or calling tools, but about designing the harness around the model so it can perceive the right context, make bounded decisions, use memory and tools safely, and produce results that are reliable inside a real system.

The chapter defines an agent as a language-model-driven software system operating within an engineered harness, and it contrasts this with ordinary pipelines whose control flow is fixed in advance. In agent systems, the model spends context, compute, and action opportunities, while the harness budgets and constrains those resources. The text also explains why classical design patterns do not fully transfer: their assumptions often place decision-making in the hands of the developer, whereas agent systems move those decisions into the runtime. This leads to a new vocabulary built around cognitive functions such as perception, memory, reasoning, action, reflection, collaboration, and governance.

The chapter further shows that agent engineering is shaped by three core uncertainties: output uncertainty, behavioral uncertainty, and environmental uncertainty. These conditions make agents more like distributed systems than traditional deterministic programs, so familiar ideas such as isolation, reconciliation, durable state, and budgets still matter, but must be adapted to probabilistic decision-making. The chapter closes by positioning the book as a practical guide for engineers through the Argus code review agent, where each chapter adds another capability, and by emphasizing that specification, constraints, and evaluation matter more than code alone when building trustworthy agent systems.

A deterministic pipeline has a fixed sequence, while an agent loop is a model-driven cycle in which reasoning and planning may interleave during execution.

How four GoF patterns break and what replaces them in agent systems.

Selected pattern lineages, from GoF through distributed systems to agent systems. The arrows trace recurring design pressures across distinct implementations.

The seven cognitive functions for processing a pull request review. The arrows show information flow. The dashed box shows governance controls reaching across the pipeline; the four governance patterns retain their matrix coordinates.

The two creations in agent engineering: specification as mental creation, running agent as physical creation.

• Agent architecture is bounded resource allocation under uncertainty: the model spends; the harness budgets.
• Agent systems introduce three fundamental uncertainties that break the assumptions underlying classical design patterns: output (same prompt, different responses), behavioral (agent selects its own strategy at runtime), and environmental (the world changes between observations). Treating uncertainty as the default operating condition is the paradigm shift.
• Agent design patterns inherit recurring engineering pressures from earlier systems. Cache hierarchies inform tiered memory, circuit breakers inform loop detectors, and saga transactions inform plan-and-execute workflows. The medium has changed from deterministic code to probabilistic language models, while the pressures recur. Experienced engineers already have the right intuitions. This book gives them the vocabulary to design, review, and communicate about agent architectures within their teams.
• The seven cognitive functions (perception, memory, reasoning, action, reflection, collaboration, and governance) organize 28 named patterns across six execution topologies. This two-dimensional framework (what the agent does × how it does it) is the map for the rest of this book.
• Design inversion treats the specification as source code and the agent as its compiler. Past the implementation plateau, further code improvements yield diminishing returns, so the developer's role shifts toward designing specifications that constrain the generated behavior.
• Token leverage, the ratio of output quality to token cost, helps teams evaluate designs alongside reliability and latency, especially when usage scales.

FAQ