Managed Abstraction With Bedrock Agents Part 2

This guide clarifies what you must define when creating an Amazon Bedrock agent and what the Bedrock runtime manages for you. It uses a concrete example — a Star Wars API assistant named SWAPIAgent — to show how agent configuration, tool wiring, and runtime orchestration work together.

What you define when creating an agent

When you create an agent in the Bedrock console, the agent builder wizard collects the required inputs. These choices shape the agent’s capabilities and the permissions it needs.

Configuration item	Purpose	Example / Notes
Agent resource role	IAM role the agent assumes to access AWS resources	Attach policies that allow invoking Lambda functions and any other AWS services the agent needs
Model selection	Foundation model used for reasoning and language understanding	e.g., Amazon Nova Micro — the agent definition is tied to a single chosen model
Agent instructions	Prompt-level behavioral guidance and persona	“You are a Star Wars assistant. Use SWAPI tools to look up factual information about characters…”
Action groups & invocation targets	Tools, APIs, or Lambda functions the agent may call	Supply OpenAPI specs for API awareness and pick the Lambda (or other target) to execute calls

Callout for IAM role:

Ensure the IAM role you attach to the agent has the proper policies to invoke the Lambda function and any other AWS resources the agent will use.

Agent instructions and the SWAPI example

Agent instructions provide high-level context and procedural guidance the model uses while planning actions. For a Star Wars assistant you might instruct the agent to:

Use the SWAPI action group when looking up canonical facts about characters.
When the user provides a character name, call the search endpoint (/people?search=<term>) to find matching characters.
If multiple matches are returned, ask a follow-up question to disambiguate.
For detailed attributes, call the detail endpoint (e.g., /people/{id}) once you have an identifier.

When you configure the action group that implements the SWAPI tool, provide an OpenAPI (Swagger) schema so the agent has precise awareness of available endpoints and parameters. For example:

openapi: "3.0.0"
info:
  title: "SWAPI Tools"
  version: "1.0.0"
paths:
  /people:
    get:
      description: "Search Star Wars characters by name. Use this when the user gives a name and you need matches."
      operationId: "search_people"
      x-requireConfirmation: DISABLED
      parameters:
        - name: search
          in: query
          description: "Character name to search for (e.g., luke, leia, vader)."
          required: true
          schema:
            type: string
      responses:
        "200":
          description: "Search results"
          content:
            application/json:
              schema:
                type: object
                properties:
                  results:
                    type: array
                    items:
                      type: object
                      properties:
                        name:
                          type: string
                        height:
                          type: string
                        mass:
                          type: string

You also select how action group endpoints are invoked. In this example the action group is wired to invoke a Lambda function (picked from a dropdown in the console) that in turn calls the public SWAPI endpoints. So, when defining the agent you specify:

The agent instructions (behavior and persona).
The OpenAPI schema for the action group (API surface and parameters).
The Lambda function (or other invocation target) that will execute the API calls.

What Bedrock handles at runtime

Amazon Bedrock’s agent runtime manages the orchestration of model reasoning and tool invocations. Key runtime responsibilities include:

Runtime responsibility	What Bedrock does
Intent interpretation	Uses the foundation model to map user prompts to actions and parameters
Parameter elicitation	Detects missing parameters for an action and asks clarifying questions
Tool selection	Chooses the correct action in an action group based on intent and the OpenAPI surface
Invocation flow	Determines call order (e.g., search first to obtain an ID, then detail) and executes calls via the configured invocation targets

Example user flow: “Tell me about Luke Skywalker.”

The user prompt arrives at your Bedrock application and is forwarded to the Bedrock agent runtime with the agent configuration.
The agent’s model recognizes this as a character lookup and consults the configured action group to decide which endpoint(s) to call.

A diagram titled "Workflow: Simple API Example" showing a user and app interacting with a Bedrock Agent Runtime (agent orchestrator and action groups) that uses a foundation model and calls AWS Lambda to query the Star Wars API (SWAPI). It highlights action endpoints like getPeople and GetPeople{id}.

Because the agent does not yet know Luke Skywalker’s SWAPI identifier, the agent runtime will typically:

Call the search endpoint (via the configured Lambda).
Receive a list of matches and extract the identifier for the correct match. If multiple matches exist, the agent may request clarification from the user.
Call the detail endpoint using the chosen identifier (another Lambda invocation to SWAPI).
Aggregate the results and return a final, formatted answer to your application.

Each action invocation is mediated through the agent runtime and the selected Lambda; responses flow back through Lambda to the agent runtime and then to your application.

Conceptual split: Agent runtime vs. agent configuration

Think of a Bedrock agent as two complementary layers:

Layer	Role
Agent runtime (execution engine)	Receives `InvokeAgent` requests, interprets intent with the model, orchestrates steps, invokes external functions (e.g., Lambda), and returns responses to your app.
Agent configuration (blueprint)	Defines instructions/persona, lists action groups and OpenAPI schemas, selects the foundation model, and specifies allowed knowledge bases and invocation targets.

You define the agent configuration up front (instructions, tools, model). After that, your application simply calls into the agent runtime using the InvokeAgent API and Amazon Bedrock handles the orchestration: tool selection, parameter elicitation, invocation of configured functions/APIs, and final response composition.

Introduction to Gen AI and LLMs

Introduction to Amazon Bedrock

Getting Started With Amazon Bedrock

Foundation Models in Amazon Bedrock

Basic Concepts of Prompt Engineering

Introduction to Text Generation With Amazon Bedrock

How Foundation Models Process Input

Extract Insights Using Prompt Engineering

Working With Different Task Types

Integrating Amazon Bedrock With Other AWS Services

Build a Marketing Email Generation Application

Introduction to Retrieval Augmentation With Bedrock Knowledge Bases

Best Practices and Optimization

Governance, Safety in Responsible AI

Security

Monitoring and Logging

Taking action with Bedrock Agents

Advanced Topics (Optional)

Final Project

Wrap Up

Managed Abstraction With Bedrock Agents Part 2

What you define when creating an agent

Agent instructions and the SWAPI example

What Bedrock handles at runtime

Example user flow: “Tell me about Luke Skywalker.”

Conceptual split: Agent runtime vs. agent configuration

Links and references

Watch Video

​What you define when creating an agent

​Agent instructions and the SWAPI example

​What Bedrock handles at runtime

​Example user flow: “Tell me about Luke Skywalker.”

​Conceptual split: Agent runtime vs. agent configuration

​Links and references

Watch Video

What you define when creating an agent

Agent instructions and the SWAPI example

What Bedrock handles at runtime

Example user flow: “Tell me about Luke Skywalker.”

Conceptual split: Agent runtime vs. agent configuration

Links and references