An agent architecture specifies how perception, internal state, decision-making, and action are organized. In multi-agent systems, architecture also constrains how agents interact: centralized brokers vs peer messaging, shared blackboards vs pairwise chats. The same LLM can sit inside many architectural shells (planner-only, critic–actor pair, swarm of role prompts). Poor architecture produces redundant work, deadlocks, or unbounded chatter; good architecture makes termination, accountability, and testing tractable. This chapter surveys classical patterns that still appear — explicitly or implicitly — in modern LLM systems.

Reactive agents map situations to actions with little or no lookahead. In robotics, behavior-based and subsumption-style designs stack simple behaviors (avoid obstacle, follow wall) that run in parallel and compete for control. Strengths: low latency, predictable resource use, robustness in dynamic worlds. Weaknesses: hard to achieve long-horizon optimality or explain global strategy. In LLM systems, a thin wrapper that always calls one tool per user message is closer to reactive control than to deliberative planning.

Deliberative agents maintain an explicit model of the world (even if approximate), formulate goals, and search over sequences of actions — classical AI planning. Strengths: explainable plans, optimality under model assumptions, compositional tasks. Weaknesses: modeling cost, brittleness when the world drifts, and computational expense. LLM agents often mimic deliberation with chain-of-thought or tool-augmented search without a formal PDDL model; the architecture is deliberative in spirit when the system explicitly represents subgoals and revises them.

The BDI architecture (associated with work such as Rao and Georgeff on practical reasoning) separates beliefs (what the agent thinks is true), desires (states it would like), and intentions (committed plans it will pursue). This supports graceful revision: new beliefs can drop intentions without thrashing every tick. BDI influenced agent languages and many cognitive agent platforms. LLM agents rarely expose explicit BDI data structures, but you can engineer them: a memory store for beliefs, a backlog of desires, and a locked “current mission” field representing intention — useful for auditability and human handoff.

Real systems usually combine fast reflexes with slow planning. A lower layer handles emergencies; a higher layer issues subgoals. The three-layer pattern (reactive execution, sequencing, deliberation) appears in robotics and in software agents. For LLM stacks, a common hybrid is: policy layer (when to call tools), worker agents (specialized prompts), and a meta-controller that starts/stops workflows. Hybrids trade complexity for coverage: neither pure reactivity nor pure deliberation fits all timescales.

A manager or orchestrator agent receives inputs, assigns subtasks, and merges results (star topology). Pros: single point of policy, easier logging and access control. Cons: bottleneck, single point of failure, orchestrator context explosion. Peer-to-peer designs let agents message directly; pros: parallelism and resilience; cons: harder global coordination, risk of chat storms. Many LLM frameworks default to orchestrated patterns for observability while allowing selective peer calls for critique or debate.

The blackboard architecture uses a shared structured memory; specialist agents read and write hypotheses or partial solutions under control of a scheduler. It decouples producers and consumers of information — useful when no single agent has the full picture. Modern analogues include shared vector stores, wikis, tickets in Jira-like tools, or structured JSON state passed between LLM calls. Challenges: consistency (who wins conflicts?), locking, and schema governance so agents don’t corrupt shared state.

Start simple: one planner agent with tools. Add reactivity for safety and rate limits. Introduce multiple agents when roles are stable and interfaces clear. Use orchestration when you need centralized policy; use peer critique when diversity of opinion reduces error. Encode state in structured stores when conversations get long. Next chapter: how agents communicate — without crisp protocols, architecture diagrams are wishful thinking.