What Are Bedrock Agents?
Amazon Bedrock Agents is a fully managed agentic runtime that allows foundation models to go beyond generating text — they can call external systems, execute multi-step plans, and autonomously achieve goals. While a standard LLM invocation is a single-pass operation, Bedrock Agents runs an iterative loop: .
The mechanism that connects an agent to the real world is Action Groups and tool use. Through Lambda-backed Action Groups, OpenAPI-defined REST APIs, or built-in tools like Code Interpreter, agents can query databases, update CRM records, process payments, send notifications, and run arbitrary code — all triggered by a natural language request from the user.
For AIP-C01, Bedrock Agents appears prominently in Domain 3 (AI Solutions with Foundation Models). You need to understand not just how to configure it, but when to recommend it versus simpler alternatives, and how to design reliable agentic architectures.
Architecture and Runtime Internals
A Bedrock Agent is defined by three core components.
The foundation model acts as the reasoning engine. Claude 3.5 Sonnet is preferred for complex multi-step reasoning tasks; Claude 3 Haiku suits latency-sensitive use cases like customer service chatbots.
Agent instructions define the agent's persona, responsibilities, and behavioral constraints in natural language. Specificity matters: vague instructions lead to unpredictable behavior. Include explicit constraints ("Never share personal data"), escalation rules ("For refunds over $1,000, confirm with the user first"), and scope boundaries.
Action Groups and Knowledge Bases provide the agent's tools and reference knowledge. Action Groups define what the agent can do; Knowledge Bases define what it knows.
When a user sends a message, the agent internally executes a reasoning loop driven by the ReAct (Reasoning + Acting) pattern. The model reasons about what tool to call, calls it, observes the result, and iterates until the goal is achieved. Bedrock automatically records every step as a trace event.
Action Groups: OpenAPI Schema and Lambda Integration
Each Action Group combines an OpenAPI 3.0 schema (function signatures and descriptions) with a Lambda function (execution logic). The model uses the schema descriptions to decide which function to call and with what parameters — so description quality directly affects agent reliability.
Key design principles for Action Group schemas:
should be a self-descriptive verb-noun pair (, ) fields must clearly explain when to use this function, not just what it does Mark parameters as accurately; don't leave optional parameters ambiguous
Lambda functions receive a structured event from Bedrock Agents containing , , , and . They must return a response in a specific format with and . Critical implementation notes:
Bedrock waits up to 60 seconds for a Lambda response. Long-running operations require asynchronous patterns. Apply input validation inside Lambda — never trust agent-supplied parameters blindly. Design Lambda functions to be idempotent so that duplicate calls (from agent retries) don't cause double-processing. Use structured error responses ( field) to help the agent understand failure causes and decide whether to retry or escalate.
Tool Use / Function Calling Patterns
Even without the full Bedrock Agents runtime, you can implement tool use directly through the . The flow is: send a request with containing tool definitions → model returns a block specifying which tool to call → your application executes the tool → send back to the model → model generates the final response.
The key difference is ownership of the orchestration loop. With raw tool use via Converse API, your application manages the reasoning loop (deciding when to stop, handling errors, managing conversation history). With Bedrock Agents, AWS manages the loop automatically. For production agentic systems, Bedrock Agents is generally preferable unless you need custom orchestration logic that the managed runtime cannot accommodate.
Multi-Step Orchestration and ReAct
The ReAct pattern structures agent reasoning as an explicit cycle: Thought → Action → Observation, repeated until the goal is met. This makes agent reasoning interpretable and debuggable. When you enable traces, you see exactly what the agent was thinking before each tool call.
Practical ReAct orchestration considerations:
Set a maximum iteration limit to prevent runaway loops (configurable in Bedrock Agents) Design Action Group functions so each represents a single, clear operation — avoid "do everything" functions that make the agent's reasoning ambiguous For write operations (database updates, payments), include a confirmation step before execution to implement human-in-the-loop oversight
!Bedrock Agents ReAct reasoning loop
Agent Memory and Session Management
Sessions () maintain conversation context within a single interaction. Memory extends context across multiple sessions — the agent can remember a user's shipping address or product preferences from a prior conversation.
Memory is stored in S3 and summarized by the model at session end. Configuration options include retention period and summarization verbosity. In production, match session IDs to your application's user session lifecycle — same session ID for continuous conversations, new ID when a new conversation begins.
Multi-Agent Collaboration
Complex workflows benefit from specialized agents orchestrated by a supervisor. Bedrock supports native multi-agent collaboration where a supervisor agent delegates subtasks to sub-agents via Action Groups. The sub-agents focus on specific domains (flight booking, hotel booking, payment processing) while the supervisor coordinates the overall goal.
Multi-agent architecture tradeoffs to understand for the exam:
| Aspect | Single Agent | Multi-Agent | |--------|-------------|-------------| | Complexity | Lower | Higher | | Maintainability | Harder as scope grows | Each agent independently testable | | Latency | Lower (no inter-agent calls) | Higher (network round-trips) | | Fault isolation | Harder | Each agent fails independently |
Debugging with Trace Logs
Enable traces with in calls. Trace events include (reasoning + action), (input validation), (output formatting), and (error details). Ship traces to CloudWatch Logs for production monitoring. Use CloudWatch Logs Insights to query for patterns like tool call failure rates or iteration counts to continuously improve agent reliability.
Exam Quick Reference
"Autonomous external API execution" -- Bedrock Agents + Action Groups "Multi-step reasoning framework" -- ReAct (Reasoning + Acting) "Action Group execution engine" -- AWS Lambda "Tool function specification" -- OpenAPI 3.0 schema "Agent step-by-step debugging" -- Trace logs () "Cross-session user memory" -- Agent Memory (S3-backed) "Multiple specialized agents" -- Multi-agent collaboration (supervisor pattern) "Input/output safety filtering" -- Bedrock Guardrails "Direct code execution in agent" -- Code Interpreter (built-in tool)