Agentic Design Patterns Reference — Claude Cert Academy

Common patterns for building reliable, efficient agentic systems with Claude. Each pattern describes the structure, when to use it, and how to implement it.

Pattern 1: Orchestrator-Worker

One orchestrator agent coordinates multiple specialized worker agents. Workers run in parallel and report results back.

• Use when: task has independent subtasks that can run concurrently
• Orchestrator responsibility: decompose task, dispatch workers, aggregate results
• Worker responsibility: execute a focused subtask and return structured output
• Failure handling: orchestrator retries failed workers or proceeds with partial results

# Orchestrator dispatches parallel workers
results = await asyncio.gather(
    worker("analyze security", code),
    worker("check style", code),
    worker("review logic", code),
)
summary = aggregate(results)

Pattern 2: Critic-Generator

One agent generates output; a second agent critiques it. Repeat until quality threshold is met.

• Use when: quality is critical and a single pass is not reliable enough
• Generator: produces initial output based on the task
• Critic: evaluates output against a rubric and returns structured feedback
• Loop: generator revises based on feedback, up to a maximum iteration count
• Stopping condition: critic score exceeds threshold OR max iterations reached

for _ in range(max_iterations):
    output = generator.run(task)
    critique = critic.evaluate(output, rubric)
    if critique.score >= THRESHOLD:
        return output
    task = f"{task}\n\nPrevious attempt feedback: {critique.feedback}"

Pattern 3: Pipeline (Sequential Chain)

Output of each agent becomes input to the next. Each step is specialized.

• Use when: task has a natural linear flow with transformations at each step
• Each step adds or transforms; downstream agents see all prior output
• Keep steps focused — a step that does two things should usually be two steps
• Checkpointing: save intermediate results so failures do not restart the whole pipeline

Pattern 4: Human-in-the-Loop

Agent pauses at defined checkpoints and waits for human approval before continuing.

• Use when: downstream actions are irreversible or high-stakes
• Approval gates: file delete, external API call, payment, email send
• Present: what the agent proposes to do, with context and alternatives
• Design: async approval so the agent suspends without consuming resources

Always include a human-in-the-loop gate before irreversible actions in production. The cost of one extra confirmation is lower than the cost of one bad action.

Pattern 5: Leaderless Swarm

Multiple identical workers pull tasks from a shared queue. No central coordinator.

• Use when: tasks are homogeneous, independent, and high-volume
• Workers are stateless — they pull, process, and push results
• Scaling is linear — add workers to increase throughput
• Failure handling: tasks return to queue if a worker fails; use dead-letter queues for repeated failures

Pattern 6: Validator Wrapper

A thin validation layer wraps every agent call to check output format and quality.

• Use when: downstream systems expect structured output (JSON, CSV, specific format)
• Validator checks: schema compliance, required fields, data type correctness
• On failure: retry with error feedback injected into the prompt, up to max_retries
• Log all validation failures for prompt debugging

def agent_with_validation(prompt, schema, max_retries=3):
    for attempt in range(max_retries):
        result = agent.run(prompt)
        error = validate(result, schema)
        if not error:
            return result
        prompt = f"{prompt}\n\nPrevious output had errors: {error}. Fix and retry."
    raise ValidationError("Max retries exceeded")

Context Management Strategies

• Summarize at checkpoints: after each major step, compress history to key facts
• External memory: store large datasets in vector stores or databases; retrieve selectively
• Context budgeting: allocate tokens across system prompt, history, and new input; monitor usage
• Sliding window: keep the last N exchanges and summary of earlier history

Tool Design Principles

• One tool, one action: avoid multi-action tools; they are harder to recover from
• Return stable identifiers: agents can reference results by ID in subsequent calls
• Rich descriptions: 3-4 sentences explaining what, when, and limits
• Error messages in content: return errors as readable content, not exceptions
• Idempotency: design tools so calling them twice produces the same result (safe to retry)

Failure Mode Checklist

• Context overflow: implement /compact or summarization before the window fills
• Infinite loops: always set max_iterations on loops and critic patterns
• Tool misuse: write detailed tool descriptions; add validation hooks
• Prompt injection: delimit untrusted content with XML tags
• Runaway costs: set per-session token budgets and alert on overrun
• Stale knowledge: for time-sensitive tasks, supply current data via tools not training knowledge

Continue to Claude Cert Academy