<aside>

**Foundation Patterns | Advanced Patterns | Cross-Cutting | Pitfalls | Example**

</aside>

<aside>

A practical framework for designing AI agents from prototype to production

Six core patterns. When to use each, how they work, and the trade-offs that matter.

Built from designing and shipping agentic workflows in SaaS - the patterns I reach for, the trade-offs that decide between them, and the failure modes worth avoiding.

When to Use This

• Designing a new AI agent or agentic workflow from scratch.
• Evaluating whether a single agent is enough or you need multi-agent orchestration.
• Choosing between sequential, parallel, loop, coordinator, and agent-as-tool patterns.
• Auditing an existing agent system for the wrong pattern fit.
• Preparing for AI / agent design interviews or technical reviews.

<aside> <img src="/icons/bullseye_orange.svg" alt="/icons/bullseye_orange.svg" width="40px" />

TL;DR

• Start simple (single agent).
• Add structure when you need reliability (sequential, parallel).
• Add intelligence when you need adaptability (loop, coordinator, agent-as-tool).
• Every pattern trades off control, flexibility, latency, and cost. </aside>

<aside> <img src="/icons/light-bulb_orange.svg" alt="/icons/light-bulb_orange.svg" width="40px" />

Key Principle

The right pattern is the simplest one that still meets the quality bar. Most production agent systems are single agents or sequential chains, not multi-agent systems.

</aside>

</aside>

<aside>

Decision Framework

Goal: Pick the right pattern in under a minute by answering four questions in order.

1. Fixed or dynamic flow? Fixed → workflow agent (sequential, parallel, loop). Dynamic → LLM-driven router (coordinator, agent-as-tool).
2. Sub-tasks independent or ordered? Independent → parallel. Ordered → sequential.
3. Need a quality bar or guardrail? Yes → wrap output in a loop (review & critique).
4. Who owns state? Sub-agent owns state → coordinator. Primary agent owns state → agent-as-tool.

<aside> <img src="/icons/light-bulb_orange.svg" alt="/icons/light-bulb_orange.svg" width="40px" />

Pro Tip!

If you can't answer Q1 cleanly, you don't have a flow yet, you have a prompt. Stay with a single agent until the path forks for a real reason.

</aside>

Pattern Selector

<aside>

1. Single Agent

Goal: Handle the entire task with one LLM, one system prompt, and an optional tool list.

When to Use

• Prototypes and proofs of concept.
• Tasks where the path to the answer is open-ended.
• A single capability with no decomposition (e.g., summarize, classify, draft).

How It Works

• One agent, one prompt, optional tool list.
• The agent decides what to do at each step based on the user input and tool outputs.
• No predefined order, no shared state, no sub-agents.

Trade-offs

• ✅ Simple to build and reason about.
• ✅ Maximally flexible.
• ❌ Hard to control output quality and step order.
• ❌ Long prompts get unwieldy as complexity grows.

Example

A trip-planning assistant that takes a destination and returns a draft itinerary in one shot.

<aside> <img src="/icons/light-bulb_orange.svg" alt="/icons/light-bulb_orange.svg" width="40px" />

Pro Tip!

If your prompt grows past one screen, the task is asking for decomposition. Move to sequential or coordinator before patching the prompt again.

</aside>

Flow

---
config:
  layout: elk
  elk:
    nodePlacementStrategy: NETWORK_SIMPLEX
---
flowchart TD
    U["User Request"] e1@==> A["LLM Agent<br><i>system prompt + tools</i>"]
    A [email protected]>|"optional call"| T1["Tool A"]
    A [email protected]>|"optional call"| T2["Tool B"]
    T1 [email protected]>|"result"| A
    T2 [email protected]>|"result"| A
    A e6@==> R["Response"]

    e1@{ animation: slow }
    e2@{ animation: slow }
    e3@{ animation: slow }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: slow }

    style U fill:#F0F4F8,stroke:#37474F,stroke-width:2px,color:#333
    style A fill:#E8DFF5,stroke:#5E35B1,stroke-width:2px,color:#333
    style T1 fill:#FFF8E1,stroke:#F57F17,stroke-width:2px,color:#333
    style T2 fill:#FFF8E1,stroke:#F57F17,stroke-width:2px,color:#333
    style R fill:#E8F5E9,stroke:#2E7D32,stroke-width:2px,color:#333

</aside>

<aside>

2. Sequential Agent

Goal: Run a fixed pipeline of sub-agents where the output of step N becomes the input to step N+1.

When to Use

• Structured, repeatable workflows.
• Tasks with a known, fixed order of operations.
• Pipelines where each step has a distinct specialty (e.g., research → draft → edit).

How It Works

• Sub-agents share a session state, a shared scratchpad scoped to one run.
• Each sub-agent writes its output to state. The next agent reads it through prompt variables
• This shared state is a form of short-term memory for the agent system.
• The flow is like an assembly line. The order is fixed at design time.

Trade-offs

• ✅ High control and reliability.
• ✅ Easy to unit-test each step in isolation.
• ❌ Inflexible: cannot adapt to dynamic situations.
• ❌ If one step fails, the rest stalls.

Example

Trip planner: food_finder runs first, then transportation_agent reads the food output from session state and plans transit around it.

</aside>

<aside>

</aside>

<aside>

</aside>

<aside>

</aside>

<aside>

</aside>

<aside>

</aside>