If you have worked through Module 1, you now have a vocabulary of seventeen primitives spread across six categories: actors, tools, instructions, coordination, connections, and interactions. You understand what each one does in isolation — what workflow orchestration provides that choreography does not, why queued connections matter when point-to-point links hit their ceiling, how delegation differs from notification as an interaction pattern. That understanding is the foundation. But it is not architecture.
Architecture begins when you start combining primitives — when you decide that this particular problem calls for an orchestrating agent using agentic coordination, connected to specialist sub-agents through dynamic connections, communicating via delegation for commands and notification for status updates. The individual primitives are components. The patterns are the ways those components compose into systems that solve real problems under real constraints. Module 2 is about those patterns.
Why Primitives Alone Are Not Enough
A common failure mode in agent system design is what you might call primitive-first thinking: picking a coordination mechanism because it sounds right, choosing a connection type because it is familiar, selecting an interaction pattern because the framework defaults to it. The result is a system that functions in a demo but buckles under the weight of production concerns — error handling, governance, observability, cost management, and the messy reality of enterprise integration.
The issue is not that any individual primitive choice was wrong. The issue is that primitives interact, and those interactions create emergent properties that no single primitive can provide or prevent on its own. Workflow orchestration gives you auditability and determinism, but pair it with point-to-point connections and you get tight coupling that resists change. Choreography gives you loose coupling and resilience, but combine it with delegation instead of notification and you have undermined the very decoupling that choreography was supposed to provide.
Patterns encode the lessons of these interactions. They capture not just which primitives to combine but how they should fit together, what tradeoffs that combination introduces, and where the system will break if you are not paying attention.
Composition Is Where the Design Decisions Live
Every production agent system makes choices along several axes simultaneously. Understanding those axes is more useful than memorizing specific configurations, because the right composition depends entirely on what you are building and what constraints you operate under.
Determinism versus adaptability. At one extreme, you wire agents into fully deterministic workflows — each step predefined, every branch enumerated. At the other, you hand an orchestrating agent a goal and trust it to figure out the steps. Most production systems land somewhere in the middle: deterministic structure with pockets of agent judgment where the problem genuinely requires flexibility. The question is always where to put the boundary, and getting that wrong in either direction is expensive. Too deterministic and you cannot handle the variability that justified using agents in the first place. Too adaptive and you lose the auditability and predictability that your compliance team requires.
This maps directly to the coordination primitives. Workflow orchestration anchors the deterministic end. Agentic orchestration occupies the middle, with an LLM making routing decisions within a structured framework. Choreography enables the most decentralized, adaptive designs — but demands that you solve the observability problem independently, because no central controller is tracking the process.
Coupling versus autonomy. Tightly coupled systems are easier to reason about, debug, and govern. Loosely coupled systems are easier to evolve, scale independently, and recover from partial failure. Every connection and interaction choice shifts this dial. Point-to-point connections maximize coupling but minimize latency and complexity. Queued connections decouple in time but introduce buffering concerns and delivery guarantees you need to manage. Dynamic connections decouple in identity — the sender does not need to know the receiver at design time — but add discovery infrastructure and match-quality concerns.
Scope versus blast radius. How much can any single agent do? The four dimensions of autonomy — tool, task, plan, and collaboration — define the scope. But scope is inseparable from blast radius: an agent with broad tool autonomy operating over action tools that write to production databases has a blast radius that no amount of prompt engineering can contain. Autonomy borders exist precisely because the combination of high autonomy and high-consequence tools demands explicit boundaries, not implicit trust.
Observability versus simplicity. Every layer of observability you add — execution traces, token cost tracking, behavioral telemetry — adds complexity, latency, and cost. But every layer you skip is a dimension you cannot debug in production. The coordination pattern you choose determines how much observability infrastructure you need. A single-agent pattern with workflow orchestration might log cleanly to a linear trace. A multi-agent choreography system requires distributed tracing across independent event-driven agents where the process path is not predetermined. The observability requirements are a consequence of the architectural pattern, not an independent concern to bolt on later.
The Patterns in This Module
Module 2 covers six pattern families, each addressing a different class of architectural decision. They build on each other, but you will encounter them simultaneously in any non-trivial system.
Orchestration patterns address how work gets coordinated across one or more agents. The four fundamental patterns — single, sequential, parallel, and hierarchical — are not academic categories. They are concrete architectural choices with different cost profiles, failure characteristics, and governance requirements. The right pattern depends on the task structure, the latency budget, the cost envelope, and how much you need to explain the system’s behavior after the fact.
Multi-agent coordination picks up where orchestration patterns leave off. When you decide to split work across multiple agents, a second set of questions emerges: how do agents discover each other, how do they negotiate, how do they handle partial failure across agent boundaries, and what happens when two agents make conflicting decisions? These are not theoretical concerns — they are the problems that cause multi-agent systems to fail in production, typically in ways that single-agent prototypes never revealed.
Error handling and recovery addresses the most underinvested area in agentic system design. LLM-based agents fail in ways that traditional software does not: partial failures where some tools succeed and others do not, semantic failures where the output is syntactically valid but meaningfully wrong, cascade failures where one agent’s bad output becomes another agent’s confident input. The patterns for handling these failures exist, but they require deliberate architectural decisions, not afterthoughts.
Governance patterns tackle the question of how to constrain agents without crippling them. The primitives provide the governance surface area — system instructions set boundaries, agent instructions define behavior, action tools enforce consequences. But the pattern is how these elements compose into a governance architecture that covers the full agent lifecycle, from design through deployment to decommissioning.
From prototype to production addresses the patterns that separate a working demo from a deployable system. This is the capstone of the module, and it synthesizes the preceding patterns into a practical framework for production readiness. The gap between prototype and production is not primarily about code quality. It is about the security boundaries you did not draw, the identity architecture you deferred, the observability you did not instrument, and the error paths you never tested because the happy path worked so well in the demo.
How to Read This Module
If you worked through Module 0 and Module 1 sequentially, you have the conceptual foundation to read Module 2 in order. Each post builds on the previous one, and the cross-references are deliberate: we reference specific primitives when a pattern depends on understanding them, and we link to existing deep-dive articles when a topic warrants more detail than the pattern discussion can provide.
If you are arriving at Module 2 with production experience but without having read the earlier modules, you can start anywhere — but you will get more from the orchestration and coordination posts if you understand the coordination primitives, and the governance discussion assumes familiarity with the instruction hierarchy from Module 1.
The posts in this module are less about introducing new vocabulary and more about developing architectural judgment. Module 1 taught you the parts. Module 2 teaches you how to assemble them into systems that survive contact with production — with its messy data, impatient users, changing requirements, compliance mandates, and the inevitability of failure. That is where the interesting engineering lives.
Key Takeaways
The seventeen agentic primitives from Module 1 are necessary but not sufficient for designing production agent systems — architecture emerges from how primitives compose, and the interactions between coordination patterns, connection types, and interaction modes create emergent properties that no single primitive accounts for. Every composition decision involves tradeoffs along predictable axes: determinism versus adaptability, coupling versus autonomy, scope versus blast radius, and observability versus simplicity — and the right position on each axis depends on your specific constraints, not on a universal best practice. Module 2 covers five pattern families — orchestration, multi-agent coordination, error handling, governance, and production readiness — each encoding the hard-won lessons of how primitives behave when they meet real workloads, real failures, and real organizational constraints.