Choosing an Agentic Design Pattern

An agent design pattern is a common architectural approach for building agentic applications — a framework for organizing a system’s components, integrating the model, and orchestrating one or several agents to accomplish a workflow.¹ Picking one is a fundamental architectural decision, and each pattern trades flexibility against complexity and performance differently. This page is the map; the individual pattern pages linked below are the territory.

Diagram

Open the interactive version here to pan and zoom.

First: do you need an agent at all?

Agents earn their cost on open-ended problems that need autonomous decision-making and multi-step workflow management — solving problems in real time against external data, automating knowledge-intensive tasks, and completing goal-focused tasks with some degree of autonomy.

If your workload is predictable or highly structured, or if it can be executed with a single call to a model, a non-agentic solution is usually more cost effective. Anthropic’s guidance lands in the same place from a different catalog — see Agents vs. Workflows, which sets out the underlying distinction this page’s two multi-agent families are an application of. Summarizing a document, translating text, and classifying customer feedback are the source’s own examples of tasks that don’t need an agentic workflow at all.

Four requirement dimensions

The source frames pattern selection around four questions. They aren’t an exhaustive planning checklist — they’re the starting point for identifying the primary goal of the system.

• Task characteristics — can the task be completed in predefined workflow steps, or is it open-ended? Does it need an AI model to orchestrate the workflow at all?
• Latency and performance — do you prioritize fast, interactive responses at the cost of accuracy? Or can the application tolerate delay to get a more accurate, thorough result?
• Cost — what’s the budget for inference? Can you afford patterns that make multiple model calls per request?
• Human involvement — does the task involve high-stakes decisions, safety-critical operations, or subjective approvals that need human judgment?

The third question is the one that separates the two families of multi-agent pattern: whether orchestration runs on predefined code or on a model’s reasoning. See Multi-Agent Systems.

The design process

1. Define your requirements — assess task complexity, latency and performance expectations, cost budget, and the need for human involvement.
2. Review the common patterns — both single-agent and multi-agent.
3. Select a pattern based on those workload characteristics.

This isn’t a one-time decision. Revisit it as workload characteristics change, requirements evolve, or new platform features become available.

Pattern selection by workload shape

Deterministic workflows

Predictable, sequential tasks with a clearly defined path from start to finish. The steps are known in advance and the process doesn’t change much between runs.

• Sequential — multi-step tasks on a predefined, rigid workflow; no model orchestration; fixed sequence where each agent’s output is the next agent’s input.
• Parallel — independent tasks that can run at the same time; no model orchestration; reduces overall latency by running sub-tasks simultaneously.
• Iterative refinement — open-ended or complex generation that’s hard to complete in one attempt; progressively improves output over cycles; no model orchestration; prioritizes quality over latency.

Workflows that require dynamic orchestration

Complex problems where agents must decide how to proceed — the system plans, delegates, and coordinates without a script.

• Single agent — structured, multi-step tasks that need external tools; fast development of a proof-of-concept prototype.
• Coordinator — dynamic routing to the right specialized subagent for structured tasks with varied input; high latency and cost from repeated calls to the coordinator model.
• Hierarchical task decomposition — multi-level model orchestration for complex, open-ended, ambiguous tasks where decomposing the ambiguity is the primary challenge; high latency from nested decomposition.
• Swarm — collaborative debate and iterative refinement across specialized agents; prioritizes synthesizing multiple perspectives; high latency and cost from all-to-all communication.

Workflows that involve iteration

The final output is reached through cycles of refinement, feedback, and improvement.

• ReAct — the agent iteratively reasons, acts, and observes to build or adapt a plan for complex, open-ended, dynamic tasks; prioritizes a thorough result over latency.
• Loop — monitoring or polling tasks that repeat a predefined action until an exit condition is met; unpredictable or long-running latency while waiting.
• Review and critique — tasks that require a distinct validation step before completion.
• Iterative refinement — listed here as well as under deterministic workflows, since the loop is code-driven but the work inside it is open-ended generation.

Workflows with special requirements

Tasks that don’t follow the common patterns — unique business logic, or human judgment at critical points. The system ends up custom-built for a single, specific purpose.

• Human-in-the-loop — human supervision for high-stakes or subjective tasks with safety, reliability, or compliance requirements.
• Custom logic — complex branching that goes beyond a linear sequence; maximum control to mix predefined rules with model reasoning; fine-grained process control for a workflow that fits no standard template.

Footnotes

1. Samantha He, “Choose a design pattern for your agentic AI system”, Google Cloud Architecture Center, last reviewed 2026-05-28. Local copy: references/google-cloud-agentic-design-patterns.md. ↩