Bedrock Agents Introduction Part 3

In this lesson we introduce Bedrock Agents and explain how they let foundation models take real-world actions—such as calling APIs, querying databases, or carrying out multi-step workflows—rather than only producing content. We’ll cover:

• The gap that exists when a foundation model must take real-world actions.
• What Bedrock Agents provide to bridge that gap.
• How your application interacts with Bedrock Agents.
• Expected results and a key takeaway.

​

Problem statement

Foundation models (for example Anthropic Claude, Meta Llama, or other large models) excel at generating text, images, or other modalities. However, they do not by themselves perform side-effecting operations—such as invoking external APIs, updating databases, or orchestrating multi-step processes. To accomplish those tasks today, you typically add custom orchestration code that:

• Calls the model and inspects its output.
• Constructs API requests (URLs, headers, payloads).
• Sends requests to external services.
• Parses responses and feeds results back into the model for further reasoning.

As the number of integrations grows, this custom orchestration becomes repetitive, brittle, and costly to maintain.

​

What Bedrock Agents provide

A Bedrock Agent centralizes orchestration. Your application sends a single request to the agent runtime specifying:

• Which foundation model(s) to use for reasoning.
• Which agent configuration to invoke (an agent is a configured entity with instructions and access to tools).
• The user task or instruction the agent should complete.

The agent runtime then decides whether to call external tools, which tools to call, how many calls to make, and how to use outputs to complete the task. In other words, the agent encapsulates planning and orchestration logic that you would otherwise implement in your application. An agent is configured with:

• One or more foundation models (the reasoning engine).
• Instructions that define the agent’s behavior and goals.
• Access to tools and APIs, organized into action groups.

At runtime the agent:

• Builds a plan.
• Selects appropriate tools.
• Executes calls to external services.
• Parses responses and iterates—feeding intermediate results back into the model—until the instruction is satisfied.

This converts a foundation model into an actor capable of accomplishing real-world tasks.

​

Key components of a Bedrock Agent

• Agent orchestrator: managed orchestration logic inside the agent runtime that coordinates planning, decision-making, and tool usage. This is provided by the service—you do not implement it yourself.
• Foundation model: the model the agent uses for reasoning and deciding when/how to call tools.
• Instructions: static guidance configured at agent creation (for example, “You are a customer support assistant; be concise and professional”) that shape behavior before any user prompt.
• Action groups: named collections of external services and tools (APIs, databases, etc.) the agent may call to fulfill tasks.

These components enable a repeated cycle: understanding → decision → action → response.

​

Agent workflow and your application

A typical end-to-end flow:

1. The end user interacts with your application (web UI, chat, voice, etc.).
2. Your application calls the Bedrock Agent Runtime (this is the agent runtime endpoint, not the standard Bedrock model endpoint).
3. The app invokes the agent using the InvokeAgent method and supplies the user’s prompt/instruction.
4. The agent uses its configured foundation model, action groups (tools/APIs), and optional knowledge base to plan and execute steps.
5. The agent returns a final, consolidated response to your application, which renders it to the user.

Action groups often contain functions like getOrder(), updateOrder(), or updateInventory()—the agent may call several actions and iterate with the foundation model before returning a final answer.

​

How your application invokes an agent

• Do not call the foundation model directly if you require tool use or orchestration.
• Call the Bedrock Agent Runtime and use the InvokeAgent API method, sending the prompt/instruction to the configured agent.
• The agent runtime mediates access to the foundation model, action groups, and an optional knowledge base (automated RAG) to provide context during reasoning.

A knowledge base is an automated retrieval-augmented-generation (RAG) system that supplies proprietary documents or context via similarity search. Combining a knowledge base with an agent improves accuracy when domain-specific context is required. After the agent completes its plan—whether it performed many API calls or lookups—the agent returns a single, consolidated response to your application. Your app is responsible for presenting that result to the user.

​

Summary and takeaway

Bedrock Agents remove the burden of writing and maintaining custom orchestration code by combining a foundation model with explicit instructions and configured tools (action groups). Your application invokes the agent via the agent runtime (using InvokeAgent), and the agent determines how best to use available models, tools, and knowledge bases to complete the assigned task—returning a single, consolidated response to your application. Next lesson: building and configuring an agent—defining instructions, registering action groups, and exposing the external APIs and data sources that the agent can call.

​

Links and references

• Anthropic Claude
• Meta Llama
• Retrieval-Augmented Generation (RAG) overview