Most operators build every AI agent from scratch. They stare at a blank prompt, wrestle with the structure, and end up with something that works for one task but can't be reused anywhere else. After building over 30 agents across four ventures, I've realized there are exactly five AI agent design patterns that cover nearly every business automation I've ever needed. Once you recognize them, you stop reinventing. You see a problem, match it to a pattern, and ship a working agent in an afternoon instead of a week.
This post gives you all five blueprints — with real configurations I use in production — so you can pick the right pattern for your next automation and skip the trial-and-error phase entirely.
What Are AI Agent Design Patterns?
AI agent design patterns are reusable blueprints for structuring how an AI agent receives input, processes it, and delivers output. Think of them the way a builder thinks about floor plans. You don't design a house from a blank sheet every time. You pick a proven layout and customize it.
Each pattern solves a different type of business problem. Some problems need a one-shot transformation. Some need continuous monitoring. Some need multi-step processing. Some need intelligent routing. And some need knowledge that compounds over time.
When you know which pattern fits your problem, you make better design decisions from the start. You avoid over-engineering simple tasks and under-engineering complex ones. You also build agents that are easier to maintain, debug, and hand off to team members because they follow a recognizable structure.
Pattern 1: The Transformer — One Input, One Output
The Transformer is the simplest AI agent design pattern and the one every operator should master first. It takes a single input, processes it, and returns a single output. No memory, no loops, no external data — just a clean transformation.
When to use it:
- Content generation (write a product description from a spec sheet)
- Data extraction (pull key metrics from a report)
- Format conversion (turn meeting notes into action items)
- Translation or rewriting (convert technical docs to customer-facing copy)
Real example: I run a Transformer agent that takes a raw product spec — dimensions, materials, features — and outputs a fully formatted Amazon listing title, bullet points, and backend keywords. The input is a JSON object. The output is structured text. Nothing else happens.
The prompt structure:
You are a [role]. Given the following [input type], produce [output type].
Rules:
- [Constraint 1]
- [Constraint 2]
- [Output format specification]
Input:
The critical design decision: Transformers should be stateless. If the same input always produces acceptable output, you've got a good Transformer. If it needs context from previous runs, you need a different pattern.
Common mistake: Adding memory or multi-step logic to what should be a Transformer. If you catch yourself saying "and then it should also check..." you've probably left Transformer territory. That's a Pipeline trying to escape a single prompt.
Pattern 2: The Sentinel — Watch, Detect, Act
The Sentinel runs on a schedule, monitors a data source, and takes action when it detects a condition you care about. This is the AI agent design pattern behind every monitoring and alerting automation.
When to use it:
- Price tracking (alert when a competitor drops below your floor)
- Inventory monitoring (trigger a reorder when stock hits threshold)
- Reputation management (flag negative reviews within hours)
- Compliance checking (scan listings daily for policy violations)
Real example: I have a Sentinel that runs every morning at 6 AM, pulls the previous day's order data, and flags any product where the return rate exceeded 8% in the trailing seven days. If it finds something, it writes a summary and drops it into my morning briefing. If nothing triggers, it stays silent.
The prompt structure:
You are a monitoring agent. Check the following data for [condition].
Thresholds:
- [Threshold 1: what triggers an alert]
- [Threshold 2: what triggers escalation]
If no conditions are met, respond with: "No alerts."
If conditions are met, respond with:
- What triggered
- Current value vs. threshold
- Recommended action
Data:
Design decisions that matter:
- Polling frequency: Match it to how fast the underlying data changes. Hourly for prices. Daily for inventory. Weekly for competitive intel.
- Alert routing: Slack for informational. Email for action-required. Phone for urgent-only.
- Silence as signal: A well-tuned Sentinel is quiet most days. If yours fires more than twice a week, your thresholds are wrong.
Common mistake: Alert fatigue. The biggest Sentinel failure isn't missing something — it's alerting on everything. A Sentinel that cries wolf every day gets ignored, and then it misses the real problem. Be ruthless with your thresholds.
Pattern 3: The Pipeline — Stage by Stage
The Pipeline processes work through sequential stages where each stage's output feeds the next stage's input. This is the AI agent design pattern for complex, multi-step business processes that need different capabilities at each stage.
When to use it:
- Content production (research → outline → draft → edit → format → publish)
- Lead qualification (scrape → enrich → score → route → follow up)
- Onboarding automation (welcome → setup → training → check-in)
- Reporting chains (collect data → analyze → generate report → distribute)
Real example: My weekly content pipeline runs every Monday. Stage 1 pulls trending topics from industry feeds and scores them for relevance. Stage 2 generates a detailed outline from the top-scored topic. Stage 3 writes the first draft. Stage 4 runs an editorial pass against my style guide. Stage 5 formats for the CMS and stages it for review. Each stage has its own prompt optimized for that specific task.
The prompt structure for each stage:
You are stage [N] of a content pipeline.
Your input comes from stage [N-1]. Your output goes to stage [N+1].
Input format: [what you receive]
Output format: [what you produce]
Your job: [specific transformation for this stage]
Rules:
- [Stage-specific constraints]
- Do not attempt work outside this stage
Design decisions that matter:
- Stage boundaries: Draw them where the skill changes. Research is different from writing is different from editing. Each stage should feel like handing work to a different specialist.
- Intermediate storage: Save the output of each stage. When stage 4 fails (and it will), you want to re-run from stage 4, not stage 1.
- Quality gates: Add a check between stages. "Is this outline complete enough to draft from?" catches problems early instead of producing a bad draft from a bad outline.
Common mistake: Making stages too dependent on each other. Each stage should do ONE thing. I've seen operators build "pipelines" that are actually one massive prompt pretending to have stages. That's a Transformer wearing a trench coat.
Pattern 4: The Router — Classify and Dispatch
The Router receives mixed inputs, classifies them, and sends each to the right handler. This is the AI agent design pattern for any business process where different inputs need different treatment.
When to use it:
- Email triage (sort incoming email by type and urgency, route to the right response workflow)
- Support ticket routing (classify issue type, assign to the right resolution path)
- Task prioritization (score incoming tasks, assign to the right queue)
- Lead routing (qualify leads, assign to the right follow-up sequence)
Real example: My email Router classifies every incoming message into one of six categories: client request, vendor communication, sales inquiry, administrative, newsletter/noise, and urgent. Each category triggers a different downstream agent. Client requests get a draft response pulled from project context. Sales inquiries get qualified and logged. Newsletters get archived. Urgent items get flagged to my phone.
The prompt structure:
You are a classification agent. Classify the following message
into exactly ONE category:
Categories:
1. client_request — Direct request from an existing client
2. vendor — Communication from a supplier or vendor
3. sales_inquiry — New business or sales-related
4. administrative — Invoices, receipts, account notifications
5. noise — Newsletters, marketing, irrelevant
6. urgent — Time-sensitive, requires immediate human attention
Respond with:
- category: [one of the above]
- confidence: [high/medium/low]
- reasoning: [one sentence]
- suggested_action: [what should happen next]
Message:
Design decisions that matter:
- Confidence thresholds: Route high-confidence classifications automatically. Send medium-confidence to a human for confirmation. Flag low-confidence for manual review.
- Fallback category: Always have a "not sure" path. An unclassifiable input forced into the wrong category causes worse problems than one flagged for review.
- Category count: Start with 4-6. Every category you add reduces classification accuracy. I started my email Router with 12 categories and it was wrong 30% of the time. Collapsed to 6 and accuracy jumped to 92%.
Common mistake: Skipping the feedback loop. Track misrouted items. Every misclassification tells you something about your category definitions or your prompt. Review monthly and tighten the descriptions.
Pattern 5: The Accumulator — Build Knowledge That Compounds
The Accumulator is the most powerful AI agent design pattern and the least used. It runs repeatedly, builds a knowledge base over time, and gets smarter with every execution. While the other four patterns are stateless or session-scoped, the Accumulator explicitly stores and retrieves information across runs.
When to use it:
- Client intelligence (accumulate preferences, history, and communication style over every interaction)
- Market intelligence (build a competitive database that deepens with every scan)
- Operational learning (log what works and what doesn't across agent runs)
- Supplier profiles (track pricing trends, reliability scores, and response patterns)
Real example: I run an Accumulator that processes every client call transcript. After each call, it extracts key decisions, action items, preferences expressed, concerns raised, and scope changes. It appends these to a per-client knowledge file. When I prep for the next call, a Transformer reads the knowledge file and generates a briefing: what we discussed last time, outstanding items, known preferences, and suggested talking points.
After six months, my client knowledge files are better than anything I could maintain manually. They catch patterns I miss — "This client has mentioned delivery speed concerns in three of the last four calls. You may want to address it proactively."
The prompt structure:
You are a client intelligence agent. After each interaction,
extract and store the following:
- Key decisions made
- Action items (with owners and deadlines)
- Preferences expressed
- Concerns or objections raised
- Scope or priority changes
- Sentiment (positive / neutral / negative)
Existing knowledge (from previous interactions):
New interaction:
Output: Updated knowledge file with new information integrated.
Do not remove existing entries — append and update.
Flag any contradictions with previous entries.
Design decisions that matter:
- Storage format: Structured Markdown with headers beats raw JSON for readability. You will read these files when debugging.
- Deduplication: Build dedup logic into the extraction prompt. "If this information is already captured, skip it."
- Pruning: Schedule a quarterly cleanup. Supplier pricing from eight months ago isn't actionable. Accumulation without pruning is hoarding.
- Retrieval: The Accumulator is only as good as its retrieval. Index by entity (client name, supplier, product), not by date.
Common mistake: Accumulating everything. An Accumulator that stores every detail becomes noisy and slow. Be opinionated about what you extract. Five sharp insights per interaction compound better than fifty vague notes.
How to Choose the Right AI Agent Design Pattern
Here's the decision tree I use every time I scope a new automation:
- Does the task have a single input and single output with no external dependencies? → Transformer
- Does the task require monitoring something over time and acting on conditions? → Sentinel
- Does the task involve multiple sequential steps where each step requires a different skill? → Pipeline
- Does the task involve classifying varied inputs and routing them to different handlers? → Router
- Does the task get better with accumulated knowledge from previous runs? → Accumulator
Most automations are Transformers. That's fine. Don't over-engineer.
About 70% of my agents are Transformers, 15% are Sentinels, 10% are Pipelines, and the remaining 5% split between Routers and Accumulators. The Accumulators are the most valuable per-agent, but you need the simpler patterns running first.
Hybrid patterns are real. My morning briefing system combines a Sentinel (monitors overnight data), a Pipeline (processes and formats the briefing), and an Accumulator (tracks what I acted on vs. ignored to improve relevance over time). But I built each component as a clean single-pattern agent first, then composed them. Start clean. Combine later.
Common Mistakes When Applying AI Agent Design Patterns
Picking a pattern that's too complex. If a Transformer solves the problem, don't build a Pipeline. Extra complexity means more failure points, harder debugging, and longer build time. Start simple. Upgrade the pattern only when the simple one actually breaks.
Mixing patterns without naming them. A "Transformer" that also monitors a feed and routes based on content type is actually a Sentinel-Router hybrid. Name what you're building. If you can't name the pattern, you probably don't have a clean design.
Ignoring the handoff format. In Pipelines and Routers, the data format between stages matters more than the prompt quality of any single stage. Spend time defining clean interfaces. A well-defined JSON handoff between Pipeline stages prevents 80% of debugging sessions.
Not testing components in isolation. Before you connect stages in a Pipeline, test each stage as a standalone Transformer. Before you deploy a Router, test each category handler independently. Composed systems fail in the connections, not the components.
Skipping the "do I even need an agent?" question. Some tasks don't need AI at all. A simple Zapier automation or a cron job running a shell script might be the right answer. AI agents add value when the task requires judgment, interpretation, or language understanding. If it's pure data movement, use a simpler tool.
FAQ
What's the difference between AI agent design patterns and AI agent frameworks?
Design patterns describe the structure and data flow of your agent — how it receives input, processes it, and delivers output. Frameworks are software tools (like LangChain, CrewAI, or Claude Code) that you build agents with. You apply a design pattern regardless of which framework you choose. Patterns are the blueprint. Frameworks are the construction tools.
Can I combine multiple design patterns in one system?
Yes, and you should once your fleet grows. Start with clean single-pattern agents, then compose them. My content system uses a Sentinel to detect trending topics, a Pipeline to produce the content, and an Accumulator to track which topics performed best. Each component was built and tested as a standalone agent first.
Which pattern should I build first?
Start with a Transformer. Pick the most repetitive text-in-text-out task in your business and automate it. Once you have three to five Transformers running reliably, build your first Sentinel for something you already check manually every day. Graduate to Pipelines and Routers as your agent fleet matures.
How do I know when to upgrade from one pattern to another?
Listen to the friction. When a Transformer starts needing "context from the last run," it wants to be an Accumulator. When a single-prompt agent keeps growing with "and then also do this," it's becoming a Pipeline. When you add if/else logic for different input types, you need a Router. The right pattern eliminates friction. The wrong one creates it.
Do these patterns work with any AI model?
Yes. These patterns are model-agnostic. I use them primarily with Claude through Claude Code, but the same blueprints apply whether you're using GPT, Gemini, or open-source models. The pattern describes the architecture, not the underlying model.
Your Next Move
You don't need to memorize all five AI agent design patterns today. Here's what to do this week:
- Audit your existing agents. Look at every automation you're running and name its pattern. If you can't name it, that's your first redesign candidate.
- Build one clean Transformer. Pick a task you do manually at least three times a week. Build a Transformer agent with a clean input, clear constraints, and a well-defined output format. Ship it today.
- Pick your first Sentinel. What do you check manually every morning? A dashboard, a competitor's site, a data feed? Build a Sentinel that does the checking and only alerts you when something actually matters.
The operators who build fastest aren't the ones who write the best prompts. They're the ones who recognize which AI agent design pattern fits the problem and execute without hesitation. Once you see these five blueprints everywhere, you'll never build from scratch again.