02 – AWS Agentic AI Patterns: From Reasoning to Multi-Agent

Agentic AI patterns are the reusable blueprints that turn a generic language model into a purposeful production system. Where Part 1 covered the why, this guide maps each pattern — reasoning, retrieval-augmented, orchestrator, multi-agent — to the AWS services that bring it to life.

Agentic AI Patterns: What You’ll Learn

You’ll recognize the core patterns, know when to choose each one, and see how LLM workflows and event-driven orchestration fit together on AWS.

Agentic AI Patterns: The Blueprint Library

Every production agent falls into one of a small number of archetypes. AWS calls these agentic AI patterns — reusable design templates that describe how an agent perceives, reasons, acts, and learns. The six patterns below each optimize for a different primary concern — accuracy, context, code quality, latency, throughput, or coordination — and map to specific AWS services that handle the heavy lifting.

In practice, few production systems rely on a single row of this table for their agentic AI patterns. A customer-support system might combine a reasoning agent for triage, a RAG agent for policy lookups, and an orchestrator to route between them.

Treat the table as a menu of building blocks rather than a single choice: pick the agentic AI pattern that matches the bottleneck you actually have — ambiguity, factual grounding, code correctness, voice latency, tool sprawl, or cross-team coordination — and add the next pattern only once the current one is the limiting factor.

Agentic AI Patterns: Reasoning Agents: How Agents Think and Plan

The reasoning agent is the most common agentic AI pattern in production. It interprets an ambiguous goal, breaks it into steps, decides which tool to call at each step, and adapts when a step fails. It typically uses a prompting strategy like ReAct (Reason + Act) or plan-and-solve, where the LLM first reasons about what to do and then emits an action.

On AWS, the canonical implementation is Amazon Bedrock Agents with the default ReAct orchestration. The agent receives a prompt, generates a rationale for its next step, invokes an action group (typically a Lambda function), observes the result, and loops until the goal is met.

This loop lets it recover from a failed API call by reasoning about the error and trying a different tool. Reasoning agents shine when the task is genuinely ambiguous — triaging support tickets, drafting analysis from unstructured documents, navigating multi-step workflows — and struggle when the task is deterministic, where a traditional function is cheaper and more reliable.

A simplified trace makes the loop concrete: the agent receives “find this customer’s last order and check if it shipped,” reasons that it needs a customer-lookup tool, calls the action group, observes a customer ID, reasons that it now needs an order-lookup tool, calls it, observes a tracking status, and only then composes the final answer.

Each of those reasoning-and-action steps is a separate call to the underlying model, which is why ReAct loops — the backbone of many agentic AI patterns — are flexible but not free: a five-step task can mean five or more model invocations before the agent responds.

Two failure modes show up repeatedly in production: the agent loops indefinitely because a tool keeps returning an error it does not know how to interpret, and the agent hallucinates a tool call that does not exist in its action group. Bounding the maximum number of reasoning steps and validating every tool response before feeding it back into the loop are the two cheapest guardrails against both.

Retrieval-Augmented Agents

The retrieval-augmented agent (often shortened to RAG agent) adds a knowledge base to the reasoning loop. Before responding, the agent queries a vector database for relevant context, then conditions its answer on what it retrieved. This grounds LLM output in your enterprise data and dramatically reduces hallucinations.

On AWS, the managed path is Amazon Bedrock Knowledge Bases. Point it at a data source (Amazon S3, a website, a Confluence space, a database) and Bedrock handles chunking, embedding, indexing, and retrieval — no custom retrieval code required. For more control, Amazon OpenSearch Service and pgvector on Amazon RDS offer fully customizable vector stores. RAG agents are essential whenever factual accuracy matters: customer support, internal Q&A, document analysis, clinical decision support.

Two design decisions dominate RAG quality in practice. The first is chunking strategy: chunks that are too large dilute the embedding with irrelevant context, while chunks that are too small lose the surrounding meaning a question needs.

The second is how many chunks to retrieve per query — a low top-k keeps the prompt cheap and focused but risks missing the right passage, while a high top-k improves recall at the cost of a longer, noisier context window. These two levers are the main tuning knobs for RAG-style agentic AI patterns.

Bedrock Knowledge Bases exposes both as configuration rather than code, so tuning them is an iteration loop, not a rebuild. It also helps to have the agent cite which retrieved chunk it used for each claim; that citation is what lets a reviewer trust — or catch — the answer instead of taking it on faith.

Orchestrator and Subagent Patterns

As agent scope grows, a single agent stuffed with every tool starts to degrade — reasoning quality drops, latency rises, debugging becomes a nightmare. The orchestrator-subagent pattern solves this: a supervisor agent receives the request, decides which specialist to delegate to, and aggregates the responses. Each subagent has a narrow focus, fewer tools, and a clearer prompt.

Amazon Bedrock’s multi-agent collaboration feature operationalizes this pattern. You define a supervisor agent and one or more collaborator agents, each with its own action groups and knowledge bases. The supervisor routes subtasks, collaborators do the work, and the supervisor stitches the final answer. This is one of the most powerful patterns for complex workloads like claims processing, multi-source research, or any task that benefits from separation of concerns.

A concrete example: a customer-support supervisor receives “why was I charged twice this month, and can I get a refund?” Rather than one agent trying to know everything about billing systems and refund policy, the supervisor recognizes two distinct subtasks and delegates the billing lookup to a billing subagent (with its own action group hitting the billing API) and the policy question to a refund-policy subagent (RAG over the refund knowledge base).

The supervisor then combines both answers into a single, coherent reply. The customer never sees the seam.

This orchestrator-subagent structure is one of the clearest examples of agentic AI patterns in customer support, and its benefit compounds as scope grows: adding a new capability means adding a new collaborator with a narrow prompt, not re-tuning one already-overloaded agent.

LLM Workflow Strategies: Chain-of-Thought, ReAct, Plan-and-Solve

Underneath every agentic AI pattern is an LLM workflow — the prompting strategy that turns model output into structured behavior. Three strategies dominate production deployments:

• Chain-of-thought — the model reasons step by step before answering. Best for math, logic, multi-step analysis. Available natively in modern Bedrock models.
• ReAct (Reason + Act) — the model alternates reasoning traces with tool calls, observing each result before the next step. The default for Amazon Bedrock Agents.
• Plan-and-solve — the model first emits a complete plan, then executes it step by step. Lower latency than ReAct for predictable workflows.

ReAct is most adaptive but most expensive (many LLM calls). Plan-and-solve is cheaper but brittle when the environment changes mid-task. Chain-of-thought is cheapest but cannot use tools. Mature patterns often combine them: plan-and-solve for the skeleton, ReAct for adaptive steps.

The choice matters most at scale when selecting among agentic AI patterns. A ticket-categorization task that runs thousands of times a day is a poor fit for ReAct — the category rarely depends on anything the agent needs to look up mid-reasoning, so chain-of-thought (or even a plain classifier) does the job at a fraction of the cost.

An open-ended research task, by contrast, cannot be planned up front because each retrieved document changes what to look up next; that unpredictability is exactly what ReAct is built for.

The practical rule of thumb: reach for chain-of-thought first, upgrade to plan-and-solve when the task has a knowable structure worth pre-computing, and reserve ReAct for tasks where the next step genuinely depends on what the previous tool call returned.

Event-Driven Agentic Workflows

Not every agent invocation comes from a user typing a prompt. Many production patterns are event-driven: a file lands in Amazon S3, a ticket is created in ServiceNow, a metric breaches a threshold in CloudWatch — and an agent wakes up to handle it. This shifts agents from synchronous request-response to asynchronous, scalable, decoupled processing.

The AWS building blocks are Amazon EventBridge for event routing and AWS Step Functions for workflow orchestration. EventBridge receives the event, matches it against a rule, and triggers a Lambda function or Step Functions state machine.

Step Functions then coordinates the multi-step agent flow — retries, parallel branches, human approval steps. Instead of one agent handling 10,000 tickets sequentially, you fan out across Lambda invocations that each handle one ticket, with Step Functions ensuring each workflow completes or fails gracefully.

Consider a document-intake pipeline: a file lands in Amazon S3, which emits an event that EventBridge matches to a rule and routes to a Step Functions state machine. The state machine invokes a reasoning agent to classify the document, branches based on the classification, and — for the branch that needs human sign-off — pauses at an approval step until someone reviews it.

If the classification step fails (a malformed file, a timeout), Step Functions retries with backoff before falling back to a dead-letter path instead of silently dropping the document.

None of this requires the agent itself to know about retries or parallelism; that responsibility sits in the orchestration layer, which is exactly the separation of concerns that makes event-driven agentic AI patterns easier to operate than a single long-running agent process.

Agentic AI Patterns: Coding Agents and Voice Interface Agents

Two specialized patterns map to high-value enterprise use cases by narrowing the agent’s scope to a single interaction modality. Coding agents write, test, and fix code, combining a code-trained LLM with access to a repository, test runner, and build system.

The AWS flagship is Amazon Q Developer, which embeds in your IDE and AWS console and excels at mechanical refactoring, boilerplate generation, test coverage, and bug fixes. The pattern shines when paired with strict evaluation: every suggested change must pass the test suite, and the agent iterates until it does.

Voice interface agents handle spoken conversation: Amazon Transcribe for speech-to-text, an LLM on Amazon Bedrock for reasoning, and Amazon Polly for text-to-speech. Amazon Lex adds intent classification and slot filling for structured dialogues. Voice agents are common in call-center automation, IVR replacement, and accessibility tooling. Both patterns demonstrate a meta-principle: specialization beats generality — an agent tuned for one modality consistently outperforms a general-purpose agent trying to do everything.

For coding agents, the evaluation loop is what makes this agentic AI pattern trustworthy: Amazon Q Developer proposes a change, the existing test suite runs against it, and only a change that passes gets surfaced as a suggestion — a failing change triggers another iteration rather than a broken pull request.

For voice agents, the corresponding discipline is turn-taking latency: Lex handles the deterministic parts of the conversation (confirming a slot value, routing to the right intent) so the more expensive Bedrock-backed reasoning step is invoked only when the conversation genuinely needs open-ended understanding, keeping the perceived response time low enough for a caller not to hang up.

Collaborative Multi-Agent Systems

The orchestrator-subagent configuration is the most common form of multi-agent collaboration, but it is not the only one. More advanced patterns involve multiple independent agents communicating through shared state, message buses, or dedicated agent-to-agent protocols. Where orchestrator-subagent is hierarchical, full multi-agent systems are peer-to-peer.

Use cases include research pipelines (one agent retrieves papers, another extracts claims, a third cross-checks against a knowledge base, a fourth synthesizes the brief) and incident response (monitoring, triage, remediation, and communications agents acting on the same incident). AWS supports these patterns through Amazon Bedrock AgentCore, the Agent-to-Agent (A2A) protocol for standardized communication, and Amazon EventBridge for loose coupling.

Multi-agent systems add real complexity — coordination overhead, debugging difficulty, emergent behavior. Start with orchestrator-subagent and graduate to peer-to-peer only when the hierarchical model cannot solve your problem.

The coordination overhead is not just conceptual in these agentic AI patterns. Every additional agent in a peer-to-peer system is another party that can misinterpret a shared message, act on stale state, or duplicate work another agent already completed. The Agent-to-Agent (A2A) protocol helps by giving agents a standardized way to describe their capabilities and exchange structured requests instead of ad hoc text, which reduces (but does not eliminate) misinterpretation.

EventBridge’s loose coupling means an agent can publish that a task finished without knowing or caring which other agents are listening — a property that scales well but also makes end-to-end debugging harder, because no single agent has a full view of the pipeline. That is precisely why the observability layer described next is not optional once you cross from orchestrator-subagent into full multi-agent territory.

Observability and Control in Agent Systems

Production agentic AI patterns are non-deterministic by design, which makes observability non-negotiable. Without tracing you cannot debug a failed run, attribute cost, or prove compliance. Every deployment needs three primitives: traces of every tool call, metrics on success rate and latency, and logs of prompts and responses.

AWS provides these natively. AWS X-Ray traces each Bedrock Agent invocation end to end, showing the rationale, tool calls, and their results. Amazon CloudWatch collects metrics and logs. Amazon Bedrock Guardrails adds runtime policy enforcement — blocking harmful outputs, redacting PII, preventing unauthorized tool calls. Control goes further: circuit breakers, human-in-the-loop checkpoints for consequential actions, and version control for prompts — the discipline known as AgentOps (Part 9).

In practice, an X-Ray trace is what turns “the agent gave a wrong answer” into an actionable bug report: you can see the exact rationale the model generated, which action group it called, what that call returned, and where the reasoning diverged from what you expected. Without that trace you are left guessing whether the model reasoned poorly, the tool returned bad data, or the prompt was ambiguous — three very different fixes.

Guardrails should be layered the same way you would layer input validation in traditional software: deny known-bad topics outright, redact PII before it reaches a log, and route any action tagged as consequential (refunds, account changes, external emails) through a human approval step rather than letting the agent execute it unattended.

Agentic AI Patterns in Practice: A Worked Example

Imagine an insurance company receiving 5,000 claims per week. A monolithic agent asked to “process the claim” would need to read the document, classify it, extract damage details, query the policy, calculate a payout, and draft a response — all in one prompt.

The orchestrator-subagent pattern splits this into a supervisor plus three specialists: a document-analysis agent (vision-capable model), a policy agent (RAG over the policy knowledge base), and a payout-calculation agent (Lambda with deterministic logic).

On AWS, the supervisor is a Bedrock Agent with multi-agent collaboration. The document agent uses Anthropic Claude on Bedrock with an image-action group. The policy agent uses Bedrock Knowledge Bases backed by OpenSearch Service. The payout agent is plain Lambda.

Walking through a single claim end to end illustrates these agentic AI patterns in practice: the supervisor receives the claim package (a scanned form plus photos) and first delegates to the document-analysis agent, which returns a structured extraction — incident type, estimated damage, claimant details.

The supervisor passes the incident type and policy number to the policy agent, which queries Bedrock Knowledge Bases for the relevant coverage clause and returns a grounded citation rather than a guess.

Only once both of those results are in hand does the supervisor call the payout agent, which is deliberately plain Lambda rather than an LLM — payout arithmetic is deterministic, so there is no reasoning benefit to routing it through a model, and a plain function is faster, cheaper, and trivially testable. The supervisor then assembles the three results into a single draft response.

Edge cases are where this agentic AI pattern earns its complexity budget. A scanned form that is illegible triggers the document agent to return a low-confidence flag instead of a guessed value; the supervisor is configured to route anything below a confidence threshold to a human reviewer rather than letting the payout agent compute against fabricated data.

A policy that has an unusual exclusion clause the knowledge base does not clearly resolve produces a citation with low retrieval relevance, which the supervisor treats the same way — as a signal to escalate rather than proceed.

This is the practical value of splitting one monolithic prompt into specialists: each specialist can fail loudly and narrowly, instead of the whole pipeline silently producing a confident but wrong answer.

Step Functions coordinates the flow and X-Ray traces every step so the claims team can audit any decision. Each claim resolves in seconds and humans review only edge cases. The same pattern generalizes to retail order issues, healthcare patient intake — anywhere specialized agents coordinate under a supervisor.

The same X-Ray trace that helps debug a wrong answer also becomes the audit trail a compliance team needs: for any claim, an auditor can replay exactly which subagent produced which piece of the decision, which policy clause was cited, and which human (if any) approved the payout.

That auditability is a direct consequence of splitting responsibilities across named subagents rather than burying every decision inside one opaque prompt — it is a design property, not something bolted on afterward.

Agentic AI Patterns: Common Mistakes to Avoid

Teams moving from prototype to production hit predictable pitfalls. Most of these agentic AI patterns mistakes are not exotic — they are the same over-engineering and under-instrumenting failures that plague any distributed system, just wearing an LLM costume:

• Choosing ReAct by default — ReAct is flexible but expensive; for predictable workflows, plan-and-solve or chain-of-thought is far cheaper. Teams that default to ReAct for everything end up paying for many extra model calls on tasks that never needed adaptive reasoning in the first place.
• Stuffing every tool into one agent — single-agent scope creep degrades reasoning; split into orchestrator + subagents instead. Once an agent’s action-group list grows past a handful of tools, the model starts choosing the wrong tool more often simply because the decision space got bigger, not because the task got harder.
• Skipping observability — without tracing you cannot debug a non-deterministic failure; instrument from day one. Retrofitting X-Ray and CloudWatch after an incident means you cannot reconstruct what actually happened during the failure that prompted you to add it.
• Forgetting event-driven triggers — many agents work better as Step Functions workflows triggered by events than as synchronous APIs. Forcing a naturally asynchronous workload (batch document processing, scheduled reconciliation) through a synchronous request-response agent just adds timeout risk with no benefit.
• Treating Guardrails as optional — shipping an agent without runtime policy enforcement means the first unsafe output, PII leak, or unauthorized tool call happens in production instead of in testing. Guardrails are cheap to configure and expensive to skip.
• Not bounding the reasoning loop — an agent without a maximum step count or a cost ceiling can burn through a budget in minutes when a tool starts returning errors it cannot resolve. A hard cap on steps, paired with a fallback to human handoff, turns a runaway loop into a bounded, recoverable failure.

Agentic AI Patterns: Best Practices

These agentic AI patterns best practices apply regardless of which specific pattern you pick, because they address the properties every production agent shares — non-determinism, tool dependency, and cost that scales with reasoning steps rather than with lines of code.

• Start with a single reasoning agent before introducing orchestrator-subagent complexity. A single agent is easier to prompt, test, and debug; only split into a supervisor and specialists once you can point to a concrete symptom — degrading answer quality, an unmanageable tool list, or a need for different models per subtask — that a single agent cannot fix.
• Pick the cheapest LLM workflow that solves the task — chain-of-thought before ReAct. Every unnecessary reasoning-and-act cycle is a model call you are paying for and a millisecond of latency the user is waiting through; upgrade workflow complexity only when a cheaper one demonstrably fails the task.
• Use Amazon Bedrock Knowledge Bases for any facts the agent must reference accurately. Never let a model recall a policy number, a price, or a compliance rule from its training data when a retrieval call can ground it in the current, authoritative source instead.
• Instrument every agent with X-Ray traces and CloudWatch metrics from day one. Add tracing before the first production incident, not after — the trace you wish you had during an outage is the one you should have turned on during the pilot.
• Wrap consequential tool calls in Bedrock Guardrails and human approval steps. Any action that spends money, changes a customer’s account, or sends an external communication should pass through an explicit checkpoint, so a reasoning error becomes a flagged review instead of an executed mistake.
• Version and test prompts like code. A prompt change can silently shift an agent’s behavior across every downstream tool call; treat prompt edits with the same review and regression-testing discipline as a code change, and keep a rollback path ready.
• Design for graceful degradation, not just the happy path. Decide up front what the agent does when a tool times out, a knowledge base returns nothing relevant, or a subagent fails — a clear fallback (retry, escalate, or return a bounded “I don’t know”) is what separates a resilient agentic system from one that fails unpredictably in production.

Agentic AI Patterns: Frequently Asked Questions

What is the difference between a reasoning agent and a RAG agent?

A reasoning agent plans and decides using only the LLM’s internal knowledge. A RAG agent augments that reasoning by retrieving context from a knowledge base before generating. Most production patterns combine both: reasoning for planning, RAG for accuracy.

When should I use an orchestrator-subagent pattern instead of a single agent?

Move to orchestrator-subagent when your single agent has more than about five tools, when reasoning quality degrades, or when different parts of the task need different models (vision for documents, text for policy).

Which LLM workflow is cheapest on Amazon Bedrock?

Chain-of-thought is cheapest (a single LLM call) but cannot use tools. ReAct is most flexible but can make many calls. Plan-and-solve sits in between.

How do I choose between Bedrock Agents and Bedrock Knowledge Bases?

Bedrock Agents are the right starting point when an agentic AI pattern needs tool use, multi-step reasoning, or action execution — the orchestrator, multi-agent, and coding patterns all live here. Bedrock Knowledge Bases are the right starting point when the dominant pattern is retrieval — RAG, semantic search over company data, grounding the model on a corpus.

In practice the two compose: an agent consults a knowledge base as one of its tools. AWS Prescriptive Guidance treats them as the canonical building blocks for the reasoning and RAG blueprints.

What is the difference between ReAct and orchestrator agents on AWS?

ReAct (reason + act) is a tight loop where a single model reasons about a tool call, observes the result, and reasons again — it powers the basic reasoning pattern. The orchestrator pattern splits that loop across specialized agents: an arbiter agent decomposes a request and delegates subtasks to specialists that each run their own ReAct loops.

Bedrock Agents supports both; Bedrock AgentCore adds the managed supervisor runtime the orchestrator pattern needs for multi-agent collaboration at scale.

Agentic AI Patterns: Key Takeaways

• Six core patterns: reasoning, RAG, coding, voice, orchestrator, multi-agent — each optimizes for a different bottleneck (accuracy, context, code quality, latency, throughput, or coordination).
• Pick the LLM workflow (chain-of-thought, ReAct, plan-and-solve) that matches the task’s adaptivity needs — the cheapest workflow that still solves the task wins.
• Event-driven orchestration with EventBridge and Step Functions scales agents from a single synchronous call to enterprise volume.
• Observability via X-Ray and CloudWatch, plus Bedrock Guardrails for runtime control, is non-negotiable for non-deterministic systems.

Every one of these agentic AI patterns maps to a concrete Bedrock service and a concrete cost line, so choosing the right pattern is a design decision, not an afterthought. Reasoning agentic AI patterns route through Bedrock Agents; RAG agentic AI patterns route through Knowledge Bases; and coding agentic AI patterns route through Q Developer.

Start with the simplest agentic AI pattern that solves your bottleneck, wire in the matching AWS service, add observability from day one, and graduate to orchestrator or multi-agent complexity only once a single reasoning agent cannot keep up.