What Amazon Bedrock Agents Actually Gives You

Bedrock Agents is a managed reasoning loop that handles orchestration, prompt construction and session state so you do not have to write the tool-calling loop yourself.

Amazon Bedrock Agents is a managed agent runtime. You describe an agent declaratively — a foundation model, a natural-language instruction, a set of action groups, optionally a knowledge base and a guardrail — and AWS runs the reasoning loop for you. You call one API, InvokeAgent, and the service does the rest: it builds the prompt, calls the model, reads the model's decision to use a tool, invokes that tool, feeds the result back to the model, and repeats until the model produces a final answer.

The three things it manages

Orchestration. Without an agent runtime you write the loop yourself: call Converse, inspect stopReason == "tool_use", dispatch the tool, append a toolResult block, call again. Bedrock Agents owns that loop. It also decides which action group and operation to call, in what order, and when it has enough information to stop. The default orchestration strategy is a ReAct-style reason-then-act cycle, and each turn's reasoning is exposed as a rationale in the trace.

Prompt management. The agent does not send your instruction to the model verbatim. It renders a set of prompt templates — pre-processing, orchestration, knowledge base response generation, post-processing — and injects your instruction, the action group schemas, the conversation history and the session attributes into placeholders in the orchestration template. Pre-processing classifies and sanitises the user's input before orchestration runs; post-processing reformats the final answer. Pre-processing and post-processing can be enabled or disabled, and every template can be overridden through promptOverrideConfiguration.

Session handling. You pass a sessionId string of your own choosing. The service stores the conversation turns for that session and replays them into the prompt on the next call, so you do not manage a message array. Sessions expire after an idle period you configure with idleSessionTTLInSeconds on the agent; the default is 600 seconds. Separately, you can enable memory (SESSION_SUMMARY) with a memoryId so the agent carries a summary across sessions for a returning user.

What it is not

It is not a workflow engine. If the sequence of steps is known in advance and must be identical every time, use Step Functions and call Bedrock from it — an LLM deciding a fixed order is expensive and non-deterministic. It is not the Converse API tool loop either: that is the DIY option you reach for when you need full control over prompts, retries and context trimming. And it is not Amazon Bedrock AgentCore, which is the separate offering for hosting your own agent framework code (LangGraph, Strands, CrewAI) with managed runtime, gateway, memory and identity primitives. Bedrock Agents is the opinionated, declarative option; AgentCore is the bring-your-own-framework option.

The trade-off is control. You gain a loop you never have to debug and lose the ability to inspect or mutate the prompt on every hop except through template overrides. If your failure mode is "the model chose the wrong tool", you fix it with better instructions and better action descriptions, not with code.

Example

Example · python
import boto3, uuid

cp = boto3.client("bedrock-agent")          # control plane
rt = boto3.client("bedrock-agent-runtime")  # data plane

agent = cp.create_agent(
    agentName="claims-assistant",
    agentResourceRoleArn="arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForAgents_claims",
    foundationModel="anthropic.claude-3-5-sonnet-20241022-v2:0",
    instruction=(
        "You are a motor insurance claims assistant for UK policyholders. "
        "Look up claims by reference, explain their status in plain English, "
        "and never quote a settlement figure that you have not retrieved from a tool."
    ),
    idleSessionTTLInSeconds=900,
)
agent_id = agent["agent"]["agentId"]

# Action groups are attached here, then the DRAFT is packaged:
cp.prepare_agent(agentId=agent_id)

response = rt.invoke_agent(
    agentId=agent_id,
    agentAliasId="TSTALIASID",      # built-in test alias -> DRAFT
    sessionId=str(uuid.uuid4()),    # you choose this; reuse it for the conversation
    inputText="What is happening with claim MC-40192?",
)

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

When to use it

  • A support portal where a user asks about an order and the assistant must decide on its own whether to look up the order, the refund policy, or both.
  • An internal ops chatbot that answers infrastructure questions by calling read-only APIs, where you do not want to maintain a bespoke tool-calling loop.
  • A prototype that must be standing up in a day, using console-defined action groups before any of the orchestration is committed to code.

Discussion

  • Be the first to comment on this lesson.