Chapter 3Architectural forces in agentic design
Every design pattern in this book, and most of the patterns in canonical sources such as Gulli (2025), Anthropic’s Building Effective Agents, and the CSIRO catalog, exists to balance a competing pair of structural forces. The patterns are not arbitrary. They are responses to tensions that arise whenever a probabilistic reasoning component sits on the control-flow path of a system that has to be reliable, auditable, and economical to run.
This chapter names those forces. The list is short by intent. A small number of well-named forces is more useful than a long catalog of dimensions, because architects reason about systems pair-wise: in any given design decision, two of these forces dominate and the rest fall out as consequences.
A working vocabulary
These seven are a working vocabulary. Some overlap. Exploration versus cost and deliberation versus latency are close to the same tradeoff in two currencies, money and time, kept separate here because which currency binds depends on whether the system is batch or interactive. Autonomy versus control and generality versus governability both pull between a system’s reach and the ease of constraining it. The point of the list is the clarity it buys, not a clean decomposition. Naming the dominant force pair for a decision surfaces the tradeoff being made, even when a third force is also in play.
The forces function the way forces function in Christopher Alexander’s A Pattern Language and in Gamma et al.’s Design Patterns. They name the structural tensions a pattern resolves. A pattern is a deliberate balance among forces. Reading later chapters with the forces in mind clarifies what each pattern is giving up to obtain what it provides.
Each is treated below. The chapter closes with a short note on how forces compose, and how to read the rest of the book as a sequence of deliberate balances among them.
Autonomy vs. control
The tension. Unconstrained ability to handle novel tasks versus the deterministic enforcement of safety boundaries.
Autonomy versus control is the first force, and the load-bearing one. Greater autonomy increases an agent’s ability to handle novel tasks, recover from unexpected failures, and choose among alternatives without prescriptive instructions. It also increases the variance of outcomes, the cost of testing, and the surface for unsafe action. Greater control, expressed through explicit constraints, validators, narrowed tool surfaces, and deterministic orchestration, reduces variance and makes the system tractable to test and audit. It also reduces the system’s ability to handle situations the designer did not anticipate.
There is no universal balance. There is, however, a default for production systems: less autonomy than the team is tempted to grant, and bounded enforcement of the rest (Chapter 5). Systems frequently fail because autonomy was granted on the assumption that the model would behave like a careful junior engineer. Models, even strong ones, do not self-limit. They will iterate, spend, and act without an internal cost signal or a brake on irreversible action.
The autonomy/control tradeoff most strongly determines the shape of an agentic system. This is why Chapter 5 treats bounded autonomy as a design discipline. Choosing the desired degree of autonomy before establishing the controls produces a brittle system.
Conservative autonomy with strong controls leaves room to widen the envelope later, once the model and operating discipline have proved themselves.
A common mistake is to imagine the choice as a single dial running from “fully manual” to “fully autonomous.” It is closer to a set of independent dials, one for each axis of bounded autonomy (Chapter 5). A system can have high autonomy on which sequence of tools to invoke while having low autonomy on which data the tools may touch; high autonomy on iteration count while having low autonomy on cost spend. Treating the dials as independent prevents the failure mode in which all dials are turned up together.
Exploration vs. cost
The tension. Better answers from more exploration versus the tokens, time, and money each additional pass consumes.
The reasoning component can almost always improve its output by exploring more: generating more candidates, reflecting more times, calling more tools, retrieving more context. Each increment of exploration carries an increment of cost in tokens, time, external API spend, and downstream resource use.
Exploration needs a budget and an explicit enforcement point. The budget can be implicit in the reasoning loop’s stop conditions, which is poor because the model decides when it is done. It can be bound to a single dimension like iteration count, which is acceptable for some patterns but misses cost spikes from expensive tools. Or it can be multi-dimensional and externally enforced, with iterations, tokens, wall-clock, spend, and retries carrying hard limits that abort the loop. That is the form recommended in Chapter 5.
The tradeoff has a non-obvious shape: the marginal return on exploration is steep and then flat. Two iterations are often dramatically better than one; 10 are rarely much better than eight. Most exploration budgets in production systems are set too high because the architect tested with the model converging in three iterations on easy cases and did not measure the long tail. The percentile distribution of useful exploration matters far more than the average.
Self-consistency, debate, and tree-of-thought patterns (cataloged in Chapter 4) are explicit explorations of this force. Each commits resources to additional reasoning passes in exchange for variance reduction. The architectural question is when the variance reduction justifies the cost. For a $0.05 query asked thousands of times per day, a self-consistency multiplier of five may be unjustifiable; for a once-per-week strategic analysis worth thousands of dollars in human time, a multiplier of ten may be cheap.
The cost dimension to optimize depends on what the system is for. Interactive systems optimize wall-clock. Batch systems optimize spend. High-stakes one-shot systems optimize quality and accept high cost. Naming this explicitly in the design, “this system optimizes X subject to constraints on Y and Z,” prevents the failure where the team applies exploration patterns appropriate for one optimization profile to a system that should have been on another.
Adaptability vs. predictability
The tension. Adapting to novel situations at runtime versus behavior that is predictable, testable, and certifiable across runs.
An agentic system is useful in part because it can adapt, replan after a failure, switch tools, change strategy. The same adaptability makes the system’s behavior harder to predict from one run to the next, harder to test, and harder to certify against compliance requirements.
Several architectural moves contain this tradeoff. Replay testing (Chapter 12) records traces and asserts that behavior stays within an approved envelope. Bounded plan revision limits how often the agent may replan and which branches it may take. A deterministic substrate confines variability to the bounded reasoning component. Behavioral envelopes describe the agent’s space of acceptable behaviors rather than its exact behavior; deployment tests assert that the envelope holds.
The deepest cost of unmanaged adaptability is organizational. Stakeholders cannot certify a system whose behavior they cannot describe. The architecture therefore makes the envelope of adaptability describable while allowing the agent to adapt within it. Regulated industries pay this cost most visibly. A financial-services agent that adapts unpredictably cannot be deployed at all in jurisdictions that require behavioral certification. With a defined envelope, the agent has latitude within the certified boundary. That certification remains stable across model versions, prompt changes, and small architectural revisions; changes to the envelope require re-certification.
For non-regulated systems, the same principle applies for different reasons. A customer-facing system whose behavior is unpredictable from week to week loses user trust independently of whether any individual run was correct. Users build mental models of systems and rely on those models. An envelope that holds across runs lets users build a working model; behavior without an envelope prevents them from doing so.
Centralization vs. emergence
The tension. Centralized orchestration that is easy to reason about and govern versus decentralized coordination that scales and partitions responsibility.
Single-agent systems with centralized orchestration are easier to reason about, debug, and govern. Multi-agent systems with decentralized coordination scale better, partition responsibility, and can exhibit useful emergent behavior.
Across the 2024 to 2026 literature, multi-agent is over-prescribed. A surprising fraction of production agentic systems are single agents with tools, plus possibly an orchestrator that delegates to specialized sub-agents under bounded authority. True multi-agent systems with peer-to-peer coordination, voting, debate, or auction-based allocation remain rare in production and disproportionately common in demos. The pragmatic default is to start with a single agent and tools, then add an orchestrator with workers if responsibility decomposes cleanly, then, and only with strong justification, move to peer multi-agent shapes. The CSIRO catalog and Gulli’s chapter on multi-agent collaboration cover the shapes thoroughly. The architectural question is which shape the problem actually requires, not how to build the most interesting one.
The tradeoff also has an observability cost. Multi-agent traces are harder to read, debug, and replay than single-agent traces. An incident in a single-agent system that an on-call engineer can debug in 20 minutes can take hours in a poorly-instrumented multi-agent system, because the engineer must reason about cross-agent interactions, inter-agent message channels, and timing artifacts. Chapter 12 develops trace discipline; Chapter 9 covers coordination shapes in compressed form.
The architectural commitment in multi-agent systems is to make the coordination layer first-class. Inter-agent channels are governed (Chapter 6); messages are structured; the orchestrator’s view of fleet state is observable; the trace links events across agents through correlation identifiers. Without this, multi-agent systems decay into hard-to-debug systems whose value depends on no two agents disagreeing in a way the architecture cannot resolve. Single-agent systems are dull architectures. They are also the ones that ship reliably and survive contact with production, which is the test that matters, and the reason to resist a more interesting shape when a simpler one will do.
Deliberation vs. latency
The tension. Deeper reasoning for better answers versus the response-time budget the system must meet.
Deeper reasoning produces better answers and slower responses. For interactive systems (chat, IDE assistants, voice) latency is a hard constraint; for batch systems (research agents, code migrations, document processing) latency is a budget, not a cliff.
Two-tier reasoning sends common cases to a fast tier and flagged cases to a deliberate one. Anthropic’s evaluator-optimizer pattern and Andrew Ng’s reflection pattern offer two shapes. Batch work can move deliberation off the user-facing path and report structured progress (Chapter 18). Streaming improves perceived responsiveness by showing intermediate reasoning. The computation still runs. Progressive disclosure keeps the fast tier light: load context and skills (Chapter 10) only when deeper reasoning warrants them.
It helps to separate two latencies. Information latency, time to first token, is what a user feels, and streaming addresses it directly. Action latency, time until the agent actually acts on the environment, such as calling a database or committing a change, is untouched by streaming. If the agent must reason for 15 seconds before invoking the tool, the side effect still lands 15 seconds late. For systems that chat with users, information latency dominates. For systems that act on the world, action latency is the real constraint, and streaming is no remedy for it.
Reasoning models in 2026 reduce the visible latency penalty for deeper reasoning, because more of the reasoning is internal to a single model call. This shifts some patterns (reflection, plan-execute) from architectural to model-internal; see Chapter 4. The architectural question persists, however. The reasoning model’s internal deliberation still consumes time and tokens, and a system that calls the reasoning model on every interaction pays the cost on every interaction.
A neglected aspect of the latency tradeoff is latency variance. Users tolerate consistent latency better than variable latency. A system whose responses come in two seconds 99% of the time and 12 seconds 1% of the time feels less reliable than one whose responses always take five. The architectural commitment is to monitor percentiles, not averages, and to bound the long tail at the time-budget axis (Chapter 5).
Memory depth vs. context constraints
The tension. Richer memory for competence versus the finite, attention-limited context window the model reasons over each turn.
Agents benefit from richer memory: past tasks, learned strategies, domain knowledge, user preferences. Richer memory introduces retrieval complexity, increases the risk of leaking irrelevant context into the loop, and consumes the bounded window available to the reasoning model on every turn.
The force breaks into two sub-tensions. Within-loop memory is the finite context window (even at the multi-million-token sizes of 2026 models, finite). Filling it with retrieval results, prior turns, and tool documentation reduces the space available for reasoning. The Skills layer (Chapter 10) and Anthropic’s progressive disclosure mechanism explicitly target this: load only what is needed, when it is needed. Cross-loop memory is episodic and semantic memory (Chapter 7) accumulating across runs. It improves the agent’s competence over time and degrades the predictability of the system, because behavior now depends on history that may not be obvious from the current input.
The pragmatic balance is to prefer rich tool-mediated retrieval to large static context, prefer compact, summarized memory to verbatim memory, and treat memory as a managed resource with policies for what is captured, when it is consulted, and how it is invalidated. Chapter 7 develops this in depth.
A bloated context primarily taxes the model’s attention. Models attend non-uniformly across long windows. A 100-token context with the right content beats a 100,000-token context with the same content buried in the middle. Memory architecture is, first, a signal-to-noise problem. The financial argument is weaker than it once was. Provider-side prompt caching, introduced across the major APIs in late 2024, lets a large static prefix be resent each turn at a fraction of its first-call cost. Caching does nothing for content that changes every turn, and nothing for the attention problem, but it removes the simplest reason to keep static context small. Cost discipline now matters most for the dynamic, per-turn portion of the context and at high scale, where the ratio between disciplined and undisciplined memory architectures can still reach an order of magnitude.
Generality vs. governability
The tension. One agent that can do anything versus a narrowly scoped agent that is straightforward to bound and own.
A general agent, one capable of arbitrary tool use, arbitrary tasks, arbitrary domains, is impressive in demos and hard to govern. A narrowly scoped agent, one tool surface, one task class, one domain, is dull to demonstrate and straightforward to govern.
The force shows up as a structural choice in nearly every project. Specialist agents with narrow tool surfaces (one for code, one for SQL, one for incident response) are easier to bound and often combined under an orchestrator. Generalist agents with broad tool surfaces and a reasoning loop that decides which tool to use are harder to bound, and their failure modes are harder to enumerate. The book’s recommendation is the specialist direction: bounded scope first, generality only when the operating profile justifies it. Most production agentic systems work because they are doing something narrow well, with strong governance, rather than something broad mediocrely with weak governance.
The decision has organizational implications. Conway’s Law predicts that systems mirror the communication structures of the organizations that build them. A specialist agent has a clear owner in its domain team, so the architecture and the org chart reinforce each other.
A generalist agent has unclear ownership; everyone is responsible, which often leaves no team accountable for maintaining it. Specialist orchestrator-worker architectures align ownership with domain boundaries, while monolithic generalist agents make that alignment harder.
There is a counterargument: an organization may not have the budget for many specialist agents and may prefer one generalist. The architectural answer is to factor the agent’s responsibilities so that the specialist split is internal to the system even if it is not visible to the user. An orchestrator-worker architecture (Chapter 9) presents a single front to the user while internally being a small team of specialists; this preserves the governance benefits of specialization without multiplying user-facing complexity.
How forces compose
In most design decisions, two of the seven forces dominate and the rest follow. Bounding autonomy (Chapter 5) is primarily about autonomy versus control and exploration versus cost. Governance architecture (Chapter 6) is primarily about adaptability versus predictability and generality versus governability.
Memory design (Chapter 7) is primarily about memory depth versus context constraints and adaptability versus predictability. Coordination (Chapter 9) is primarily about centralization versus emergence and deliberation versus latency. Skills (Chapter 10) is primarily about memory depth versus context constraints and generality versus governability. Failure modes (Chapter 11) follow when these forces are left unbalanced.
When reading later chapters, identify the pair of forces dominating the pattern. The pattern’s tradeoffs section is, in essence, a statement of which force was accepted as the cost and which was preserved as the benefit. Mapping a pattern to its force pair is the analytical vocabulary this book is trying to provide, and it doubles as a filter: a pattern that cannot be mapped to a force pair is incompletely specified for design use, because its tradeoffs cannot be evaluated. A pattern that claims to optimize everything simultaneously is hiding a tradeoff that will appear in production, and a clear statement of which force the pattern privileges is part of what makes it usable.
Forces, patterns, and deliberate choice
Several existing pattern catalogs (Gulli 2025, the Augment Code 2026 guide) list forces alongside patterns. Where they differ, this book follows the principle that forces describe tensions and patterns describe responses to them. A pattern is complete when it makes the architect’s choice explicit; a pattern that disguises the choice as a default leaves the tradeoff to be discovered in production.
For any proposed pattern, whether in this book, a canonical source, or a team’s design document, ask which forces it balances and at what cost. An unclear answer means the pattern is incompletely specified. An answer of “all of them” is incoherent because the forces cannot all be optimized at once.
The forces themselves are stable; the positions architects should take on them shift as the field evolves. In 2024 the right point on the autonomy/control axis was further toward control than many architects realized. In 2026, with stronger reasoning models, the same axis can be carried slightly toward autonomy in domains where the bounding layer is mature. The architectural commitment is invariant across these shifts: whatever the current position, it is a deliberate choice, expressible as a balance of forces, defended by the design’s bounding and governance, and revisable as the field evolves. A team that builds with this discipline can move along the axes as conditions change; a team that does not is locked into the position it implicitly chose at the start. Chapter 4 and onward use the forces named here as the vocabulary for that discussion.
Summary
Seven structural forces, autonomy/control, exploration/cost, adaptability/predictability, centralization/emergence, deliberation/latency, memory depth/context, and generality/governability, drive nearly every architectural decision in agentic systems. The patterns in this book and in canonical sources balance those forces.
The next chapter maps the cognitive layer, including patterns that have become model-internal in 2026. From Chapter 5 onward, each architectural chapter identifies the forces it balances.