Blueprints → Deployments
A reader who finishes a pattern doc has a question: which production-shaped agent uses this? This page answers it.
It's the agent-blueprints-side companion to `agent-deployments/docs/blueprint-map.md`, which goes the other direction (recipe → pattern). Keep both pages open if you're orienting for the first time.
How to read this
agent-blueprints covers cognitive shape — how the agent thinks. agent-deployments covers operational shape — how the agent survives production (auth, rate limiting, retries, idempotency, observability, tracing). Every deployment recipe inherits the operational layer; each one picks from this repo via the three-tier taxonomy:
recipe declares:
agent_pattern: <one> # the flow shape (from patterns/)
primitives: [...] # building blocks the agent uses (from primitives/)
modifiers: [...] # transformations layered on the pattern (from modifiers/)
capabilities: [...] # deployment provisioning (managed by agent-deployments)
The first three come from this repo (cognitive). The fourth is owned by agent-deployments (operational). A recipe picks exactly one pattern + zero or more primitives + zero or more modifiers + zero or more capabilities.
This page is the index of which recipes use which cognitive units. For the canonical recipe-to-pattern table with deployment links, see the agent-deployments blueprint map.
Reverse lookup: which deployments use what?
Patterns (flow shapes)
| Pattern | Used by deployment recipe(s) as the agent_pattern: |
|---|---|
| Prompt Chaining | content-pipeline |
| Parallel Calls | parallel-enricher |
| Orchestrator-Worker | (composed inside code-review-agent, hierarchical-agent) |
| Evaluator-Optimizer | content-pipeline |
| ReAct | research-assistant, claude-code-subagent |
| Plan & Execute | code-review-agent |
| RAG | docs-rag-qa |
| Reflection | code-review-agent |
| Routing | customer-support-triage |
| Multi-Agent | ops-crew, hierarchical-agent, restaurant-rebooking |
| Event-Driven | restaurant-rebooking |
| Saga | (no current recipe — candidate for booking/order workflows) |
Primitives (building blocks)
| Primitive | Used by deployment recipe(s) as a primitives[] entry |
|---|---|
| Tool Use | Almost every recipe — it's the default. |
| Memory | memory-assistant, research-assistant, ops-crew, restaurant-rebooking |
| Skills | memory-assistant, claude-code-subagent |
Modifiers (transforms)
| Modifier | Used by deployment recipe(s) as a modifiers[] entry |
|---|---|
| Human in the Loop | (no current recipe — candidate for content moderation, code-review approval flows) |
Entries marked "no current recipe" are documented here but don't yet have a production-shaped example in agent-deployments. That's a contribution opportunity — see agent-deployments contributing guide.
Per-framework code variants
Pattern code lives under patterns/<name>/code/<lang>/<framework>/ — see `meta/style-guide.md` for the convention. _reference.py next to those directories holds the framework-agnostic MockLLM reference the design docs read against. When agent-scaffold resolves a recipe that targets a specific framework, its context assembler prefers the matching variant (e.g. a langgraph recipe loads patterns/<name>/code/python/langgraph/<name>.py) over the generic reference. ReAct is the current exemplar of the layout; other patterns follow in per-pattern PRs.
What every deployment inherits
The cognitive/operational boundary isn't decorative — it's load-bearing. Each pattern's design doc should be silent on these concerns; each deployment recipe must be explicit about them. The table below lists what agent-deployments always provides, so you know what you're not reading about in this repo.
| Concern | Where it's documented |
|---|---|
| Auth (JWT, API keys) | `agent-deployments/docs/cross-cutting/auth-jwt.md` |
| Rate limiting | `agent-deployments/docs/cross-cutting/rate-limiting.md` |
| Structured logging | `agent-deployments/docs/cross-cutting/logging-structured.md` |
| Observability + tracing | `agent-deployments/docs/cross-cutting/observability.md` |
| Idempotency | `agent-deployments/docs/cross-cutting/idempotency.md` |
| Testing strategy | `agent-deployments/docs/cross-cutting/testing-strategy.md` |
| Capability provisioning (vector DBs, queues, dashboards, etc.) | `agent-deployments/docs/capabilities/` |
See system-design-heritage for the long-form explanation of why these concerns live there and not here.
Picking a starting point
If you know the shape of the problem but not the agent:
- Use Choosing a Pattern to land on a pattern.
- Find your pattern in the table above, jump to the matching recipe.
- If no recipe exists, the pattern still ships with
overview→design→implementation+ reference code; the deployment recipe is the missing layer you'd add for production.
If you know the product feature but not the architecture:
- Skim the recipe list in `agent-deployments/docs/recipes/` — they're named by intent (e.g.
customer-support-triage,docs-rag-qa). - Open the closest recipe; its
Composes:section names the patterns it builds on. - Read those patterns here before extending the recipe.
Next step
Walk through the full lifecycle on one concrete example: Blueprint → Spec → Scaffold.