Taxonomy

The catalog splits every entry into one of three cohorts. Each cohort answers a different design question and composes with the others in predictable ways.

Primitives

Capabilities a pattern draws on — memory across turns, callable tools, agent-discovered skills.

Modifiers

Orthogonal behaviors layered on top of a pattern — human approval gates, audit logging, retries.

Why three cohorts?

Earlier versions of this repo treated "workflow" and "agent pattern" as parallel categories, but design questions kept leaking across the line: memory isn't a workflow shape, it's a capability the shape draws on; human-in-the-loop isn't an agent pattern, it's a behavior layered on top of one. The three-cohort split makes those decisions orthogonal — you pick a pattern, you pick which primitives it uses, you pick which modifiers wrap it.

How to walk a recipe

A downstream consumer (a deployment spec, a scaffolded project, an AI tool reading the catalog) names exactly one agent_pattern, lists the primitives it requires, and the modifiers it applies. The catalog at composition/ shows which combinations work well and which fight each other.

Growing the taxonomy

The cohorts themselves are declared in taxonomy.yaml at the repo root. Adding a brand-new cohort (e.g. guardrails, evaluators) is one entry in taxonomy.yaml plus a directory — no code change. The validator, the catalog emitter, the schemas test, the docs generator, and the website data generator all read taxonomy.yaml.

If the site lags behind the catalog after a contribution lands, trust the catalog. The authoritative sources of truth are taxonomy.yaml and the generated patterns-catalog.yaml at the repo root; this page is a rendered view of them.