Eight patterns in the tutorial. Three on the allowlist.

Multi agent orchestration patterns are the named topologies people use to wire several LLM-driven nodes together: supervisor routing to workers, a sequential pipeline, a planner-executor split, a swarm where anyone hands off to anyone, a debate between two critics, a reflector rewriting its own output, and a few more. In production the right question is not which one to use, but which subset is audit-safe and cycle-bounded enough to survive a worker restart at 2am. Our allowlist contains three patterns. The rest we reject by name with the specific MAST failure they invite.

A supervisor whose workers are themselves supervisors multiplies the state surface on every nesting level. MAST-1.3 inter-agent misalignment sits at the top of that taxonomy for a reason: the outer supervisor and the inner supervisor develop subtly different routing assumptions, and the only place those assumptions are reconcilable is in the prompt. We reject hierarchical because the single-layer supervisor-with-capped-budget pattern is strictly enough to handle every use case we have shipped. If a client insists on a nested shape, the honest answer is two separate graphs with a queue between them, not a nested StateGraph.

Any agent handing off to any other makes MAST-2.4 infinite handoff inevitable past three agents unless you layer a budget on top. If you are going to layer a budget on top, you have just rebuilt the supervisor pattern with extra edges. The supervisor-with-capped-budget pattern achieves everything swarm promises with one-tenth the routing surface, and its topology fingerprint is enforceable in CI. Swarm is appealing in demos and unscalable in audits.

The debate pattern pairs two agents that critique each other until convergence. MAST-3.1 unproductive persistence lands here: the loop can terminate after one turn or after twenty, and which it does is a property of prompt and seed, not of graph structure. Worse, evaluating debate transcripts requires a pairing-specific rubric that does not transfer across model vendors, which breaks our vendor-neutral rule. When clients ask for a critic, we ship a single-pass scorer node and use the supervisor's turn budget to bound any re-routing.

It is safe when and only when recursion is forbidden at the graph level. Our approved variant has a single call to the planner per case, a typed Plan with len(steps) <= 8, and a plan_depth bound of 4. The executor iterates the plan list in order. The planner node is not called from within a step. A step is not allowed to return a new plan. MAST-3.2 unbounded self-critique is prevented by the grammar, not by the prompt. If your repo has a plan-inside-plan path, it is not the pattern we approve, and topology_walker will reject the PR.

patterns.md is a ~60 line YAML file with two top-level keys: approved and rejected. Each approved entry has a name, a fingerprint (nodes_max, edges_max, cycle_policy, fan_out_max, required_state_fields, optional constraints) and the MAST code it prevents. Each rejected entry has a name and the MAST code it invites. The file is source of truth for scripts/topology_walker.py. Changing patterns.md is a scoping event, not a hotfix.

It parses graph.py with the standard library ast module. It counts every add_node, add_edge, and add_conditional_edges call. It infers fan-out per node by counting how many distinct next-node string literals appear inside each conditional router function. It walks the induced graph and computes whether a cycle exists outside the supervisor-budget pattern. It compares the resulting fingerprint to every approved entry in patterns.md. If no match, it exits non-zero. It is ~80 lines of pure Python. No runtime execution of graph.py is needed.

Two answers. First: across five shipped systems at Monetizy.ai, Upstate Remedial, OpenLaw, PriceFox, and OpenArt, we have not needed one. Every use case has fit supervisor-capped-budget, sequential-pipeline-idempotent, or planner-executor-bounded-depth, sometimes composed as two graphs joined by a queue. Second: if your use case truly does not fit, the answer is to scope a week of engagement on defining the fourth pattern's fingerprint, its MAST failure mode, and its CI check. It is not to silently add it during a feature PR. patterns.md makes that discussion explicit.

The ceiling numbers are one layer of defense. Topology fingerprints are a higher layer. You can satisfy the 8-edge ceiling with a swarm of 4 agents and still have a peer-to-peer topology we reject. topology_walker.py asks a question the edge counter cannot: is the shape of this graph one we are willing to run at 2am? The numbers live inside patterns, not on top of them.

Yes, because the fingerprint is computed from the source of the graph file, not from a framework-specific runtime. In LangGraph it walks StateGraph calls. In Pydantic AI we parse Agent / Tool definitions the same way. In a custom DAG we parse the .add_step / .add_branch calls in your orchestrator file. patterns.md does not reference a framework. A client who switches from LangGraph to a custom DAG keeps their allowlist. This is part of why the leave-behind survives the engagement.

The academic literature describes many more patterns, including voting ensembles, tree-of-thought search, graph-of-thought, skill libraries with tool-caching. We treat them the same way: run a MAST analysis, pick the closest approved pattern, map the paper's idea onto it. Most of what people call 'a new pattern' is a new prompting strategy inside supervisor + worker or planner + executor. The fingerprint does not care about the prompt. It cares about the graph.