Pattern 3 of 10 · Autonomous reasoning + tool use

Agentic Workflow · ReAct Pattern

When the task requires the AI to plan, take actions, and adapt — not just answer questions — you need an agent. Bedrock Agents run a loop of Reason → Act → Observe, calling tools (Lambda-backed action groups, knowledge bases, external APIs) until the goal is achieved. Guardrails wrap the whole thing.

Architecture diagram

— Agentic workflow · ReAct reasoning loop —
👤 User goal or request goal BEDROCK AGENT ReAct loop Reason → Act → Observe (loops until done) powered by an FM ⊕ GUARDRAILS WRAP INPUT & OUTPUT ACTION GROUP Lambda Tool defined by OpenAPI schema KNOWLEDGE BASE Bedrock KB for lookup / citations EXTERNAL API via Lambda CRM · DB · service call ACT OBSERVE ACT OBSERVE ACT OBSERVE final response BEDROCK AGENT TRACING Every Reason / Act / Observe step is logged for debugging and explainability LEGEND ACT: agent calls a tool OBSERVE: tool returns User in/out Guardrails zone

How data flows

The Bedrock Agent sits at the center, powered by a foundation model that drives a ReAct loop: Reason about what's needed, Act by calling a tool, Observe the result, then reason again. The loop continues until the agent decides it has enough information to respond.

Tools come in three flavors: Action Groups (Lambda-backed functions defined by OpenAPI schemas), Knowledge Bases (for document lookup with citations), and external API calls (via Lambda to CRMs, databases, SaaS services). Bedrock Guardrails wrap the whole agent — filtering input from the user and output back to them.

Bedrock Agent Tracing records every reasoning step, tool call, and observation, so you can debug and explain the agent's behavior to users or auditors.

AWS services used

Amazon Bedrock AgentsThe managed agent service. You define action groups, attach knowledge bases, and configure guardrails. Bedrock handles the ReAct reasoning loop.
AWS LambdaBacks each action group. One Lambda per tool/function. Lightweight, stateless tool execution.
OpenAPI schemaDefines each action's parameters and return types. The agent reads the schema to know what tools exist and how to call them.
Bedrock Knowledge BasesOptional. Gives the agent retrieval over your documents for lookup tasks and grounded citations.
Bedrock GuardrailsWrap the agent — filter user input before reasoning starts and filter final responses before they reach the user.
Step Functions (optional)For human-in-the-loop patterns. Pauses agent execution awaiting approval, then resumes. Use the callback pattern.
CloudWatch LogsWhere Agent Traces are stored. Query with Logs Insights to analyze reasoning patterns.

When to use this pattern

✓ Use Bedrock Agents when…

  • The task requires taking actions, not just answering"Cancel my order," "schedule the meeting," "update the record" — these need tool calls, not just retrieval.
  • The task requires multi-step reasoning"Find customer X's order, check if it was delivered, and if not, file a support ticket." Needs planning across multiple steps.
  • Tools exist as APIs you can wrap in LambdaCRM, order system, calendar, internal DB. If you can call it from code, the agent can use it.
  • You want reasoning traces for debugging / complianceBedrock Agent Tracing gives you every thought, action, and observation — essential when the agent does something unexpected.
  • You need a single agent (not a team of specialized agents)One agent, one set of tools. For coordinated specialists, see Pattern 4.
  • You prefer managed over custom orchestrationBedrock Agents handles the loop, timeouts, retries. You don't write the ReAct logic yourself.

✗ Do NOT use Agents when…

  • The task is pure Q&A over documentsThat's RAG, not agents. Use Pattern 1. Adding an agent just slows it down.
  • The workflow is deterministic"Every morning, summarize yesterday's sales" is a scheduled Lambda + Bedrock call, not an agent. Agents are for dynamic planning.
  • Tight latency requirements (<500ms)Agents loop multiple times per request — latency compounds. Not suitable for real-time UI.
  • You need step-by-step orchestration with branching business logicFor complex branching, Step Functions is more predictable. Agents decide on their own path; Step Functions follows yours.
  • Cost sensitivity is criticalEach reasoning loop = more FM calls = higher cost. For high-volume simple tasks, direct Bedrock invocations are cheaper.
  • Deep customization of the reasoning loop is requiredIf you need fine control over memory, planning, or reasoning strategy, consider Strands Agents (open-source) instead of Bedrock Agents.

Exam angle

Pattern-match shortcuts When a stem mentions "take actions," "autonomous," "multi-step task," "tool use," or "plan and execute," the answer is almost always Bedrock Agents (preferred over Strands Agents when "managed" or "minimal operational overhead" appears).
The "system prompt can enforce it" trap A common distractor says "just add the requirement to the system prompt" (e.g., "agent must get approval for refunds over $500"). System prompts are advisory, not enforcement. Real enforcement requires Step Functions callback pattern or a deterministic wrapper around the agent.
Agents vs Strands vs AgentCore Bedrock Agents = managed, default choice. Strands Agents = open-source framework, use when you need custom reasoning. Bedrock AgentCore = infrastructure for running agents at scale (not an agent framework itself). Don't confuse them.

Keywords that point here

take actions multi-step reasoning tool use action groups ReAct autonomous agent tracing OpenAPI schema

Related patterns

For multiple coordinated agents, see Pattern 4: Multi-Agent Orchestration.
For just answering questions, use Pattern 1: Basic RAG.
For deterministic multi-step workflows, use Step Functions directly instead of an agent.
Full security posture: Pattern 10: Defense-in-Depth.

↑