TL;DR:

  • AWS Bedrock Agents provides a fully managed environment for building AI agents that orchestrate multi-step tasks, call external tools, and query proprietary knowledge bases without managing your own orchestration infrastructure.
  • It integrates directly with AWS services — Lambda for tool execution, S3 + OpenSearch for knowledge bases, Secrets Manager for credentials — making it the natural choice for teams already invested in AWS.
  • The main trade-offs vs building your own: you get operational simplicity and enterprise AWS controls, but less flexibility in orchestration logic and higher vendor lock-in.

If your organisation runs on AWS, Amazon Bedrock Agents is the fastest path to production AI agents. Rather than wiring together LLM calls, tool definitions, and state management yourself, Bedrock Agents handles the orchestration loop — deciding when to call tools, when to query knowledge bases, when to respond — while you define the actions and data sources.

This guide covers what Bedrock Agents actually does, how it compares to building your own agent stack, and what the practical workflow looks like.

What Bedrock Agents Provides

An agent in Amazon Bedrock consists of several components you configure:

Foundation Model — The LLM doing the reasoning. You choose from the models available in Bedrock: Claude 3.x (Anthropic), Nova (Amazon), Llama 3.x, Mistral, or others. Claude models are the most commonly used for complex reasoning tasks.

Instructions — A natural language system prompt defining the agent’s role, scope, and constraints.

Action Groups — The tools the agent can call. Each action group is backed by an OpenAPI schema (describing the available operations) and either an AWS Lambda function (for live execution) or a direct integration. When the agent decides a tool is needed, Bedrock calls the Lambda; the result is returned to the agent for the next reasoning step.

Knowledge Bases — Vector stores the agent can query via RAG. You point a knowledge base at an S3 bucket; Bedrock handles chunking, embedding, and indexing. At query time, the agent can retrieve relevant context before answering.

Memory — Bedrock Agents supports session-level memory (maintaining context within a conversation) and cross-session memory (persisting facts about users or state across multiple sessions).

Guardrails — Content filtering, topic restrictions, and PII handling applied at the Bedrock layer — not something you build yourself.

The Agent Orchestration Loop

When a user sends a message to a Bedrock Agent, the following happens:

  1. The model receives the user message, the system instructions, and any retrieved memory
  2. The model reasons about whether to answer directly, call a tool, or query a knowledge base
  3. If a tool call is needed, Bedrock invokes the Lambda function and returns the result to the model
  4. The model reasons again with the tool output — this continues until the model has enough to produce a final response
  5. The response is returned to the caller; memory is updated if configured

This ReAct-style loop (reason, act, observe) runs automatically. You don’t write orchestration code. AWS handles retries, timeouts, and trace logging.

Setting Up an Agent: The Practical Workflow

1. Define your action group Lambda

Your Lambda function receives a structured JSON payload from Bedrock when the agent decides to call it:

import json

def lambda_handler(event, context):
    agent = event['agent']
    action_group = event['actionGroup']
    api_path = event['apiPath']
    parameters = {p['name']: p['value'] for p in event.get('parameters', [])}
    
    # Handle different API paths
    if api_path == '/get-order-status':
        order_id = parameters.get('order_id')
        # Your business logic here
        result = get_order_from_database(order_id)
        return {
            'messageVersion': '1.0',
            'response': {
                'actionGroup': action_group,
                'apiPath': api_path,
                'httpMethod': event['httpMethod'],
                'httpStatusCode': 200,
                'responseBody': {
                    'application/json': {
                        'body': json.dumps(result)
                    }
                }
            }
        }

2. Write your OpenAPI schema

Bedrock uses the schema to tell the model what’s available. Write it clearly — the model reasons from it:

openapi: "3.0.0"
info:
  title: Order Management API
  version: "1.0"
paths:
  /get-order-status:
    get:
      summary: Retrieve current status of a customer order
      description: Returns the status, estimated delivery date, and tracking info for an order ID.
      operationId: getOrderStatus
      parameters:
        - name: order_id
          in: query
          required: true
          schema:
            type: string
          description: The unique order identifier
      responses:
        "200":
          description: Order status successfully retrieved

3. Configure knowledge bases

Point Bedrock at your S3 bucket containing documents (PDFs, text files, HTML). Choose an embedding model (Amazon Titan Embeddings or Cohere Embed) and a vector store (Amazon OpenSearch Serverless, Pinecone, Redis Enterprise Cloud, or Aurora PostgreSQL with pgvector).

Bedrock handles the sync — new documents in S3 trigger re-indexing. The agent decides when to query the knowledge base vs when to use tool calls vs when to answer from parametric knowledge.

Invoking Your Agent

import boto3
import json

bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

response = bedrock_agent_runtime.invoke_agent(
    agentId='YOUR_AGENT_ID',
    agentAliasId='YOUR_ALIAS_ID',
    sessionId='unique-session-id',
    inputText='What is the status of order ORD-29481?'
)

# Stream the response
for event in response['completion']:
    if 'chunk' in event:
        print(event['chunk']['bytes'].decode('utf-8'), end='')

The SDK returns a streaming response. For debugging, enable traces to see the reasoning steps:

response = bedrock_agent_runtime.invoke_agent(
    agentId='YOUR_AGENT_ID',
    agentAliasId='YOUR_ALIAS_ID',
    sessionId='session-123',
    inputText='...',
    enableTrace=True
)

Traces show each reasoning step: what the model decided, which tool it called, the tool output, and how that informed the next step. Essential for debugging unexpected behaviour.

When to Use Bedrock Agents vs Building Your Own

Choose Bedrock Agents when:

  • Your team is already on AWS and wants to avoid managing orchestration infrastructure
  • You need enterprise controls — AWS IAM, VPC, CloudTrail audit logs, Guardrails — as first-class primitives
  • Your use case maps well to the Lambda + S3 + OpenSearch pattern
  • You want managed scaling without configuring agent infrastructure

Build your own (LangGraph, Temporal, OpenAI Agents SDK, etc.) when:

  • You need fine-grained control over orchestration logic — custom routing, parallel tool calls, complex branching
  • You want to run on multiple cloud providers or avoid vendor lock-in
  • Your agents have unusual state management requirements (e.g., long pauses waiting for human approval in a multi-day workflow)
  • You want to mix models from different providers within a single agent loop

The main limitation of Bedrock Agents is the relative rigidity of the orchestration loop. If your agent needs to do things the Bedrock loop wasn’t designed for — spawning sub-agents with different models, running tool calls in parallel, implementing custom retry logic — you’ll be working against the platform. Framework-based approaches give you full control at the cost of managing the infrastructure yourself.

Pricing

Bedrock Agents pricing has two components: the foundation model tokens (billed per-token at standard Bedrock rates) and the orchestration sessions. There’s no per-agent provisioning cost — you pay for what you use. For agents handling customer-facing queries at volume, the token cost dominates; Bedrock’s cross-region inference and prompt caching features can reduce this substantially.

For teams evaluating whether Bedrock Agents makes sense, the answer usually comes down to how much of your existing infrastructure is already AWS, how standardised your agent patterns are, and how important native AWS compliance controls are to your deployment requirements.