agentic-design-patterns

name

agentic-design-patterns

description

Select and apply the right agentic design pattern when building an AI agent, workflow, or multi-step LLM system. Use this skill whenever the user is designing, architecting, debugging, or reviewing an agent/LLM pipeline and needs to decide HOW to structure it -- e.g. they mention agents, orchestration, multi-step workflows, RAG, routing, tool use, retries, evaluation, guardrails, memory, planning, or ask "how should I build/structure this agent?" or "which pattern fits this problem?". Maps problem symptoms to one of 20 patterns and specifies, for each, which steps are LLM calls vs deterministic code and what context each call carries. Use it even when the user does not say the word "pattern".

Agentic Design Patterns

A decision aid for choosing and implementing the right structure for an agentic / multi-step LLM system. This skill does two things: (1) maps a problem to the pattern(s) that solve it, and (2) for the chosen pattern, gives an implementation spec that distinguishes LLM calls from deterministic code and states the context strategy for each call.

Most real systems combine several patterns. Do not force a single choice when composition is the right answer.

How to use this skill

1. Read the user's problem and extract the symptoms (what's hard, what's breaking, what's expensive).
2. Match symptoms to pattern(s) using the Selection table below.
3. For each selected pattern, open references/patterns.md and read that pattern's entry. It contains the step-by-step mechanics: every step tagged [LLM] or [CODE], a literal prompt template for each [LLM] step, and the context strategy.
4. When proposing an architecture, explicitly label which steps are model calls and which are plain code, and state what each LLM call carries in its context (fresh / appended / retrieved / batched). This is the most common thing engineers get wrong, so make it explicit.
5. If multiple patterns apply, describe how they nest (see Composition below).

The 20 patterns, by family

Orchestration — how work is structured, split, and routed

1. Prompt Chaining · 2. Routing · 3. Parallelization · 4. Planning · 5. Multi-Agent Collaboration · 14. Inter-Agent Communication

Reliability & Safety — how you keep the system from breaking 6. Reflection · 11. Exception Handling & Recovery · 12. Human-in-the-Loop · 17. Evaluation & Monitoring · 18. Guardrails & Safety

Knowledge & Memory — how the system remembers and retrieves 8. Memory Management · 9. Learning & Adaptation · 13. Knowledge Retrieval (RAG) · 20. Exploration & Discovery

Reasoning & Resources — how it thinks and what it spends 7. Tool Use · 10. Goal Setting & Monitoring · 15. Resource-Aware Optimization · 16. Reasoning Techniques · 19. Prioritization

Selection table (symptom → pattern)

Match on the symptom, not the buzzword. Read the right column entry in references/patterns.md before recommending.

If the problem is…	Reach for
One big task that decomposes into ordered steps, each validating the last	1. Prompt Chaining
Requests of different kinds that should go to different handlers/tools	2. Routing
A large job made of independent chunks that can run at once	3. Parallelization
An ambitious goal that needs a plan before any execution	4. Planning
Several specialized roles cooperating on one deliverable	5. Multi-Agent Collaboration
Agents that must message each other with protocols/IDs (rarely worth it)	14. Inter-Agent Communication
Output quality is inconsistent; you want draft → critique → revise	6. Reflection
Calls fail (timeouts, rate limits, bad data) and you need graceful recovery	11. Exception Handling & Recovery
A decision is high-stakes / irreversible and needs human approval	12. Human-in-the-Loop
You need to catch quality drift/regressions before users do	17. Evaluation & Monitoring
Untrusted input: PII, prompt injection, harmful content	18. Guardrails & Safety
The system should remember facts across turns/sessions	8. Memory Management
The system should improve from feedback/corrections over time	9. Learning & Adaptation
Answers must be grounded in a document corpus	13. Knowledge Retrieval (RAG)
Open-ended research: gather broadly, cluster, then focus	20. Exploration & Discovery
The model needs external info or actions (APIs, calculators, DBs)	7. Tool Use
Autonomous work tracked against measurable targets/KPIs	10. Goal Setting & Monitoring
Cost matters; route cheap tasks to cheap models	15. Resource-Aware Optimization
Genuinely hard reasoning needing branching/debate (rarely needed)	16. Reasoning Techniques
Many competing tasks that must be ordered and re-ordered dynamically	19. Prioritization

Context strategy — the cross-cutting decision

For every LLM call you place, decide what it carries. Getting this wrong causes either context explosion (cost + hallucination) or missing information. The recurring strategies:

• Fresh per step — the call gets only the previous step's output + its instruction, not the running history. State lives in your code, not a growing thread. (Prompt Chaining.)
• Appended / growing thread — one conversation where tool results or turns accumulate until the model stops. (Tool Use.)
• Sliding window — carry only the last N relevant turns (e.g. last draft + last critique). (Reflection.)
• Batched fan-out + reduce — N isolated calls each holding only their chunk, then one merge call holding all outputs. (Parallelization, parts of Reasoning, Exploration, Evaluation.)
• Retrieved injection — store knowledge/memories externally; inject only the top-K relevant items into the next call. (RAG, Memory Management.)
• Offline / out-of-band — batched analysis calls that don't sit in the live request path. (Learning & Adaptation, Evaluation.)

LLM vs. deterministic code — default to code

A frequent mistake is putting the model where plain code belongs. Defaults to encode when recommending:

• Keep out of the control path: retries, backoff, error classification by status code, threshold gates, routing dispatch, scoring formulas, dedup/normalization, schema validation, vector search. These are [CODE].
• Use the model for: open-ended generation, classification of fuzzy intent, extraction from unstructured text, critique against a rubric, synthesis, and proposing (not executing) high-stakes actions. These are [LLM].
• When in doubt, prefer a deterministic check around an LLM call rather than a second LLM call to check the first.

Composition (patterns nest)

Real systems chain patterns. Common compositions:

• Front door: Guardrails (18) → Routing (2) → specialist agent. Sanitize and classify before any expensive work.
• A specialist agent is usually Tool Use (7) wrapped in Exception Handling (11), and may use Reflection (6) for quality.
• Heavy throughput: Parallelization (3) for fan-out, with Resource-Aware Optimization (15) choosing model tiers per chunk.
• Knowledge tasks: RAG (13) for grounding + Memory Management (8) for continuity.
• Anything autonomous in production: wrap in Evaluation & Monitoring (17), Goal Setting (10), and Human-in-the-Loop (12) at the risky points.

When you recommend a composition, draw the call graph and annotate each node [LLM]/[CODE] and its context strategy.

Output format when advising

Unless the user asks otherwise, structure architecture recommendations as:

1. Pattern(s) chosen and the symptom each addresses (one line each).
2. Call graph — the steps in order, each tagged [LLM] or [CODE].
3. Prompt templates for the [LLM] steps (use {{placeholders}} for interpolated data; label system / user / tool roles).
4. Context strategy — one line per LLM call stating what it carries.
5. Failure handling — what happens when a step fails (retry / fallback / human / escalate).
6. Trade-offs — the main con of the chosen pattern and how to mitigate it.

Reference

references/patterns.md contains the full spec for all 20 patterns: TL;DR, when to use, pros/cons, a worked scenario, the context strategy, and the step-by-step [LLM]/[CODE] mechanics with prompt templates. Always read the relevant entry before giving implementation-level advice — do not reconstruct the mechanics from memory.