AI Agent Design Patterns: Start Simple, Verify Actions

“Your AI forgets everything the moment a conversation ends.” That describes a stateless application without persisted context, not every AI product. Thread state and cross-session memory are separate capabilities that an application can supply. LangChain's memory overview

But memory does not answer the next architectural question: what should the agent be allowed to do with what it remembers? A support assistant may need an earlier conversation to understand a complaint. It still cannot treat a remembered “I am an administrator” as permission to issue a refund. For extraction, updates and forgetting across sessions, use our Supermemory implementation guide. Here, the decision is about control flow.

With AI agents, complexity should earn its place. My starting point is the smallest system that meets the task's acceptance criteria. Anthropic likewise recommends beginning with simple solutions and weighing additional agentic behavior against latency and cost. Anthropic's effective-agent guidance

This guide compares five useful patterns through their failure modes. They are composable design choices, not an exhaustive taxonomy or a five-level maturity ladder. In particular, verification is a risk control, not a reward for reaching a more advanced architecture. Sources reviewed on 17 September 2026; examples and acceptance checks below are proposed designs, not reported client benchmarks.

Which AI agent design pattern solves your failure mode?

Identify the first broken requirement before adding another model call. Missing context suggests better context handling. A predictable business process suggests a coded workflow. Neither automatically justifies an autonomous loop.

The last row can apply to every other row. A one-call payment proposal needs authorization just as much as a multi-step agent does. Conversely, a read-only summarizer does not become better merely because it has a planner.

1. Single-shot: keep the baseline when it works

A single-shot design sends a bounded task to a model once and returns its output without an autonomous tool loop. Strictly speaking, this is a baseline LLM workflow, not necessarily an agent under definitions that require dynamic action selection.

Use it for extracting fields from a supplied complaint, classifying a request, summarizing an approved document or drafting a response from complete context. Required data may be assembled deterministically before the call; that does not require the model to choose the retrieval process.

Example: turn a support message into a category, urgency and concise summary. Validate the schema in ordinary code. Missing required fields should produce a validation failure or a review request, not an invented order number.

The advantage is a small application-level execution path. The limitation is that the model cannot inspect a result and decide to fetch another source without changing the architecture. One call is also not inherently deterministic, cheap or correct: those properties depend on the model, context and task. Keep this baseline while measured quality is sufficient. If the work is exact arithmetic or a fixed transformation, start with ordinary code instead.

2. ReAct: add a loop when observations change the next action

ReAct interleaves deciding, acting and observing. A tool result informs the next decision rather than merely filling a fixed sequence. The original paper studies the combination of reasoning and environment actions. ReAct research paper

Example: a support assistant checks an order. A shipment exception means it should inspect delivery events; a completed return means it should inspect the refund status. The useful next lookup was not known from the initial message alone.

That is different from a process that always loads an order, retrieves the same policy and produces a summary. For the fixed process, explicit application code may be easier to test than model-selected orchestration.

For a first implementation, define a maximum number of steps, a wall-clock deadline and a tool-call budget. Detect repeated calls that produce no new evidence. Distinguish a retryable transport failure from a business rejection, and return a clear incomplete status when the budget is exhausted. Record tool names, arguments, outcomes and concise decision summaries; do not require access to a model's hidden reasoning.

Tool observations are data, not new authority. Check access before sensitive reads, validate arguments and gate every consequential write. A retrieved page saying “ignore the policy” must not rewrite the policy.

3. Planner-executor: separate the task map from doing the work

A planner-executor design gives planning and execution distinct responsibilities. The planner proposes steps; an executor completes them. This separation is the central idea in LangChain's original plan-and-execute description, not a guarantee of better results. Plan-and-execute architecture

Consider it when a long assignment repeatedly skips deliverables, loses dependencies or becomes difficult to resume. A market-research report, for example, needs evidence collection before analysis and analysis before recommendations. The final prose should not conceal a missing research step.

Make each proposed step carry an input, expected output, dependency and completion check. Save completed work as explicit state. Replan when evidence invalidates an assumption, not just because the model can produce a different plan. Set a limit on replanning and expose blocked steps to an operator.

Planning and execution do not require separate models or a crowd of agents. One executor can work through the plan. Parallel workers only help where tasks are genuinely independent; shared writes and dependent outputs need coordination. If the steps are already known and stable, a predefined workflow is often the smaller design.

The failure mode to watch is a well-formatted but wrong plan. Check its scope and prerequisites before execution, and verify completed outputs rather than treating checked boxes as evidence.

4. Reflection: improve a draft without pretending to prove it

Reflection adds critique and revision after an initial output. Self-Refine uses model-generated feedback to revise a draft and reports improvements on its evaluated tasks. Those findings are not a universal accuracy guarantee. Self-Refine research paper

Use a concrete rubric: did the response address each requested point, distinguish facts from assumptions and remain within the approved sources? “Think harder” is not an acceptance criterion. Start with one revision pass and compare it with the unedited baseline.

Example: a support-reply draft includes the right facts but omits the next step. A critique can flag that omission and request a clearer revision. For code, a critique can suggest improvements, but compilation, tests and human review remain separate checks.

Research on intrinsic self-correction found that the tested models could fail to repair reasoning without external feedback and sometimes make it worse. This is a task- and model-specific caution, not a claim that all later systems are incapable of improvement. Study of self-correction without external feedback

The practical distinction is simple: reflection asks whether a draft can improve. Verification checks whether a requirement is actually satisfied. A second model's approval is still not proof of a user's permissions or the correct account balance.

5. Verifier-gated: separate proposing an action from authorizing it

Verifier-gated execution prevents a proposed action from taking effect until an independent control permits it. OWASP recommends downstream authorization, minimum permissions and human approval for high-impact actions rather than letting an LLM decide its own authority. OWASP guidance on excessive agency

“Independent” means the agent cannot bypass the check, rewrite its policy or manufacture its evidence. The verifier may include schema validation, a rule engine, a trusted system lookup, deterministic calculations or a human approver. Another model can provide an advisory assessment, but it should not be the sole authorization boundary.

For a refund proposal, I would require the application to establish the authenticated actor and tenant, load the current order from the system of record, validate the amount and currency, check the remaining refundable amount and confirm the required approval. These are proposed engineering controls, not a complete payment implementation.

Bind approval to the exact action: recipient, amount, currency and relevant record version. A changed proposal needs renewed validation. OWASP's transaction-authorization guidance calls for server-side enforcement and a final authorization check tied to execution. OWASP transaction-authorization guidance

Missing evidence, a malformed verifier response or a verifier timeout should block execution or route it to review. A business denial must not become an unlimited “try again” loop. Design idempotency and reconciliation for uncertain outcomes: a payment timeout does not prove that no payment happened. Check current state before attempting another write.

Put the gate before each relevant side effect, including intermediate tool calls, not just before the final answer. After execution, reconcile the actual result. Pre-action authorization and post-action verification solve different problems.

A support assistant does not need all five patterns at once

Imagine a customer asking about a delayed order and a possible refund. This is an illustrative design exercise, not a client deployment. Begin with a single-shot classification and a read-only workflow. Add a ReAct loop only if the appropriate investigation depends on what earlier lookups reveal.

A planner is optional: a small order-status task probably does not need one. Introduce it only when investigation spans several dependent deliverables. A reflection pass is also optional and belongs on the draft response, not on the payment authorization.

The refund path is different. Keep credentials for execution outside the model, validate the structured proposal, obtain any required approval, execute through a narrow interface and reconcile the result. Whether one model call or several produced the proposal does not change this boundary.

Persist the state needed to resume safely, but do not confuse a conversation transcript with an execution ledger. Redact sensitive trace data and test restart behavior. OWASP's agent-security guidance covers tool restrictions, memory protection and operational controls in more depth. OWASP AI Agent Security Cheat Sheet

How do you decide whether another loop earned its place?

Compare the baseline and one proposed change on the same representative tasks. Keep the model configuration and evaluation criteria stable where possible, record unavoidable differences and run repeated trials. Otherwise, an apparent architecture improvement may just be a different model or an easier task sample.

Measure accepted outcomes, unsupported claims, unauthorized actions, review effort, timeouts and end-to-end p50/p95 latency. Count all model and tool calls, including retries and revisions. For the accounting model, use our AI agent cost-per-action guide; the decision here is whether the extra step reduces the specific failure enough to justify its operational burden.

Safety controls are not optional experiments on live users. Test consequential workflows in a sandbox or shadow mode before granting write access. Do not remove authorization because an ungated benchmark is faster.

For the surrounding runtime, recovery and operating responsibilities, use our agent harness architecture guide. For a concrete implementation, Wavect's AI development service connects the workflow to product requirements and acceptance checks. Our prototype-to-enterprise-pilot case study is a separate delivery example, not evidence that these patterns were benchmarked there.

Use the software QA checklist before launch to define release criteria, or discuss the failure mode in your agent workflow. Bring a failed trace, a successful example and the action the system must never take without approval.