# Serverless Workers on Amazon Bedrock AgentCore Runtime

> For the complete documentation index, see [llms.txt](https://docs.temporal.io/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> **Pre-release**
> Amazon Bedrock AgentCore Runtime support is in Pre-release, and its APIs may change in backwards-incompatible ways.

This page covers how Serverless Workers run on Amazon Bedrock AgentCore Runtime, including Worker Versioning and the
Runtime session lifecycle.

On AgentCore Runtime, a Serverless Worker is a standard long-running Temporal Worker that runs inside an AgentCore
Runtime session. When the [Worker Controller Instance (WCI)](/serverless-workers#worker-controller-instance) needs
capacity, it invokes an AgentCore Runtime endpoint. The Runtime starts a Worker, which connects to the Temporal Service
and polls its Task Queue.

AgentCore Runtime uses the same event-driven autoscaling model as AWS Lambda. The WCI invokes individual Runtime
sessions when it needs more capacity; it does not manage a target-sized pool of Runtime sessions.

## Worker Versioning 

Serverless Workers require [Worker Versioning](/worker-versioning). Associate each Worker Deployment Version with a
named AgentCore Runtime endpoint that points to one AgentCore Runtime version.

AgentCore creates an immutable Runtime version when you create or update a Runtime. A named endpoint has a stable ARN
and points to a chosen Runtime version. Configure the endpoint ARN as the compute provider for the corresponding Worker
Deployment Version:

```bash
temporal worker deployment create-version \
    --deployment-name my-worker \
    --build-id v1 \
    --aws-agentcore-endpoint-arn <AGENTCORE_RUNTIME_ENDPOINT_ARN> \
    --aws-agentcore-assume-role-arn <INVOKE_ROLE_ARN> \
    --aws-agentcore-assume-role-external-id <EXTERNAL_ID>
```

Use one named endpoint for each Worker Deployment Version. For example, point an endpoint named `temporal-v1` at
AgentCore Runtime version `1` and use its ARN for Temporal Worker Deployment Version `my-worker/v1`.

When you deploy new Worker code, AgentCore creates a new Runtime version. Create another endpoint that points to that
new Runtime version and configure it on a new Worker Deployment Version. Keep the older endpoint while Pinned
Workflows can still need the older Worker code.

> **⚠️ Caution:**
>
> Do not configure a live Worker Deployment Version with AgentCore's `DEFAULT` endpoint. That endpoint moves to the
> latest Runtime version whenever you update the Runtime. Updating code behind a Worker Deployment Version can cause
> non-determinism errors for in-flight Workflows, including Pinned Workflows.
>

For details about AgentCore Runtime versions and endpoints, see [AgentCore Runtime versioning and
endpoints](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agent-runtime-versioning.html).

## Lifecycle 

An AgentCore Runtime session is only the compute that runs a Worker. It can end because of its idle timeout or maximum
lifetime. A later Task for the same Workflow can run on another Worker in another Runtime session. Keep state that the
Workflow needs in the Workflow or another durable store, not only in the Runtime session.

Unlike an AWS Lambda Worker, an AgentCore Worker does not run within a fixed Lambda invocation deadline. Your Runtime
handler starts the Worker as background work, and the Worker continues polling until it drains or AgentCore terminates
the Runtime session.

AgentCore applies lifecycle settings to each microVM Runtime session:

- **Idle Runtime session timeout**: Ends an idle session. The default is 15 minutes.
- **Maximum lifetime**: Ends a microVM session after a fixed lifetime. The default and maximum is 8 hours.

Set the Worker’s own idle and graceful-shutdown policy so it stops polling and drains in-flight Tasks before its Runtime
session is no longer needed. The AgentCore maximum lifetime remains a hard termination boundary. Configure Activity
timeouts and, for long-running Activities, [Activity Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat)
so a retry can recover after a Worker is interrupted.

For the lifecycle setting ranges and defaults, see [Configure Amazon Bedrock AgentCore lifecycle
settings](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-lifecycle-settings.html).