Agentic AI Design Patterns: Proven Patterns for Building Autonomous Systems

Most LLM applications follow a simple request-response flow: send a prompt, get a completion. Agentic systems break that mold. Instead of generating a final answer in one shot, an agentic workflow prompts the LLM to reason through steps, call external tools, evaluate its own output, and iterate until the result meets a quality bar.

Andrew Ng formalized this shift in early 2024 when he identified four foundational agentic design patterns: Reflection, Tool Use, Planning, and Multi-Agent Collaboration. These patterns describe how an AI agent decides what to do next, checks its own work, interacts with external systems, and coordinates with other agents.

Since then, the pattern vocabulary has grown. Anthropic published five workflow patterns (Prompt Chaining, Routing, Parallelization, Orchestrator-Workers, Evaluator-Optimizer) that describe the control flow around LLM calls. Google Cloud documented 12 patterns ranging from single-agent systems to swarm architectures. The common thread across all of them: treating agent construction as a software architecture problem, not just a prompting exercise.

The practical difference matters. Teams using structured agentic patterns report 2-3x faster agent development cycles compared to ad-hoc implementations, because patterns give you a shared vocabulary for the recurring decisions every agent system faces: when should the agent stop and ask? How do you prevent infinite loops? Where does state live between steps?

Andrew Ng's framework remains the most widely referenced starting point for understanding how agents work. Each pattern addresses a specific capability gap in single-shot LLM calls.

Reflection The reflection pattern has an agent evaluate its own output against explicit criteria, identify problems, and produce a revised version. The cycle repeats until the output passes a quality threshold or hits an iteration limit.

The implementation has three phases. First, the agent generates an initial response. Second, a separate prompt (or a different model entirely) critiques that response against specific criteria like accuracy, completeness, or safety. Third, the agent regenerates its response incorporating the critique. Research shows reflection can improve performance on coding benchmarks like HumanEval from 80% to 91%.

The key implementation detail: keep the critic independent from the generator. At minimum, use a separate system prompt with different instructions. For high-stakes applications, use a different model. If the critic shares the generator's blind spots, you get shallow self-agreement instead of genuine evaluation. And always set explicit iteration bounds. Without a maximum loop count, an agent that keeps finding marginal improvements will run forever.

Tool Use

Tool use follows a four-phase cycle: define available tools with structured schemas, let the LLM select and parameterize a tool call, invoke the tool in your runtime, and feed results back into the conversation. This is what separates an agent from a chatbot. A chatbot can only work with information in its context window. An agent with tool access can query databases, call APIs, read files, and write outputs to external systems.

Every major LLM provider now supports structured tool calling natively. The practical challenge isn't connecting tools but designing good tool schemas. Vague tool descriptions produce unreliable tool selection. Overly specific schemas make the tool set brittle. The sweet spot: each tool does one thing, with a clear description of what it returns and when to use it.

Planning

Planning breaks a complex goal into a sequence of steps before execution begins. The simplest form is a numbered list the agent generates and then executes step by step. More sophisticated implementations use tree search or Monte Carlo methods to evaluate multiple plans before committing.

Two main variants exist. Plan-then-execute generates the full plan upfront and follows it rigidly. Plan-act-reflect generates a plan, executes a step, evaluates the result, and adjusts the plan before continuing. The second approach handles uncertainty better but costs more in LLM calls.

Planning is where most agent systems hit their first scalability wall. A plan with 20 steps accumulates context window pressure, and each step's output feeds into the next. Managing that context, deciding what to keep and what to summarize, is the real engineering challenge.

Multi-Agent Collaboration Multi-agent collaboration assigns different roles to specialized agents that coordinate on a shared task. One agent might research, another might write, a third might review. Each agent has its own system prompt, tool access, and responsibility boundary.

The pattern works because specialization improves quality. A single agent trying to research, write, and review struggles with role confusion. Dedicated agents with clear boundaries produce better results at each stage. The coordination overhead is real, though. You need a protocol for how agents communicate, how conflicts are resolved, and how the final output gets assembled.

Anthropic's "Building Effective Agents" guide draws a sharp distinction between workflows and agents. In a workflow, the developer controls the flow through predefined code paths. In an agent, the LLM dynamically directs its own process. Both are useful, and Anthropic's five workflow patterns describe the control flow structures that sit underneath most agent implementations.

Prompt Chaining

Prompt chaining decomposes a task into a fixed sequence of steps where each LLM call processes the output of the previous one. Between steps, you can insert programmatic checks ("gates") to verify the process stays on track. Marketing copy generation followed by translation is a classic example: generate the copy, validate tone, translate, validate the translation.

Use prompt chaining when you can decompose a task into fixed subtasks and you're willing to trade latency for accuracy.

Routing

Routing classifies an input and directs it to a specialized handler. Customer service is the textbook case: route general questions to one prompt, refund requests to another, and technical issues to a third. The pattern prevents optimization for one input type from hurting performance on others.

This pattern works well when you have distinct categories that require meaningfully different handling, and when classification accuracy is high enough to make routing reliable.

Parallelization

Parallelization runs multiple LLM calls simultaneously with results aggregated programmatically. It comes in two flavors: sectioning (breaking a task into independent parallel subtasks) and voting (running the same task multiple times for diverse outputs). Code review is a good example of sectioning: scan for security vulnerabilities in one call, check for performance issues in another, evaluate readability in a third.

Orchestrator-Workers

The orchestrator-workers pattern uses a central LLM to dynamically break down tasks, delegate subtasks to worker LLMs, and synthesize their results. This differs from parallelization because the subtasks aren't predefined. The orchestrator figures out what needs doing based on the input.

Multi-file code changes are a natural fit. The orchestrator reads the codebase, decides which files need changes, delegates each file's modifications to a worker, and merges the results.

Evaluator-Optimizer

The evaluator-optimizer pattern pairs a generator LLM with an evaluator LLM in a feedback loop. The generator produces output, the evaluator scores it against criteria and provides feedback, and the generator revises. This is Ng's reflection pattern expressed as a two-agent workflow, and it works best when you have clear, measurable evaluation criteria.

Give your agents a workspace that keeps up

generous storage, auto-indexed for semantic search, with an MCP server your agents can call directly. No credit card, no trial expiration.

Start 14-Day Trial

The foundational patterns describe individual capabilities. Production systems combine them into architectures that handle the messy realities of real workloads: state management, error recovery, cost control, and human oversight.

Human-in-the-Loop

Almost every production agent system includes explicit checkpoints where the agent pauses for human review. The pattern is simple in concept: insert approval gates at high-stakes decision points. The implementation challenge is designing the pause mechanism. The agent needs to serialize its state, present a clear summary of what it's about to do, wait for approval, and resume cleanly.

High-stakes decisions like financial transactions, data deletions, and external communications almost always need human gates. The temptation is to automate everything, but autonomous systems that ask for confirmation at appropriate points perform better in real deployments than those optimized to minimize human interaction.

Coordinator Pattern

The coordinator pattern sits between simple routing and full orchestrator-workers. A central agent analyzes incoming requests, decomposes them into subtasks, and dynamically routes each subtask to a specialized agent. Unlike orchestrator-workers, the coordinator maintains a persistent view of the overall task state and can re-route or retry if individual workers fail.

Customer service systems use this pattern extensively: the coordinator classifies the request, checks account status, decides whether to handle it directly or escalate, and assembles the final response from multiple specialist outputs.

Iterative Refinement

Iterative refinement extends the basic reflection loop with shared state that persists across cycles. Agents modify a stored document, codebase, or plan through multiple rounds until a quality threshold is met or an iteration maximum is reached. Each cycle has access to the full history of changes, not just the last output.

This pattern shines for complex generation tasks like long-form writing, multi-file code development, or strategic planning where quality improves measurably with each pass. The tradeoff is direct: each iteration compounds latency and cost.

Persistent State and Storage

Every pattern above assumes the agent can read and write state somewhere. In development, that's usually local files or in-memory stores. In production, agents need persistent storage that survives restarts, supports concurrent access from multiple agents, and provides audit trails.

This is where workspace infrastructure becomes critical. An agent generating a report needs somewhere to store intermediate drafts. A multi-agent pipeline needs a shared location where one agent's output becomes another's input. A human reviewer needs to see what the agent produced before approving it.

Local filesystems work for single-agent prototypes. For multi-agent production systems, you need cloud storage with versioning, permissions, and search. S3 gives you durability but not structure. Google Drive gives you collaboration but not agent-native access. Fastio provides workspaces designed for this exact use case: agents and humans share the same workspace, files are auto-indexed for semantic search through Intelligence Mode, and the MCP server exposes 19 consolidated tools that any LLM can call. The free tier includes 50GB storage and included credits with no credit card required.

Pattern selection depends on three variables: task complexity, quality requirements, and acceptable latency.

Start with the simplest pattern that works. A single agent with good tools and a clear system prompt handles a surprising range of tasks. Only add complexity when you can demonstrate it improves outcomes. Anthropic's guidance is direct: "add complexity only when it demonstrably improves outcomes."

For structured, repeatable tasks, use prompt chaining or sequential multi-agent pipelines. Each step is predictable, testable in isolation, and easy to debug. Content generation pipelines (research, write, edit, publish) fit here naturally.

For tasks requiring dynamic decomposition, use the orchestrator-workers pattern. When you can't predict what subtasks are needed until you see the input, let the orchestrator figure it out. Multi-file code changes, research tasks spanning multiple sources, and complex customer requests all benefit from dynamic decomposition.

For quality-critical outputs, add reflection or evaluator-optimizer loops. The cost of an extra LLM call is trivial compared to the cost of publishing incorrect code or sending wrong information to a customer. Set explicit iteration limits (three rounds is a reasonable default) and define measurable exit criteria.

For high-stakes decisions, add human-in-the-loop gates. Financial transactions, data modifications, external communications, and anything with legal implications should have explicit approval checkpoints.

For latency-sensitive workloads, use parallelization. Run independent subtasks simultaneously and aggregate results. This pattern reduces wall-clock time but increases total compute cost.

Pattern Combinations

Real systems rarely use a single pattern in isolation. A production content pipeline might use planning to decompose the task, tool use to gather research, parallelization to generate multiple sections simultaneously, reflection to improve each section, and human-in-the-loop for final approval. The key is making each pattern boundary explicit in your code. When you can point to exactly where routing happens, where reflection loops, and where human gates activate, your system becomes debuggable.

Context Window Management

Every agentic pattern accumulates context across steps. A 10-step plan with tool outputs at each step can easily exceed context limits. Three strategies help: summarize intermediate results before passing them forward, use separate context windows for independent subtasks, and store verbose outputs externally (in files or a workspace) while keeping only references in the conversation.

Error Handling and Recovery

Agents fail. Tools return errors, LLMs hallucinate, external APIs time out. Design for graceful degradation: retry with backoff for transient failures, fall back to simpler approaches when complex patterns fail, and always give the agent an explicit "I can't complete this" exit path rather than letting it loop indefinitely.

Cost Control

Reflection and iterative refinement patterns multiply your LLM costs by the number of iterations. Monitor token usage per pattern, set budget caps on iteration counts, and use cheaper models for routine steps (classification, simple extraction) while reserving expensive models for judgment-heavy steps (planning, critique).

Testing Agentic Systems

Traditional unit tests don't capture agent behavior. You need evaluation frameworks that test end-to-end task completion, not just individual function outputs. Build a test suite of representative tasks with known-good outputs and run your agent against them on every change. Track pass rates over time to catch regressions.

Workspace Architecture for Multi-Agent Systems

Multi-agent systems need shared infrastructure. At minimum, you need a file store where agents can read and write, a way to track which agent produced which output, and access controls that prevent one agent from overwriting another's work.

Fastio workspaces handle this natively. Each workspace supports file versioning, so you can track how documents evolve across agent iterations. Granular permissions (org, workspace, folder, file level) prevent accidental overwrites. The built-in audit trail logs every action, and Intelligence Mode auto-indexes files for semantic search, so agents can query workspace contents by meaning rather than filename. When the agent pipeline finishes, ownership transfer lets you hand the completed workspace to a human client while retaining admin access.