Skip to main content
This lesson contrasts calling a foundation model directly with invoking it through a Bedrock Agent, and explains how your application interacts with the Bedrock Agent Runtime and external tooling. When your application calls a foundation model directly, it uses the Bedrock Runtime API endpoint and is responsible for orchestration: deciding when to call external APIs or tools, parsing model responses, performing retries and error handling, and combining results. By contrast, when you call an agent you point your SDK client to the Bedrock Agent Runtime endpoint and use the InvokeAgent API method (rather than InvokeModel or Converse). The agent orchestration takes a high-level request and decides which tools, models, or knowledge bases to consult.
A presentation slide titled "Workflow: How Your Application Interacts With a Bedrock Agent" showing a comparison table between "Without an Agent (Direct Model)" and "With a Bedrock Agent," listing aspects like the API called, how the app invokes it, and who decides when to call APIs/tools. The design uses colored header bars and a dark blue background.
Example: creating a client that targets the Bedrock Agent Runtime and calling InvokeAgent Key differences to note in the example below:
  • The client is created for the Bedrock Agent Runtime service (not the standard Bedrock Runtime).
  • You must provide agentId and agentAliasId that reference an existing Bedrock agent (the agent configuration contains the foundation model, action groups, instructions, and optional knowledge bases).
  • Provide a sessionId to scope a conversation. The format is defined by your application (numeric, alphanumeric, or any convention you choose) and controls conversation separation and continuity.
  • Responses from InvokeAgent are streamed in chunks; the code below shows assembling a completion from those chunks.
Session ID guidance: choose a sessionId strategy that fits your application. You might use one session per end user, or separate sessions for different tasks or contexts (for example, a support conversation vs. an order request). The sessionId format is up to you.
In the example above the prompt asks “Who is Luke Skywalker?” If the agent is configured with an action group that maps to an external data source such as the Star Wars API (SWAPI), the agent can decide to call that tool to fetch the answer rather than relying exclusively on the foundation model’s internal knowledge. How action groups map to external tooling
  • Your application calls the Bedrock Agent Runtime and specifies an agent (agentId).
  • The agent configuration maps to a chosen foundation model and one or more action groups.
  • Action groups contain discrete actions (for example: getOrder, updateOrder, updateInventory).
  • Each action can be implemented as an AWS Lambda function; Lambda acts as the “glue” to external APIs, databases, and services.
Benefits of using Lambda as the bridge:
  • Centralizes retry logic, pagination, backoff strategies, and error handling.
  • Encapsulates API clients and secrets management.
  • Enables complex business logic, filtering, and orchestration before returning results to the agent.
The agent orchestrator invokes the appropriate Lambda actions when needed, receives their responses, and composes a final response back to your application.
A labeled workflow diagram showing user requests flowing from "User" and "Your App" into a Bedrock Agent runtime/orchestrator that talks to a foundation model and action groups (e.g., getOrder, updateOrder, updateInventory), which invoke AWS Lambda to call external APIs and data sources.
Agent abstraction: instead of your application orchestrating every model call and external API call, you send a goal-oriented request and the agent selects tools, action groups, and knowledge sources. Lambda functions make those external integrations reliable, testable, and secure.
Links and further reading:

Watch Video