AWS Builder Center
Where Temporal Fits in an AWS Architecture for Durable AI Agents

Where Temporal Fits in an AWS Architecture for Durable AI Agents

AI agents can execute long-running tasks, call unreliable external services, and wait for human decisions. This article explores how Temporal can provide durable orchestration around agents powered by Amazon Bedrock and when AWS-native alternatives may be a better fit.

AI agents are often demonstrated as simple request-and-response applications: a user sends a prompt, the model calls one or two tools, and a final answer returns a few seconds later. Production systems are rarely that simple.
An agent may need to research information from several sources, wait for a human approval, retry an external API, coordinate specialized agents, or continue a process hours after the original request. At that point, the main challenge is no longer only model intelligence. It is reliable execution.
This is where durable execution platforms such as Temporal become relevant. Temporal does not replace Amazon Bedrock, an agent framework, or Amazon Bedrock AgentCore. It addresses a different concern: preserving the state and progress of a business process when workers restart, services fail, or execution pauses for a long time.
This article presents a conceptual architecture rather than an implementation. The goal is to explain where Temporal can fit, what it contributes, and when an AWS-native option may be simpler.

The reliability problem behind AI agents

Consider a research agent that must complete the following process:
  1. Interpret a user's objective.
  1. Query several internal and external data sources.
  1. Ask specialized agents to analyze the results.
  1. Generate a preliminary report.
  1. Wait for a reviewer to approve or reject it.
  1. Apply the requested corrections.
  1. Publish the final version.
Several failures are possible. An API can time out after the model has already consumed tokens. A worker can restart after completing three steps. The approval might arrive two days later. A repeated request might accidentally create two reports. A deployment could replace the worker while an execution is still active.
Solving these cases manually usually introduces status tables, queues, retry counters, schedulers, idempotency keys, and recovery scripts. Each component is reasonable on its own, but together they can become a second orchestration system hidden inside the application.
Durable execution moves much of that responsibility into an explicit workflow platform.

Temporal's role

Temporal applications separate orchestration from side effects.
  • A Workflow describes the durable sequence of decisions.
  • An Activity performs an operation that can have side effects, such as invoking a model, calling an API, writing to a database, or sending a notification.
  • Signals deliver asynchronous events to a running Workflow, such as a human approval.
  • Queries read the current state without changing it.
  • Updates can change state and return a result synchronously.
Temporal records an ordered Event History for each Workflow Execution. When a Worker fails or restarts, another Worker can replay that history and reconstruct the Workflow's state. Activities can use configurable retry and timeout policies. This allows the business process to continue without treating every infrastructure interruption as a new execution.
The distinction between Workflows and Activities is especially important for generative AI. Model and tool calls are nondeterministic and may create external effects, so they belong in Activities. The Workflow should contain the deterministic coordination logic: which step comes next, what must be retried, when to wait, and how to react to an external event.
Temporal describes this model in its documentation on  Workflow replay ,  Activities and retry behavior , and  Workflow message passing .

A conceptual architecture with AWS

In an AWS-based agent system, the responsibilities could be separated into layers:
Layer
Responsibility
Amazon Bedrock
Provides access to foundation models.
Amazon Bedrock AgentCore
Hosts agents and provides capabilities such as Runtime, Memory, Gateway, Identity, and Observability.
Agent framework
Implements reasoning, tools, state transitions, or multi-agent collaboration.
Temporal Workflow
Coordinates the durable business process around one or more agent executions.
Temporal Activities
Invoke agents, models, APIs, databases, and notification services.
Temporal Service
Stores Event History, schedules work, and preserves Workflow state.
Temporal Workers
Execute Workflow and Activity code in the organization's runtime environment.
A client application could start a Temporal Workflow for a business objective such as “investigate this incident and prepare a remediation plan.” The Workflow could invoke an agent hosted in AgentCore Runtime through an Activity. Additional Activities could retrieve evidence, update a ticket, or request approval. If the process must pause, the Workflow can wait for a Signal instead of keeping a compute process active.
Temporal Workers can connect to Temporal Cloud or a self-hosted Temporal Service. The Workers remain under the application's control and can run in supported infrastructure environments. Temporal provides an official guide for deploying Python Workers to  Amazon EKS using Amazon ECR .
AgentCore remains responsible for running and operating the agent. Its Runtime supports real-time and asynchronous workloads, session isolation, streaming, and long-running execution. Temporal can sit outside that runtime and coordinate a broader process that spans multiple agent sessions, services, approvals, and organizational systems. AWS documents the current long-running behavior in  AgentCore Runtime .
The two layers therefore solve related but different problems:
  • AgentCore Runtime answers, “Where and how should this agent execute?”
  • Temporal answers, “How does this complete business process continue reliably across time and failures?”
Not every application needs both.

Where Temporal can add value

1. Long-running, multi-stage processes

A process may extend beyond a single model invocation or agent session. Examples include an investigation that lasts several days, customer onboarding with timed follow-ups, or a content workflow with multiple reviews. A Temporal Workflow can preserve the process state while individual Activities start and stop as needed.

2. Human-in-the-loop decisions

Agents should not execute every consequential action autonomously. A Workflow can pause before a sensitive operation and resume when an approval Signal arrives. Temporal documents this pattern in its  reliable document approval guide .
This approach makes the approval part of the process history rather than an informal event stored separately from execution.

3. Controlled retries for model and tool calls

External services fail, models can be throttled, and tools may return temporary errors. Activities can define retry policies, timeouts, and non-retryable errors. The important design decision is idempotency: retrying an information lookup is different from retrying a payment or publishing action.
Temporal provides retry machinery, but application developers must still define safe business semantics.

4. Recovery without repeating completed work

If a Worker stops after several successful steps, the Workflow can reconstruct its state from Event History. Completed Activities do not need to be treated as if they never happened. This can prevent unnecessary model calls, duplicated external actions, and wasted tokens.

5. Coordination across multiple agents

Multi-agent systems introduce distributed-systems problems even when each individual agent works correctly. A durable parent Workflow can coordinate specialized agents, track partial results, enforce deadlines, and decide how to proceed when one participant fails.
The agent framework can continue to manage reasoning inside an agent, while Temporal manages the lifecycle of the larger process.

Temporal is not the only durable option on AWS

An architecture decision should include AWS-native services that address similar requirements.

AWS Step Functions

Step Functions Standard Workflows are durable, auditable, and suitable for long-running orchestration. They offer service integrations, visual state machines, retry and catch behavior, and strong alignment with AWS operations and IAM. AWS documents Standard Workflows as appropriate for durable workflows that may run for up to one year in its  workflow type guide .
Step Functions may be the natural choice when a workflow primarily coordinates AWS services, the team values visual state-machine definitions, and minimizing additional platform operations is a priority.

AWS Lambda Durable Functions

Lambda Durable Functions provide code-first durable execution inside the Lambda programming model. They support checkpointing, waits, retries, external events, and executions of up to one year. Wait operations suspend without charging for idle compute. The  AWS Lambda Durable Functions documentation  includes AI workflows and human approvals among its use cases.
This option can be attractive when the application already fits Lambda's operational and packaging model and the team wants code-first orchestration without operating a separate Worker fleet.

Amazon Bedrock AgentCore Runtime

AgentCore Runtime is purpose-built to deploy and operate agents and tools. It supports asynchronous processing and long-running agent workloads, but its primary abstraction is an agent runtime rather than a general business-process Workflow. For some applications, its session and asynchronous capabilities may already provide everything required. Adding another orchestration layer would then create unnecessary complexity.

A practical decision framework

Temporal may deserve consideration when several of the following are true:
  • The business process spans many services or organizational boundaries.
  • Executions must survive Worker restarts and deployments.
  • Human interactions can pause a process for an unpredictable period.
  • The team prefers code-first orchestration in a general-purpose language.
  • Workflow portability or control over Worker infrastructure is important.
  • The process needs rich message passing while it remains active.
  • Orchestration extends beyond the lifecycle of one agent execution.
An AWS-native alternative may be simpler when:
  • Most steps are direct AWS service integrations.
  • The team already operates Step Functions extensively.
  • Visual workflow definitions are beneficial to operators.
  • The workload fits naturally inside Lambda Durable Functions.
  • AgentCore's existing asynchronous and session capabilities cover the requirement.
  • Introducing and operating an additional platform would cost more than the complexity it removes.
This is not a universal feature comparison. The right choice depends on execution duration, programming model, operational ownership, compliance requirements, existing skills, and the services being coordinated.

Trade-offs to consider

Temporal's durability does not eliminate architecture work. It changes where that work happens.
Workflow code must remain deterministic so it can replay safely. Activities need appropriate timeouts and idempotency. Teams must manage Worker deployments and version long-running Workflow code carefully. They must also choose between Temporal Cloud and self-hosting; self-hosting adds responsibility for the Temporal Service and its persistence layer.
Data governance also matters. Prompts, model responses, tool results, and business identifiers can contain sensitive information. Teams should decide what belongs in Temporal payloads and Event History, what should be encrypted with a payload codec, and what should remain in an application data store. Identifiers visible in operational interfaces should not contain secrets or personal information.
Finally, every extra control plane increases cost and cognitive load. Temporal is valuable when durable coordination is a central requirement, not simply because an application contains an AI model.

Conclusion

Reliable AI systems require more than reliable model inference. They need a way to preserve progress, handle failures, wait for external decisions, and coordinate work across services.
Amazon Bedrock and AgentCore can provide the model and agent execution layers. Temporal can provide durable orchestration around a broader business process. Step Functions and Lambda Durable Functions offer AWS-native approaches that may be more appropriate for many workloads.
The most useful question is therefore not “Is Temporal better for AI agents?” It is “Which layer owns durability in this architecture, and what is the simplest platform that can meet that responsibility?”
Making that boundary explicit helps teams avoid two common mistakes: expecting an agent framework to become a workflow engine, or adding a workflow platform where a managed AWS capability already solves the problem.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article