Choosing the Right Patterns

Start with the Failure Mode

Do not start by asking which pattern is popular. Start by asking what is most likely to break first.

Usually that is one of five things:

1. Control: the agent acts too freely or too opaquely
2. Memory: the agent forgets what matters or carries the wrong context forward
3. Tool use: the agent has too much access or uses tools unreliably
4. Reliability: the system fails silently, drifts, or becomes hard to debug
5. Throughput: the workflow is too slow, too serial, or too expensive

Once you know the failure mode, the catalog becomes much easier to narrow.

Use the Three Discovery Surfaces

The site now has three useful ways to narrow the library:

• Use the Decision Guide when you want a fast shortlist
• Use Browse Patterns when you want to compare trade-offs directly
• Use the Pattern Graph when you want to see what tends to cluster together

The best workflow is:

1. Start with /decision
2. Open 3-6 candidate patterns in /patterns
3. Use /graph to spot adjacent patterns worth considering
4. Commit to a small stack for v1

Match the Pattern to the Problem

If control is the main risk

Start with patterns that make agent behavior legible and bounded:

• Specification-Driven Agent Development
• Plan-Then-Execute Pattern
• Human-in-Loop Approval Framework
• Spectrum of Control / Blended Initiative

Use these when the problem is not raw capability but confidence in who decides what and when.

If memory is the main risk

Start with patterns that control context and persistence:

• Working Memory via TodoWrite
• Curated File Context Window
• Curated Code Context Window
• Episodic Memory Retrieval & Injection
• Memory Synthesis from Execution Logs

Use these when the agent either forgets important state or drowns in too much irrelevant context.

If tool use is the main risk

Start with patterns that make execution safer and more predictable:

• Code-Then-Execute Pattern
• Sandboxed Tool Authorization
• Tool Capability Compartmentalization
• Action-Selector Pattern
• Tool Selection Guide

Use these when the biggest problem is not reasoning quality but unsafe or messy interaction with the outside world.

If reliability is the main risk

Start with patterns that improve observability, evaluation, and recovery:

• LLM Observability
• Reflection Loop
• Workflow Evals with Mocked Tools
• Schema Validation Retry with Cross-Step Learning
• Deterministic Security Scanning Build Loop

Use these when the system appears to work until it suddenly does not, or when debugging costs more than building.

If throughput or scale is the main risk

Start with orchestration patterns that reduce idle time and improve routing:

• Asynchronous Coding Agent Pipeline
• Parallel Tool Execution
• Budget-Aware Model Routing with Hard Cost Caps
• Planner-Worker Separation for Long-Running Agents
• Workspace-Native Multi-Agent Orchestration

Use these when the system already works in principle but cannot ship efficiently.

Good Starting Stacks

Start with 2-4 patterns, not 8-12.

Minimum viable coding-agent stack

• Specification-Driven Agent Development
• Code-Then-Execute Pattern
• Human-in-Loop Approval Framework
• LLM Observability

This is a good default when code quality and control matter more than autonomy theater.

Minimum viable autonomous stack

• Continuous Autonomous Task Loop Pattern
• Reflection Loop
• Episodic Memory Retrieval & Injection
• Progressive Autonomy with Model Evolution

This is a good default when the agent needs to operate beyond a single request-response cycle.

Safety-first stack

• Human-in-Loop Approval Framework
• Egress Lockdown (No-Exfiltration Channel)
• Deterministic Security Scanning Build Loop
• Anti-Reward-Hacking Grader Design

This is a good default when the cost of a bad action is much higher than the cost of slower execution.

What Not to Add Too Early

Teams usually over-add patterns in the first version. Common mistakes:

• adding long-term memory before the agent can reliably complete one session
• adding multiple orchestration layers before a single-agent path is stable
• adding autonomy before observability and approval boundaries exist
• adding too many tools before tool selection and authorization are explicit
• adding evaluator loops without a clear success criterion

If you cannot explain why a pattern reduces a current failure mode, leave it out of v1.

A Practical Selection Workflow

Use this sequence when you are unsure where to start:

1. Write down the primary task and the most expensive failure mode.
2. Use the Decision Guide to narrow to a short list.
3. Open the candidate patterns and compare:
   • control model
   • memory requirements
   • tool surface
   • safety bar
   • operational cost
4. Use the Pattern Graph to find adjacent patterns worth adding later, not immediately.
5. Pick 2-4 patterns for the first version.
6. Add more only after you can explain what the previous stack still fails to solve.

A Useful Rule of Thumb

If you are building your first production version, bias toward:

• explicit control over autonomy
• narrow tool access
• simple memory
• strong observability
• short, testable workflows

Most systems need fewer clever patterns and more operational clarity.

Next Steps

• Start with the Decision Guide
• Browse the full catalog in Patterns
• Use the Pattern Graph to see neighboring ideas
• Read the detail pages for the 2-4 patterns you plan to combine