Agentic Design Patterns
The shapes agents are built from, each one runnable and each one read against the ten principles.
What a pattern carries that an example does not
Every pattern states which principles it expresses directly in code, which ones its textbook implementation quietly breaks, and what to add when it does. That third column is the part nobody else publishes. Knowing that ReAct makes reasoning inspectable is common knowledge; knowing that its default form gives you no way to steer it mid-run, and what to add so it does, is the part that bites in production.
Three kinds of relation, and silence is the fourth
A pattern claims structural where it expresses a principle in code, default gap where its default breaks one, and depends where your implementation decides rather than the pattern. Most principles get no row at all, which is deliberate. Patterns are shapes of inference; the principles govern how work is delegated and made visible. Forcing a verdict into every cell would produce a grid that is mostly assertion.
Tools and actions (1)
The workhorse loops. Reach for these first.
Reasoning and reflection (1)
Spend more thinking to buy reliability.
Retrieval (1)
Ground the answer in something outside the model.
Memory (1)
State that survives into the next session.
Sampling and search (1)
Generate several candidates, then pick.
Multi-agent (1)
Split the work when it is genuinely parallel.
Safety and routing (1)
Decide what runs, and what stops to ask.
Specialty (0)
Narrow shapes for narrow problems.
Part of the taxonomy. No pattern has been built for this family yet.
How this differs from the other two pattern surfaces
These are reasoning shapes: how an agent decides, when it acts, what it remembers. The AI Pattern Blueprint covers a different layer, how to compose the interface around an AI-mediated surface. Agent runtime architecture covers a third, the deployment concerns of triggers, scheduling, context loading and recovery. A system usually needs all three, and they answer different questions.
These relations are analysis, not a validation run
The relations are first-party doctrine analysis written alongside the code, not the output of a scored validator run. They are honest about which technique they describe and cite its source paper; they never assess a named vendor framework. To get a scored verdict, run the validator against your own repository.
Doctrine relations are first-party analysis, not the output of a validation run. Run the validator on your own code to get a scored verdict.
Also in this section