Other Architectural Patterns

There is no single best team shape. Some tasks need a pipeline, some need parallel workers, and some need a generator repeatedly improved by a critic.

Task shape → choose pattern → define messages/state → evaluate outcome

What You Will Learn

• How common multi-agent patterns solve different coordination problems.
• What each pattern gains and what complexity it introduces.
• How to choose from task structure instead of fashionable terminology.

You already know supervisor, hierarchical, and peer-to-peer in real depth. This module completes the catalog — the remaining named patterns you’ll encounter in real systems, some new, others already covered elsewhere in this course and worth only a precise cross-reference here rather than repetition.

It’s worth knowing where this catalog sits on the control-versus-autonomy spectrum this entire course has been building: “From most-controlled to most-autonomous: pipeline, orchestrator–worker, hierarchy, and blackboard.” (Apptad, Multi-Agent Orchestration) Pipeline sits at the most predictable end. Blackboard sits at the more emergent end, alongside the peer-to-peer and swarm patterns Module 9 already covered in depth.

---

Pipeline: the most controlled pattern in this entire course

Agent A → Agent B → Agent C → Agent D

A pipeline is a strict, ordered handoff chain — each stage’s output is the next stage’s only input, in a fixed, unchanging sequence. It’s worth being precise about why this differs from Module 10’s sequential execution generally: a pipeline isn’t just “steps that happen in order,” it’s a named architecture where the stages themselves are fixed, specialized agents, not a temporary ordering decision made for one particular task.

Why it wins: it’s predictable and trivial to debug — a failure is always traceable to exactly one stage, since nothing branches and nothing runs concurrently. (Apptad) The real cost: it cannot parallelize by design, which makes it the wrong choice the moment independent work exists to exploit.

Real production usage: the canonical sequential pipeline shipping in 2026 is the sales-operations research stack that’s become standard at high-velocity B2B teams — named tools like Clay and Apollo’s agent layer, alongside various CrewAI-templated stacks. (Paiteq, Multi-agent system orchestration patterns) A lead-research pipeline fits this shape: enrich the lead, then score it, then draft outreach — each stage strictly needs the previous one’s output, and nothing benefits from running out of order.

Why this pattern’s simplicity is a feature, not a limitation

It’s worth resisting the instinct to treat pipeline as merely “the simple option you graduate away from.” Every failure-mode discussion in this course so far — Module 4’s coordination overhead, Module 10’s race conditions, Module 12’s contradiction persistence — assumes some form of concurrency or shared mutable state. A pipeline structurally has neither.

There’s no race condition possible when only one stage is ever active at a time, and no shared-memory conflict possible when each stage only ever sees the previous stage’s output, never a pool other agents are simultaneously writing to. This isn’t pipeline being simplistic — it’s pipeline structurally eliminating entire categories of failure this course has spent multiple modules teaching you to defend against elsewhere.

That’s a real reason to prefer it whenever a task’s actual structure allows it, not a consolation prize for tasks too simple to need something more sophisticated.

---

Blackboard: a real pattern from 1980s AI, still running in named companies today

This is worth the deepest treatment in this catalog, because it has a traceable history and real, current production evidence spanning multiple named companies.

The classic definition: a shared knowledge base — the “blackboard” — that agents post to and retrieve from, enabling asynchronous collaboration without direct agent-to-agent communication. (Confluent, Four Design Patterns for Event-Driven, Multi-Agent Systems) This is directly Module 12’s shared-workspace memory pattern, now formalized under its proper architectural name.

The history: this pattern traces to Hearsay-II, a real AI system from the 1980s. A 2026 production analysis describes today’s LLM-based version directly: “It’s classic blackboard — Hearsay-II from the 1980s, just with LLMs reading and writing JSON instead of speech tokens.” (Paiteq)

A real, concrete example, with named companies: “A planning agent posts a draft schedule; warehouse agents check feasibility against their local constraints and post objections; a reconciler agent picks up when enough objections land and re-runs the plan.” The same source identifies exactly why this pattern wins here specifically: “the agents are owned by different teams with different release cadences, and forcing them through a single supervisor would have created a coordination bottleneck nobody wanted to own.” Production write-ups from JPMorgan, Walmart Labs, and a handful of European 3PLs all describe broadly this same shape. (Paiteq)

The actual execution flow

Planning agent posts a draft schedule to the blackboard
     ↓
Warehouse agents (owned by separate teams) independently
read the schedule
     ↓
Each checks feasibility against its own local constraints
     ↓
Agents post objections to the blackboard, if any
     ↓
Reconciler agent watches for objections accumulating
     ↓
Once enough objections land, reconciler re-runs the plan
     ↓
(cycle repeats until no objections remain)

Notice no agent ever calls another agent directly. Every interaction happens through reading and writing the shared blackboard, which is precisely what lets teams on independent release schedules participate without ever needing to coordinate their deployment timing with each other.

This is the, precise reason to reach for blackboard over supervisor: not raw scale, but organizational ownership. When agents are built and maintained by separate teams on separate release schedules, forcing them all through one supervisor creates exactly the bottleneck Module 7 already warned about — blackboard sidesteps it by design, since no single coordinator has to understand or approve every agent’s internal logic.

---

Event-driven: the same patterns, running on a message bus

It’s worth knowing this isn’t a competing pattern so much as an implementation strategy applicable to several patterns you already know. A 2026 analysis shows orchestrator-worker, hierarchical agent, blackboard, and a fourth pattern (covered below) can all be transformed into event-driven distributed systems — gaining the operational advantages of data-streaming infrastructure and removing the need for specialized, pattern-specific communication paths. (Confluent)

Concretely: “The blackboard becomes a data streaming topic consisting of messages produced from and consumed by the worker agents.” This is directly Module 3’s event-based communication mode, now shown as a implementation choice for an entire architecture, not just one message-passing style among several.

The real security consideration worth knowing here: giving agents a continuous reasoning loop with standardized tool access across real operating environments is powerful — and current 2026 research is direct about the risk this creates: “unconstrained deployments… demonstrate how weak guardrails can produce safety incidents and unregulated behavior at scale.” (Autonomous Event-Driven Multi-Agent Orchestration for Enterprise AI, arXiv) This is directly Module 11’s security material, now specifically relevant to event-driven architectures: a continuously-running, event-reactive agent has more opportunities to act on something malicious than an agent invoked once per discrete request.

---

Market-based: a pattern worth knowing exists

It’s worth naming this fourth pattern briefly, since it’s real and appears in current architecture surveys alongside the others: agents bid or compete for tasks based on their own assessed capability or cost, rather than being assigned by a supervisor or discovering work through a shared blackboard. (Confluent) This suits situations where the right agent for a task isn’t known in advance and self-assessment is a reasonable proxy for actual fit — though it’s worth treating with the same honest skepticism Module 13 applied to naive voting: an agent’s own bid is a claim about its capability, not a verified fact, and a system relying on self-reported bids inherits all the same risks an unverified confidence score does.

The connection worth drawing here: market-based coordination is, structurally, Module 5’s delegation criteria turned inside-out. Delegation has a central decision-maker evaluating candidates against capability, cost, and reliability. A market-based system removes that central evaluator and lets candidates evaluate and represent themselves instead — which trades away the oversight a central delegator provides in exchange for not needing one at all. Whether that trade is worth making depends entirely on how much you trust agents’ self-assessment to be accurate, which is exactly the kind of assumption Module 5’s own reliability-tracking discipline exists specifically to avoid having to make on faith.

---

Patterns already covered in depth: precise cross-references

Debate got its real, honest treatment in Module 13 — including the important finding that structured debate underperformed independent voting by a wide margin in a real 2026 study. Worth adding one precision here: debate as an architecture still has a place, specifically when capped to a small number of rounds and used to enrich information before a final vote, rather than treated as the resolution mechanism itself — exactly the hybrid pattern Module 13 already recommended.

Voting — covered in full in Module 13, including weighted voting, majority-vote error amplification, and the real Byzantine Fault Tolerance math for how many agents a voting group needs to tolerate a faulty member.

Critic/Reviewer — covered as a role in Module 2 and as an arbitration mechanism in Module 13. Worth one new precision here: as a standalone architecture, this typically runs as a generate-then-critique loop — an agent produces output, an independent critic reviews it, and the loop repeats until the critic approves or a maximum iteration count is hit. The real design question this raises, distinct from anything covered so far: how many review rounds are actually worth running before diminishing returns make an additional pass not worth its cost — a task-specific tuning decision, not a fixed rule.

Planner/Executor — covered extensively across Module 2 (as roles), Module 5 (delegation), and Module 14 (planning specifically). Nothing further to add here beyond what those three modules already established.

---

Hybrid: how real systems actually combine these

This is worth closing on, because it’s the honest truth about how production systems are actually built — not one pattern chosen exclusively, but several composed deliberately.

Real, concrete composition examples: “A hierarchical system where leaf-level teams use mesh coordination internally. A pipeline where one stage launches a swarm for parallel data collection.” The same source states the underlying principle directly: “The patterns are composable, and the best architectures combine them based on each subsystem’s requirements.” (GuruSup, Agent Orchestration Patterns)

This is worth taking as this module’s actual closing lesson, not just a footnote: nothing in this catalog is meant to be chosen once, exclusively, for an entire system. A real system might use a pipeline for its overall request flow, with one stage internally implemented as a supervisor coordinating several workers, one of which delegates to a blackboard-style shared workspace for a open-ended research subtask. Each subsystem gets matched to its own requirements — precisely the restraint principle from Module 1, applied recursively at every level of a real architecture rather than just once at the top.

---

Applying this to the recurring scenario

The legal-contract pipeline has, in fact, always been a pipeline pattern at its top level — Planner, then Executor, then Critic, in a fixed sequence — composed with a supervisor-style delegation at the Planner-to-Executor handoff, since the Planner assigns specific checklist items to specific Executor runs.

If this firm’s volume grew enough to warrant Module 8’s hierarchical extension — grouping specialists under mid-level supervisors — the architecture would become a hybrid: a pipeline at the top level (intake → review → finalize), with a hierarchical supervisor structure nested inside the “review” stage specifically. This is exactly the composability this module’s closing section described, not a hypothetical.

And it’s worth noting one boundary case this composition avoids: if the firm ever needed cross-team-owned specialist agents — a third-party compliance vendor’s own agent participating in review, say — that specific integration point is precisely where blackboard’s organizational-ownership argument would apply, layered inside the hierarchical review stage rather than replacing it entirely.

---

Interview-relevant framing

Q: When would you reach for a blackboard pattern instead of a supervisor?

Ans: Specifically when the agents involved are owned by different teams with different release cadences — forcing them all through one supervisor creates exactly the coordination bottleneck Module 7 already covers, and blackboard avoids it by design, since no central coordinator needs to understand or approve every agent’s internal logic. Real production write-ups from companies like JPMorgan and Walmart Labs describe this exact shape for cross-team workflows — it’s a current pattern, not a historical curiosity, even though it traces back to Hearsay-II from the 1980s.

Q: Why would you implement an existing pattern like blackboard or supervisor in an event-driven way?

Ans: Because event-driven implementation is an infrastructure choice, not a competing architecture — you gain the operational maturity of data-streaming systems (durability, replay, decoupled scaling) without changing the actual coordination logic. A blackboard becomes a streaming topic instead of a database table; the pattern’s behavior doesn’t change. The real trade-off worth naming is security: a continuously-running, event-reactive agent has more opportunities to act on something malicious than an agent invoked once per discrete request, which is exactly why current research treats weakly-guarded event-driven deployments as a documented risk category.

A third question worth preparing for:

Q: How would you decide whether a system needs one architectural pattern or a hybrid of several?

Ans: By evaluating each subsystem’s requirements independently, rather than picking one pattern for the whole system upfront. A request-handling flow with strictly ordered stages fits pipeline; a subtask within one of those stages that benefits from parallel exploration might warrant a swarm nested inside it; a cross-team-owned integration point might need blackboard specifically to avoid a coordination bottleneck.

Real production architectures do exactly this — a hierarchical system with mesh coordination inside its leaf-level teams, or a pipeline stage that launches a swarm for one specific parallel task. The mistake is treating architecture selection as a single, top-level decision rather than a recursive one applied at every subsystem boundary.

Common Misconception

Incorrect idea: The most sophisticated pattern is the most production-ready.

Why it is incorrect: A pattern is useful only when its structure matches the task and improves measured outcomes over a simpler baseline.

Key takeaways

• Pipeline is the most controlled, most predictable pattern in this course’s entire catalog — trivial to debug, unable to parallelize by design, and well-suited to strictly sequential real workflows like sales-ops research stacks running in production today.
• Blackboard is a real pattern tracing to Hearsay-II, a 1980s AI system — still running in named 2026 production companies including JPMorgan and Walmart Labs, chosen specifically to avoid the coordination bottleneck of forcing cross-team-owned agents through a single supervisor.
• Event-driven is an implementation strategy, not a competing architecture — supervisor, hierarchical, and blackboard patterns can all run on a message-streaming backbone, gaining real operational advantages at the cost of a larger security surface for continuously-reasoning agents.
• Market-based coordination, where agents bid for tasks based on self-assessed fit, is a real pattern worth knowing exists — and worth the same skepticism Module 13 applied to unverified self-reported confidence.
• Debate, voting, critic/reviewer, and planner/executor were already covered in depth in earlier modules — this module added only the precisions new to each, rather than repeating what you already know.
• No real production system commits to exactly one pattern from this catalog — the honest, dominant reality is composition, with different subsystems of the same architecture matched to their own requirements, recursively applying this course’s restraint principle at every level.

Module 16 turns from architecture choice to what happens when any of these architectures breaks: multi-agent failure modes — hallucination, incorrect delegation, infinite loops, cascading failures, and the rest of the practical failure catalog every one of these patterns is exposed to.