Agentic Design Patterns: Types, Examples

An AI agent's reliability depends on how its work is organized: which decisions it makes, what evidence it receives, and what happens when an action fails. Adding another agent or a critique step changes those conditions, but it also adds coordination, latency, and new failure paths.

This guide explains six agentic design patterns, their operating mechanisms, and the situations that justify each one. It also covers the shared building blocks and practical checks needed to combine them into a system you can evaluate and operate.

What are agentic design patterns?

Agentic design patterns are reusable ways to organize model decisions, tool execution, feedback, and state around a task. They describe how an application carries work forward across multiple steps, including how it revises a failed attempt or hands a decision to a person.

An important distinction is who chooses the next step. In a workflow, application code defines the sequence or branches. In an agent, the model selects actions as the task develops. Anthropic's architectural guide distinguishes these approaches while treating both as forms of agentic systems.

The patterns here operate at different levels. Single-agent and multi-agent designs organize decision-making. Parallel execution organizes scheduling. Reflection adds feedback, human review adds a decision boundary, and memory supplies retained context. They can overlap: a single agent might retrieve past investigations, revise a query after validation fails, and request approval before changing a service configuration.

Treat each pattern as an answer to a specific engineering problem. Its value comes from changing a measurable outcome, such as task completion or recovery from errors.

How agentic design patterns work

An agent typically receives a goal, chooses an action, observes the result, and decides whether to continue. The ReAct paper demonstrated an approach that interleaves reasoning and actions so information from an external environment can inform subsequent steps.

Consider a hypothetical support investigation: identify why a customer's scheduled export failed. The agent retrieves the job record, finds an authentication error, and checks the credential status. An expired credential calls for a different follow-up than a service outage. The next action depends on the observation.

Application code surrounds this loop. It validates tool arguments, checks permissions, executes permitted requests, and records results. It should distinguish an empty result from an unavailable service. Otherwise, an agent may interpret a failed lookup as evidence that no matching record exists.

Completion also needs an explicit contract. For this investigation, require an identified job, supporting evidence, and either a proposed remedy or a clear escalation reason. Set a deadline and a tool-call budget so incomplete work terminates visibly.

The core building blocks of agentic systems

Five components provide a useful implementation checklist, regardless of the pattern selected.

Task and decision policy. Define the goal, permitted scope, and evidence required for completion. Give the model instructions for choosing tools and recognizing when information is insufficient. Keep enforceable limits in application code, where a generated response cannot waive them.

Tool interfaces. Expose operations with clear inputs, outputs, and failure states. For an export investigation, separate reading job history from rotating a credential. Return stable identifiers and timestamps so later calls refer to the same objects. An ambiguous tool description makes correct selection harder to evaluate.

State and persistence. Record completed steps, pending actions, tool results, and approval decisions outside the model's transient context. Define what a restarted run should resume. A saved conversation alone may omit the execution status needed to determine whether an external action already happened.

Knowledge access. Provide retrieval tools for documents and operational records. Keep source identity, access scope, and observation time attached to evidence. The agent needs to distinguish a historical incident note from a current status lookup, even when both mention the same service.

Validation and observability. Check outputs against task-specific criteria and capture the execution trace: tool arguments, results, errors, retries, and final status. Evaluate both the answer and the actions taken to produce it. A correct diagnosis reached through an unauthorized lookup still fails the system's requirements.

Together, these components make an agent run inspectable. They also let you change its orchestration without losing control over the underlying operations.

Single-agent design pattern

A single-agent design gives one agent responsibility for selecting tools and carrying a task to completion. It may make many model calls, but one decision loop maintains ownership of the investigation.

For the failed export example, that agent can inspect job history, check credentials, consult the runbook, and draft a response. The task stays within a coherent context, and each new observation informs the same ongoing investigation.

Use this pattern when one role can handle the work with a manageable tool set. Start with narrow tool descriptions and clear boundaries between similar operations. If the agent repeatedly selects the wrong lookup, first test whether better naming or more specific arguments fix the problem.

The main design pressure is accumulated context. Long investigations can bury important evidence among irrelevant results. Preserve a compact record of established facts, unresolved questions, and source references. Retrieve detailed artifacts when needed instead of repeatedly passing every log line.

Evaluate the baseline on realistic cases, including missing records and tool failures. A single agent provides a useful reference for later changes: a more elaborate design should demonstrate an improvement large enough to justify its additional execution paths.

Reflection and self-correction pattern

Reflection adds a review step between an initial attempt and acceptance. The system produces an artifact, evaluates it, and feeds actionable criticism into a bounded revision loop. Evaluation can use code, a model, human feedback, or a combination.

For example, an agent generating a query can receive a schema-validation error naming an unknown field. It can inspect the available fields, revise the query, and try again. A successful execution then requires a separate check that the query actually answers the user's question.

The Reflexion paper illustrates a related approach: agents retain textual reflections on feedback for later attempts without updating model weights. Such retained feedback connects reflection with memory.

The quality of the feedback matters. Huang and colleagues' study of intrinsic self-correction found that the models tested struggled to correct reasoning without external feedback and sometimes degraded their answers. This is evidence against assuming that another review pass necessarily improves correctness, rather than a universal conclusion about every model or task.

Use reflection when you can identify a useful evaluation signal: a failing test, an invalid reference, or a missing source. Preserve the best validated candidate, limit revisions, and escalate repeated failures. Measure whether revisions fix defects and whether they introduce new ones.

Parallel agent pattern

Parallel execution assigns independent work to concurrent branches and combines their outputs. Anthropic's parallelization pattern includes both splitting a task into separate subtasks and running multiple attempts at the same task.

In the export investigation, separate branches could inspect recent job failures, service health, and relevant configuration changes. Give each branch the same customer identifier and investigation window, then require findings with evidence references. A coordinator can compare the results once the branches finish.

This pattern fits work that does not require one branch's answer before another can start. If credential inspection requires an identifier available only from the job lookup, perform that lookup first. Launching both together would hide a dependency inside retries or guesswork.

Parallel execution can reduce elapsed time for independent tasks, while increasing simultaneous resource demand. Set concurrency limits and define whether the final answer requires every branch. A timed-out service-health check should appear as missing evidence in the combined result.

Aggregation needs its own rules. Preserve contradictions and distinguish agreement from independent corroboration: several agents repeating the same source still provide one source. Prefer parallel read operations initially; concurrent writes need explicit ownership and conflict handling. The useful unit of parallel work is a bounded task with a result that can be checked independently.

Human-in-the-loop pattern

Human-in-the-loop systems pause at selected decisions so a person can approve, reject, clarify, or revise the proposed next step. This is useful where authority, business context, or an ambiguous requirement determines the correct action.

An agent might diagnose the export failure and prepare a credential-rotation request. The reviewer should see the affected integration, evidence, expected disruption, and exact proposed change. Approval should bind to that proposal; a later change to its target or scope requires another decision.

LangGraph's interrupt mechanism provides a concrete implementation: persist execution state, pause for external input, and resume with the response. Its documentation also warns that resumed nodes restart, so side effects before an interrupt must be idempotent, meaning repetition does not produce an additional effect.

Design the pause as an operational state. Assign a reviewer, define expiry, and explain what happens if nobody responds. On resumption, recheck conditions that could have changed, such as whether the credential has already been replaced.

Place review where a person has enough evidence to decide, before the consequential action executes. Avoid asking them to reconstruct the investigation from a transcript. Track review time and rejection reasons to learn whether the agent is producing useful proposals or transferring unfinished analysis to its reviewers.

Multi-agent collaboration pattern

Multi-agent collaboration distributes work across agents that exchange results, delegate follow-up tasks, or transfer responsibility. Unlike a simple parallel split, the work can evolve in response to another agent's findings. Collaboration may be sequential, concurrent, or both.

For example, an investigation coordinator could assign a job-history analysis, then ask a configuration specialist to examine the specific integration implicated by that result. If the specialist finds a recent policy change, the coordinator may request a new comparison against earlier successful runs.

Anthropic's multi-agent research system describes a lead agent coordinating subagents and synthesizing their findings. Its account also discusses the coordination and resource costs of this approach, making it useful evidence for the trade-off rather than a reason to adopt it everywhere.

Use collaboration when the task benefits from separate contexts, specialized tools, or dynamically discovered subtasks. Give each assignment an objective, inputs, permitted tools, expected output, and stopping condition. A role label such as researcher or critic does not establish those contracts.

Choose an owner for the final decision and shared artifacts. Require handoffs to include evidence, uncertainty, and unresolved questions. Bound delegation depth and repeated exchanges so agents cannot keep referring the same problem to one another. Evaluate the complete result as well as individual worker outputs: accurate local findings can still be assembled into an unsupported conclusion.

Memory-augmented agent pattern

Memory-augmented agents retrieve retained information to inform later decisions. LangChain's memory documentation distinguishes short-term state associated with a conversation thread from long-term information available across sessions.

For a support agent, current investigation state might include completed checks and pending questions. Longer-lived memory could include a customer's confirmed notification preference or a previously resolved incident. Retrieving either does not itself update the model's weights.

Choose storage and retrieval around the question. Key-based lookups suit explicit preferences. Semantic search can locate similar incident descriptions. Relationship queries suit questions about which jobs use a credential, which services those jobs feed, and who owns the affected integrations.

Write memory selectively. Record its source, subject, timestamp, and retention policy, and separate verified facts from agent hypotheses. Revalidate changeable facts before using them to justify an action. A previous incident's explanation is a lead to investigate, not evidence that today's failure has the same cause.

Operational knowledge also needs a clear relationship to retained agent notes. For dependency questions, PuppyGraph lets teams define a graph schema over existing data, giving agents a model of entities, relationships, and properties. Its default direct-query path reads supported SQL databases, warehouses, and lakehouses without requiring a persistent duplicate dataset. The agent can query defined relationships while workflow state and learned preferences remain in their appropriate stores.

PuppyGraph's ontology enforcement validates queries against that model before execution and returns structured, LLM-readable feedback for invalid references. An agent can use this feedback to correct its query. This grounds query construction; source accuracy and action authorization still require their own checks. It gives a memory-augmented system a defined path to relationship context alongside its retained notes and documents.

How to choose the right agentic design pattern

Start with the failure or constraint you need to address. Use a fixed workflow when the steps are known and a single agent when investigation requires adaptive tool selection. Add other patterns against observed needs.

These patterns can be layered around one task. An export-support agent might begin alone, add schema feedback for query repair, retrieve past incidents, and pause before a credential change. Add parallel branches only when independent checks dominate elapsed time; add collaborators when separate contexts improve the investigation.

Build an evaluation set before expanding the architecture. Include successful cases, unavailable dependencies, contradictory evidence, stale memory, and resumed runs. Measure completion against explicit criteria, total execution cost, latency, unauthorized-action attempts, and the frequency of human intervention. Compare changes under the same task conditions and resource budget.

Keep failure handling explicit. A tool timeout may justify a retry; a permission denial requires a different response. For writes, use operation identifiers and check execution status before repeating a request whose outcome is unknown. These controls apply across patterns and often matter more than adding another model call.

Conclusion

Agentic design patterns organize decisions, evidence, and responsibility. Choose them according to the work: one loop for a coherent task, feedback for repairable errors, concurrency for independent checks, collaboration for evolving assignments, human review for consequential decisions, and memory for useful retained context. Validate each addition against realistic failures as well as successful runs.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries connect entities across warehouse and lakehouse tables, with no graph-specific ETL, to give agents relationship context for multi-step investigations.