Agent Architecture
Intermediate 12 min read Agent Architecture

Agent Design Patterns

Known shapes for known problems

Agents come in recognizable shapes: single-loop, router/planner, orchestrator-workers, evaluator-optimizer. Choosing the pattern — not inventing one — determines complexity, reliability and cost.

design patternsingle looprouterorchestratorevaluatorpattern
Prerequisites: AI Agents Overview
Before we start

What you will learn

  • Recognize the common agent patterns
  • Match a pattern to task shape and stakes
  • Avoid over-architecting simple tasks
Introduction

What is this?

Design patterns capture proven agent shapes: single agent loop (most tasks), router (dispatch by type), parallelization (independent splits), orchestrator+workers (delegation), and evaluator-optimizer (generate-then-refine). Choose the simplest pattern that meets reliability needs; complexity is a cost, not a virtue.

Motivation

Why do you need it?

  • Patterns encode worked-out failure handling.
  • Matching shape to task reduces drift and cost.
  • Teams inherit debugging and eval discipline with the pattern.
  • Simple first; refactor to a richer pattern when evals demand it.
Think about it

Mental model

Imagine

Software design patterns

Think of

Agent patterns

Like the classic Gang of Four moves, agent patterns are proven recipes: 'when do I need a facade?' becomes 'when do I need an orchestrator?'. Use the recipe that fits; don't re-invent a composite for a task that a for-loop solves.

Mechanics

How it works

  • Identify the task contour: single path? parallel splits? need refinement?
  • Map to a pattern: loop, router, parallel, orchestrated, evaluator-optimizer.
  • Start minimal; add structure only where measured need appears.
  • Evals compare the enriched pattern against the baseline.
  • Document the chosen pattern for the team.

Pattern picker.

Task
Single?
Split?
Refine?
Route?
Real world

In production

  • Support desks: router → specialist subagents.
  • Research: orchestrator fans out per-question searches.
  • Writing/analysis: evaluator-optimizer iterates drafts.
Guidelines

Best practices

  • Start with the single loop; add structure on evidence.
  • Keep the chosen pattern readable and observable.
  • Document why the pattern fits (graded by evals).
  • Reuse the pattern's standard failure handling.
Watch out

Common mistakes

  • Orchestrator-of-everything just to feel advanced.
  • Mixing patterns with no boundary (confusing state flow).
  • Skipping evals that justify added complexity.
Root cause analysis

Common issues

Error
Parallel splits produce inconsistent outputs
Root cause

Shared state mutation

Fix

Isolate each split-worker's state; merge at the end deterministically.

Error
Optimizer never converges
Root cause

Evaluator without a stopping bar

Fix

Define explicit acceptance criteria and a max-iteration cap.

When things break

Debugging tips

  • Task small but architecture huge → revert to minimal loop; complexity costs.
  • Refinement loops endless → evaluator's criteria vague; make checkable.
  • Router misroutes → router decision criteria unclear; measure routing accuracy.
Interviews

Interview checkpoint

Practice

Hands-on lab

Router + Specialist Pipeline
30 min · intermediate
In progress
Objectives
  • Route an intent to a specialist function
  • Return structured results from each specialist
  • Compose the pipeline and aggregate its output

Router + Specialist Pipeline

30 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Best first choice for a straightforward task:

2

Complexity is a feature agents should aspire to.

Go deeper

Official documentation