> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bedrock Agents Introduction Part 2
> Explains differences between calling foundation models directly and using Bedrock Agents, covering orchestration, InvokeAgent usage, session scoping, action groups, and Lambda integrations.
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.
| Aspect | Direct Model (No Agent) | Bedrock Agent |
| - | -: | - |
| API Endpoint | Bedrock Runtime API | Bedrock Agent Runtime API |
| API Method | `InvokeModel` / `Converse` | `InvokeAgent` |
| Orchestration | Your application must orchestrate model calls and external API usage | Agent runtime decides which tools or action groups to call |
| Session scoping | Implement in your app | Pass a `sessionId` to the agent to scope conversation continuity |
| Use case | Fine-grained control over calls and handling | High-level goal-driven requests; agent chooses tooling and flow |
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.
```python theme={null}
import boto3
# Create a client for the agent runtime (NOT the regular bedrock-runtime)
client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
response = client.invoke_agent(
agentId="YOUR_AGENT_ID",
agentAliasId="YOUR_AGENT_ALIAS_ID",
sessionId="user-123", # application-defined identifier used to maintain conversation scope
inputText="Who is Luke Skywalker?"
)
# The response is streamed in chunks
completion = ""
for event in response["completion"]:
if "chunk" in event:
completion += event["chunk"]["bytes"].decode()
print(completion)
```
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)](https://swapi.dev/), 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.
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:
* Amazon Bedrock documentation: [https://docs.aws.amazon.com/bedrock/](https://docs.aws.amazon.com/bedrock/)
* AWS Lambda: [https://docs.aws.amazon.com/lambda/](https://docs.aws.amazon.com/lambda/)
* SWAPI (example external data source): [https://swapi.dev/](https://swapi.dev/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.