Chapter 7 — Advanced Collaborative and Dynamic Patterns

Seventh post of the chapter-by-chapter walkthrough of LLM Primer IV: Designing AI Cognition with MCP. When the topology cannot be drawn at design time — when the right next step depends on what the previous step found — the patterns from Chapter 6 stop being sufficient.

Why this chapter exists

The patterns in Chapter 6 share an architectural feature that becomes a liability for harder tasks: the topology is fixed at design time. The engineer draws the pipeline, names the stages, decides who feeds whom, and the runtime never reconsiders. For tasks whose shape is known in advance, this is a strength. For tasks whose shape is genuinely emergent — where the right specialist depends on what the user actually asked for, where the plan itself has to be built as the work proceeds — the fixed topology becomes a cage.

This chapter walks the dynamic patterns: roundtables where agents iterate toward consensus, routers that delegate to specialists chosen at runtime, and magentic orchestration that builds plans as the task unfolds. Each buys capability the simpler patterns cannot offer. Each introduces failure modes — non-termination, mis-routing, runaway planning — that the simpler patterns avoid.

One line: roundtable is a meeting that has to end, handoff is dynamic delegation to specialists, magentic is a manager building the plan as they go — each is the right answer for a narrow class of task, and reaching for them when a simpler pattern would do is the most common production failure of 2025.

7.1 Group chat and roundtable: maker-checker, multi-participant consensus

Group chat orchestration places several agents in a shared conversational context and lets them speak in turn. The simplest form is the two-agent maker-checker loop: the maker produces a candidate, the checker evaluates it against a rubric, the maker revises on feedback, and the loop terminates on approval or a turn budget. Language models are measurably better at evaluation than at production when both are framed correctly — a model asked to write and self-evaluate in the same call tends to defend its first attempt; the same model given the same output in a fresh context with a clear rubric is markedly more critical.

The honest failure modes are three. Collusion — when maker and checker share a model and prompt, the checker approves anything. The defense is real role differentiation, ideally different models. Non-termination — a strict checker rejects every candidate; the orchestrator must accept the best-seen or escalate. Checker drift — in a shared roundtable context, the checker starts approving things it would have rejected earlier because the maker's justifications accumulate. A field finding from late 2025 is counterintuitive: the most reliable maker-checker systems prevent the checker from seeing how the candidate was produced. Stateless checkers — given only the candidate and the rubric — increase correct rejections by 30–50%. Shared context is a tool, not a default.

Multi-participant roundtables extend the pattern with several specialists and a moderator. The cost grows quickly: token spend grows with the shared transcript, latency grows with turns, and agents getting stuck on tangents is observed in production. The disciplines that make it work — bounded tokens per turn, structured turn outputs, explicit termination rubrics — are the difference between a productive meeting and a meeting that should have been an email.

7.2 Handoff and routing: dynamic delegation

Handoff orchestration takes a different approach: one agent at a time handles the conversation, and the active agent can hand off when its work is done or when the request shifts into a different specialty. The router — usually itself an LLM — reads conversation state and outputs a routing decision: "stay with current" or "hand off to specialist X with this context summary." The summary is the contract between the routing layer and the specialist.

The hardest engineering problem is recognizing when handoff is needed. Mis-routing is the most common failure: the router sends a billing question to technical support, support does its best, and the user gets a confused answer that addresses none of their concerns. Defenses layer: a confidence threshold below which the router defers to a human, explicit "this isn't my area" actions specialists can take, and logging every routing decision for review.

Two other failure modes shape production design. Handoff loops — specialist A sends to B, B sends back to A — defended by detecting repeated handoffs and forcing a different resolution. Context loss — each handoff summary is lossy, and the next specialist may ask for information the user already provided — defended by storing the full conversation outside any specialist's context, with the summary as the primary payload and the full history available on request. As specialist counts grow, flat routers become brittle; the pattern that emerged in 2025 is hierarchical routing — a coarse router picks a category, a category-specific router picks the specialist. Two levels is the sweet spot in production.

7.3 Magentic orchestration: plans built as the work unfolds

For tasks whose decomposition is not known at the start — investigate why the database is slow, debug an unfamiliar system, research a complex topic — none of the prior patterns suffice. Magentic orchestration, named after Microsoft's Magentic-One framework, is the family of patterns where a manager agent holds a task ledger and updates it as work proceeds. The ledger has explicit slots: the original goal, the current understanding (which may refine), open subtasks with priorities, completed subtasks with results, discoveries that may require revising the plan, and a stop condition. The manager reads the ledger each step, decides the next dispatch, and integrates results back.

The strength is genuine open-endedness. "Investigate why the database is slow" cannot be decomposed up front — the next subtask depends on whether the bottleneck turns out to be network, query plan, or hot row. No fixed pipeline could handle this; no static handoff topology could route correctly without knowing in advance what the relevant specialties would be.

The cost is the most severe in this chapter on every dimension: latency, tokens, engineering effort, operational risk. Token spend grows superlinearly because the ledger is read on every turn. The catalogued failure modes are sharp. Runaway planning — the manager opens subtasks faster than it closes them, ledger grows without bound. Goal drift — as the manager learns, it reformulates the goal away from the user's intent. Plan churn — every new finding triggers a plan revision, no commitment is sustained long enough to make progress. The pattern that has emerged is the bounded magentic loop: budgets on open subtasks, total worker invocations, and wall-clock time, with escalation when any bound is hit. Production magentic systems without bounds occasionally burn hundreds of dollars in tokens on tasks the manager could not solve within any practical budget.

7.4 Choosing among the patterns

Three questions select among them. Is the topology known in advance? If yes, stay with Chapter 6's static patterns. Does the work benefit from iteration against an external check? If yes, a maker-checker loop is the right addition — embeddable inside any other pattern. How open-ended is the planning? If clear bounds, handoff or sequential handles it; if genuinely emergent, magentic is the necessary pattern, accepted with its costs.

A 2025 case from a financial-services firm is the instructive cautionary tale: a magentic customer-onboarding workflow chosen because the team was excited about the framework's flexibility was replaced with a fixed sequential pipeline. Per-onboarding cost dropped from roughly seven dollars to eighty cents; completion rates improved. The pattern of reaching for the most general tool when a more specific one would do is not new in software engineering, and it manifests sharply in multi-agent orchestration because the generality is paid in tokens.

Worth holding onto: the dynamic patterns are commitments to operational capability, not just architectural choices. A magentic system without distributed tracing produces incidents that cannot be diagnosed. A roundtable without turn-by-turn logging produces output that cannot be reviewed. A handoff router without routing observability produces silent mis-routings whose effects accumulate. Reach for the pattern you can operate, not the pattern that would theoretically be best if operations were a solved problem.

What Chapter 7 sets up

Chapters 6 and 7 specify how agents coordinate. They do not specify where the agents run, how the language model is co-located with the tools, or what the deployment topology looks like at the level of processes, machines, and network boundaries. Two systems with identical orchestration patterns can be deployed in dramatically different ways — different latency profiles, different cost structures, different security postures. Chapter 8 covers that dimension.

Next — Chapter 8: Deployment Layouts. Three broadly different ways MCP can be physically deployed — model-with-server, model-in-client, hybrid — with the real-world tradeoffs in latency, cost, operational complexity, and the kinds of failures each makes likely.

Want the full picture? The book walks the field findings on stateless checkers, the durability-of-handoff-routers patterns at scale, the full magentic ledger schema, and the cost-audit case study where a magentic workflow was replaced by a fixed pipeline at a 9x cost reduction. View LLM Primer IV on Amazon →