Intermediate

Agents for Bedrock

Agents for Bedrock is a managed service that runs multi-step agentic workflows — the model reasons, decides what actions to take, calls your APIs or Lambda functions, processes results, and iterates until it completes a goal. You define the tools; AWS manages the orchestration loop.

How It Works

A Bedrock Agent has three configurable components: a foundation model that drives reasoning, a set of action groups that define what the agent can do, and optionally a Knowledge Base for retrieval. When you invoke an agent, it enters a ReAct loop — it reads the user's request, decides on an action, calls the action, receives the result, and either acts again or returns a final response.

Agent Architecture

User Input→Agent Orchestrator→Foundation Model (reasoning)

↓ tool call

Action Group→Lambda / API→result back to model

Action Groups

Action groups define the tools an agent can use. Each action group has an OpenAPI schema (describing available operations and their parameters) and a backend — either a Lambda function or an HTTP endpoint (Bedrock calls it directly). The model reads the schema to understand what operations exist and generates structured calls; Bedrock executes them.

Built-in action groups let the agent perform code interpretation (runs Python in a sandbox) and user confirmation (pauses to ask the user before executing). You don't need a Lambda for these.

Agent Memory

Agents support short-term memory (within a session — all turns of the conversation are available to the model) and long-term memory (GA late 2024 — key facts from past sessions are summarised and stored, then retrieved for future sessions). Long-term memory uses DynamoDB under the hood; you enable it per agent without managing the storage yourself.

Multi-Agent Collaboration

Multi-agent collaboration (GA March 2025) lets you build hierarchies of agents. A supervisor agent receives a high-level goal, breaks it down, and delegates subtasks to specialist subagents. Each subagent has its own model, action groups, and knowledge base. Results bubble back up to the supervisor, which synthesises a final answer.

Good multi-agent patterns

• Researcher + Writer + Reviewer pipeline
• Domain-specialist subagents (finance, HR, legal)
• Parallel research with synthesis

Watch out for

• Latency compounds across hops — each subagent adds round-trip time
• Cost multiplies — every step uses tokens
• Hard to debug — logs span multiple agents

Inline Agents

Inline agents (2025) skip the console-configured agent setup. You define everything in code — model, instructions, action groups — and invoke the agent in a single API call. Useful for dynamic agent configurations where the tools change per request.

Invoking an Agent

import boto3

agents_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

response = agents_runtime.invoke_agent(
    agentId="AGENT_ID",
    agentAliasId="TSTALIASID",  # or a deployed alias
    sessionId="session-123",
    inputText="Summarise last quarter's sales and flag anomalies",
)

for event in response["completion"]:
    if "chunk" in event:
        print(event["chunk"]["bytes"].decode(), end="", flush=True)

Checklist: Do You Understand This?

What is an action group and how does the model know what operations it can perform?
What is the difference between short-term and long-term agent memory?
When would you use multi-agent collaboration instead of a single agent?
What boto3 client do you use to invoke a Bedrock Agent?