AI agent architecture patterns help you decide who chooses the next step, which work can happen together, and what happens when a tool returns something unexpected. I find those questions more useful than starting with a framework or a diagram full of agents.

A client asking for a renewal brief might need a simple document pipeline. A client asking why an account is at risk might need an investigation that changes direction as evidence arrives.

I compared the pattern guidance and implementation examples below to build a practical reference for that choice. The renewal scenarios, limits, and failure tests are proposed designs, not results from a customer deployment.

How to choose AI agent architecture patterns

Start by writing the deliverable and identifying what you do not know when a request arrives. Is the uncertainty the request category, the evidence needed, the next action, or the quality of a draft?

Then try a baseline: one model call with the necessary context and a clear output format. Add a pattern when you can explain the particular failure it should fix.

Anthropic distinguishes predefined workflows from agents that direct their own tool use. Its article also warns that its original tooling discussion has aged; I use the architectural distinction here, rather than its old framework examples.

This guide treats seven patterns as useful choices, not a universal taxonomy. Some describe coordination, others describe an individual agent's loop, and they can be combined.

If you need the components around these shapes, read our AI agent tech stack guide. Here the question is how the work moves between those components.

Seven AI agent architecture patterns at a glance

Use the uncertainty column to find your starting point. The final column is the first failure I would deliberately introduce before handing the system to a client.

Routing selects a known path. Orchestration creates a task list. Parallelization describes work running together, while a tool loop describes decisions changing after observations.

Google's architecture guide similarly asks builders to consider task structure, response time, cost, and human involvement before selecting a design.

1. Prompt chaining: make the dependencies explicit

Choose a chain when you know the stages and later work needs earlier output. For the renewal brief, extract the renewal date and account facts, validate the fields, then draft the narrative.

The intermediate result should be a small artifact with named fields. I would pass the account ID, source references, renewal date, missing fields, and verified facts, rather than asking the writer to interpret a previous agent's entire conversation.

Put the validation between extraction and drafting. A missing renewal date should produce a request for information or an explicitly incomplete brief, rather than a confident date inferred from an old email.

Microsoft describes sequential orchestration as a predefined order where each stage processes the previous stage's output. That dependency is the reason to use the pattern.

My implementation contract would distinguish an empty field from an unavailable source. Both can block a conclusion, but the recovery differs: one needs clarification, while the other might need a retried connection.

Failure test: remove the contract's renewal date. Pass only if the draft preserves the gap and the workflow avoids generating a customer-facing commitment from it.

Skip this pattern when one call already extracts and summarizes accurately enough for your acceptance criteria. Splitting a job into stages introduces handoffs that need their own checks.

Our multi-step AI workflow guide goes deeper on chains and conditional branches. The architectural choice here is whether the dependency earns a separate stage.

2. Routing: choose among paths you already understand

A router decides where a request belongs. A billing question can go to a billing specialist, while a product-usage question goes to a specialist with different knowledge and tools.

I would define the allowed route names before writing the classifier prompt. For example, the proposed renewal service could return billing, product, mixed, or needs_clarification.

The mixed path matters. “Our invoice doubled, and half the team cannot log in” contains two jobs; forcing it into one category can leave a real issue unanswered.

Do not treat a model's stated confidence as a calibrated probability. Evaluate route choices against labeled examples, and make the fallback useful even when the classifier sounds certain.

LangGraph's workflow guide demonstrates structured routing to context-specific tasks. A narrow set of outputs also gives your application something concrete to validate.

Failure test: submit the mixed billing-and-access request. Pass if the system covers both issues or asks the clarification your service contract requires, without silently dropping one.

Task routing is separate from model routing. One chooses the job; the other chooses the model that handles it, which we cover in our model routing guide.

I would add specialist paths because they need different permissions or evidence. Different wording alone rarely justifies a separate agent to maintain.

3. Parallelization: separate work that can proceed independently

Use parallelization when each branch can do useful work without waiting for another branch. A policy review and a usage review can inspect the same frozen account snapshot independently.

The policy branch might identify contractual conditions. The usage branch might describe adoption changes, with each returning evidence and qualifications for a final merger.

The important boundary is shared state. If both branches update the same CRM record, you have introduced a coordination problem beyond running two analyses at once.

I would keep these branches read-only and give one later step ownership of any approved write. That makes the relationship between the brief and its source snapshot easier to reconstruct.

Define the join rule explicitly: wait for all required evidence, return an incomplete result when an optional branch fails, or stop the request. Letting whichever branch finishes first stand in for the whole result changes the product promise.

Daniel Carpintero's workflow examples on Hugging Face cover independent parallel tasks and combining their outputs. They are implementation guidance, not evidence that more branches improve every workload.

Failure test: make the usage source time out. Pass if the final brief names the missing analysis and avoids inventing usage evidence or quietly presenting a complete review.

Running several judgments on the same input is another form of parallel work. Agreement is useful evidence to inspect, but shared context or the same model can produce shared mistakes.

4. ReAct-style tool loops: let observations change the next action

Choose a tool loop when the next useful lookup depends on the last result. An account discrepancy might lead from an invoice to a subscription change, then to the account's approved plan.

The original ReAct paper studies interleaving reasoning and actions so observations can inform later decisions. I use “ReAct-style” for this operational shape, without implying that every tool-calling product implements the paper's exact prompting method.

For the renewal example, the loop can investigate why the invoice and account snapshot disagree. It should have permission to read the relevant records, while refunds and subscription changes remain separate operations.

Give the runtime a list of allowed tools, validated arguments, a time budget, and a stopping rule. “Keep going until confident” is not a useful operational limit.

For a proposed pilot, I might allow up to six read-only tool calls before returning the evidence found and the unresolved question. That number is an illustrative starting limit to test, not an industry standard.

Failure test: return no matching invoice. Pass if the agent reports the empty result, tries only permitted recovery steps, and stops within the configured budget.

The audit trail should record tool names, permitted arguments, results, and outcomes. You do not need to expose or store private chain-of-thought to know which account was queried.

A fluent answer saying “I checked your account” is insufficient. Inspect whether the lookup actually ran and whether its result supports the answer.

5. Orchestrator-workers: discover the subtasks at runtime

An orchestrator creates and delegates work based on the request. The renewal brief might reveal an acquisition, a region-specific contract amendment, or an unusual product rollout that changes what needs investigation.

That differs from a parallel workflow whose policy and usage checks were fixed in advance. The orchestrator must decide which additional investigations matter and what each worker should return.

I would give each worker a short task, the permitted sources, the relevant account boundary, and a result schema. Useful fields include findings, source references, unresolved questions, and whether the task was completed.

The coordinator should own the final synthesis. If two workers disagree about the renewal date, it should preserve the conflict until authoritative evidence resolves it.

Anthropic's account of its research system describes a lead agent coordinating specialized investigations. Its reported outcomes belong to that system and workload; they are not a promised benefit for this proposed renewal service.

Failure test: have one worker supply a claim with a nonexistent source reference. Pass if the coordinator rejects or marks it unverified instead of laundering it into the brief.

Cap the number of workers, the work assigned to each, and the coordinator's ability to create more work. A delegation layer without limits can hide repeated research behind an organized-looking diagram.

Our multi-agent systems explainer covers broader team structures. I would choose this particular structure only when deciding the subtasks is itself valuable work.

6. Evaluator-optimizer: revise against evidence and a rubric

Use this loop when you can name what a better artifact looks like. For a renewal brief, the rubric might require a supported renewal date, a source for every account-specific claim, and an explicit list of unresolved issues.

The evaluator returns actionable failures. “The recommendation cites usage growth, but the source contains no usage series” tells the generator what to repair; “make it stronger” does not.

Self-Refine explores iterative generation, feedback, and revision using the same model. Its experiments support investigating the technique, not assuming a model's self-critique verifies business facts.

I would combine deterministic checks for required fields and valid source IDs with a rubric for clarity and relevance. A separate model call can help assess the latter, but it cannot replace the underlying source.

Preserve the previous draft and the feedback that caused each change. Otherwise a revision can remove a useful qualification while improving the evaluator's preferred style.

Failure test: include a polished sentence claiming a signed renewal when the contract is unsigned. Pass if the system detects the unsupported claim, even when the prose otherwise satisfies the rubric.

Use a revision cap and a fallback. In an illustrative pilot, two revision attempts might be enough to expose whether feedback helps before you spend more on the loop.

If the remaining problem is unavailable evidence, return the gap. Rephrasing the same unsupported conclusion is not progress toward a reliable brief.

7. Plan-and-execute: separate the plan from carrying it out

Choose plan-and-execute when a variable objective benefits from an inspectable sequence. Preparing a renewal review package could require collecting records, resolving gaps, producing a brief, and assembling supporting documents.

A planner proposes the steps. An executor performs the permitted work, and a replanner updates the remaining steps when a result changes the situation.

LangGraph's archived plan-and-execute notebook illustrates this distinction. I cite the versioned example for its architecture, not as current installation instructions.

Compared with a ReAct-style loop choosing its next action after each observation, this pattern maintains a separate plan. A step's executor can itself use a bounded tool loop.

I would attach stable step IDs and completion evidence to the plan. Replanning should update remaining work while preserving what already happened.

Failure test: restart planning after the review package has been saved. Pass if the system recognizes the completed save and avoids creating another package or repeating an approved external action.

For our proposed service, scope approval happens before execution, and approval of a customer message happens again before sending. A plan describes intended work; it does not create permission to perform it.

Skip the planning layer for a short, predictable brief. A maintained plan earns its cost when dependencies and recovery need to be visible.

Compose patterns around one client deliverable

I would begin the renewal service with a router, a small evidence-gathering workflow, and a draft. Most requests should not need every pattern in this article.

The router distinguishes a routine renewal summary from a discrepancy investigation. The routine path uses a chain; the investigation path adds a bounded read-only tool loop.

If policy and usage can be checked independently, those checks can run together. Their merger then passes verified facts to the writer, followed by a check against the agreed rubric.

An orchestrator becomes useful only if the required investigations vary enough to justify runtime task creation. A separate planner becomes useful when the broader review package has dependencies that need tracking.

The customer-facing promise stays constant: a draft brief with evidence and unresolved questions. The internal route can vary without silently changing what counts as a completed job.

When comparing two designs, keep the inputs and acceptance criteria fixed. Otherwise a more elaborate architecture can look better simply because it attempted an easier version of the task.

Write the handoff contract before connecting agents

A handoff should transfer enough evidence to continue the job without transferring every unrelated fact the previous step saw. This is where I would spend the implementation effort first.

• Identity: authenticated user, tenant, account, and run ID.
• Task: the requested deliverable and permitted scope.
• Evidence: source IDs, timestamps, retrieved facts, and qualifications.
• State: completed steps, remaining work, and missing inputs.
• Authority: permitted reads, proposed writes, and approval status.
• Budget: remaining calls, deadline, and the required fallback.

Keep tenant identity attached to every lookup, rather than relying on a specialist to remember it from a prompt. The retrieval service and action endpoint should enforce the boundary.

For writes, use an operation ID that remains stable across retries and verify the destination's resulting state. A timeout after a successful save must not automatically become permission to save again.

These are implementation recommendations for the proposed service. A framework's ability to connect nodes does not establish that your tenant checks, retry behavior, or approval handling are correct.

Use a failure test for every architectural decision

I would collect a small set of sanitized or synthetic renewal requests and label what should happen. Include normal jobs, missing evidence, ambiguous categories, unavailable tools, and attempts to cross account boundaries.

Then change one architectural choice at a time. Compare a single call with a chain, or a fixed evidence workflow with an orchestrator, using the same requests.

Record the artifact and the outcome separately. A response that reads well can still cite the wrong account or describe an action that never completed.

Our AI agent evals guide explains how to preserve enough starting context to replay a case and how to separate deterministic checks from model and human judgments.

For this pilot, I would require all account-boundary and unauthorized-write cases to pass before expanding access. Quality thresholds for tone or completeness can be agreed separately with the client.

Keep failed cases visible when you revise prompts. Removing a difficult input changes the evaluation set and hides the question you were trying to answer.

Count the work, then measure cost and latency

Pattern names are poor cost estimates. Count model calls, retrieved context, tool operations, coordination, revisions, and recovery attempts along the paths your requests actually take.

In hypothetical arithmetic, a three-call chain repeated for 100 requests uses 300 model calls. Adding one evaluator call to every request raises that to 400 before any revisions.

Those are call counts, not a price quote: different calls can have different token sizes, model rates, caching behavior, and tool charges. Measure the actual billable units for your implementation.

Likewise, two independent hypothetical checks taking four and six seconds would take roughly six seconds plus overhead when run concurrently, rather than ten seconds sequentially. Shared rate limits, retries, and the final merge can change that result.

I would compare accepted briefs per unit of cost and the slowest user-visible cases, alongside ordinary response time. A low average can hide a route that repeatedly exhausts its budget.

Include the human work left behind: reviewing unresolved questions, repairing failed integrations, and checking a source conflict. Saving model calls while increasing that workload can make the service harder to operate.

Build the client-facing starting point in Pickaxe

For a consultant selling this as a client service, I would start with Pickaxe for the agent, connected knowledge, and branded delivery. The first version can be a useful renewal assistant before it becomes a large orchestration project.

The current Agent Builder documentation puts the model, System prompt, Knowledge Base, and Actions in Build, with Settings for additional controls and Preview for testing.

I would begin with approved account guidance in the Knowledge Base and a narrowly described task. Keep the distinction between shared reference material and account-specific live records clear.

Pickaxe Actions can connect tools, other agents, and external workflows. The same documentation recommends a focused set of Actions and a waterfall setup when a primary agent needs to route to specialists.

That gives this proposed service a concrete starting shape: a primary assistant and a billing or product specialist when the separation is useful. I would describe the trigger in both the System prompt and the Action's trigger prompt.

For integrations that support an account choice, the Actions guide distinguishes the owner's connected account from each end user's account. Select that deliberately and test which records the deployed user can actually reach.

I would deliver the assistant through a branded Pickaxe Portal when clients need agents and supporting pages together. Access configuration is part of the product, not something the architecture diagram can stand in for.

For strict joins, persistent checkpoints, enforced iteration budgets, or a multi-stage approval process, verify the chosen runtime or connected workflow explicitly. Connecting specialist Actions does not by itself prove those particular execution guarantees.

Decide what would justify the next pattern

Before adding another layer, write the result that would make it worthwhile. “Mixed requests stop losing an issue” is a useful routing goal; “the design becomes multi-agent” is not a customer outcome.

I would record the current design, its failing cases, the proposed change, and the new work it introduces. That creates a decision you can revisit after the first deployment.

A chain earns its place when intermediate validation catches important omissions. An orchestrator earns its place when discovering tasks improves accepted results enough to justify coordination and debugging.

If the simpler version meets the agreed contract, ship it and keep the evidence. You can add a new shape when the workload changes, with a clear reason and a test that demonstrates the difference.

Frequently asked questions about AI agent architecture patterns

Is RAG an agent architecture pattern?

Retrieval-augmented generation describes bringing retrieved evidence into generation. It can support a single call, a chain, a specialist worker, or a tool loop; it does not decide the whole system's control flow.

Does every pattern require multiple agents?

No. One agent can use a tool loop, while a chain can be a sequence of model calls with ordinary validation code between them. Count separate agents only when they have a distinct role or execution context.

What is the difference between an orchestrator and a router?

A router selects from known destinations. An orchestrator determines the subtasks needed for a request, assigns work, and combines the results; the same application can use both.

Where does human approval fit?

It can sit at any consequential boundary, including a plan change or an external write. Bind approval to the actual artifact and action being proposed, so a changed draft cannot silently reuse an earlier approval.

Should I use an evaluator for every answer?

I would add one when there is a clear rubric and evidence that revision helps. Start with deterministic checks for simple requirements, and compare the additional evaluator work against the failures it catches.

Which pattern should a beginner use first?

Try one call with appropriate context first. If that fails in a repeatable way, a short chain or a router is usually a manageable next experiment because its boundaries can be inspected directly.

Start with the uncertainty you can name

I would take one client request, write down the promised deliverable, and mark the first point where the current design cannot make a reliable decision. Choose the smallest pattern that addresses that point.

Keep the evidence, fallback, and action permissions visible as you build. That gives you something more useful than an impressive architecture: a service whose behavior you can explain, test, and improve.