Transitioning to Temporal for durable microservice orchestration

Temporal replaces scheduling with durable execution

Temporal is a durable execution platform for long-running, stateful workflows written in code. This distinguishes it from Apache Airflow, which functions as a batch workflow scheduler for data-engineering pipelines. While Airflow handles scheduled ETL tasks and reporting through Python DAGs, Temporal manages microservice coordination, business processes, and agent pipelines. Camunda serves a different purpose by coordinating AI agents, people, and systems through BPMN and DMN models for regulated business processes. If your team needs to coordinate complex transactions across multiple services like order placement or subscription billing, Temporal manages the logic. Temporal uses a workflow-as-code model where developers write workflows and activities in languages including Go, Java, Python, TypeScript, .NET, Ruby, and PHP.

Maxim Fateev and Samar Abbas created the Seattle-based platform in 2019 after they developed the Cadence orchestration engine at Uber. The company recently secured a $146 million growth round led by Tiger Global, which brought its post-money valuation to $1.72 billion. This follows a $75 million Series B extension in February 2023. Companies like Netflix, Snap, Comcast, and Stripe utilize the platform to manage disparate services in the cloud. Temporal currently has 183,000 active users on its open-source platform and 2,500 customers via its managed service. Unlike Airflow, where tasks remain stateless between runs, Temporal preserves the internal state of a program through its event history.

Workflows survive process failures

Temporal maintains an event history for every running workflow to rebuild in-process state after a worker crashes or restarts. This event history is an ordered, timestamped record of every workflow step, every activity invocation and result, every signal received, and every timer fired. When a worker dies, the Temporal service replays this history on a new worker to restore local variables and the exact position within the code. This replay mechanism ensures that workflows survive process deaths and outages. You can use signals for event-driven coordination, which allow external events like webhooks or human approvals to enter a running workflow.

While documentation often mentions reliability, Temporal provides at-least-once execution. This means an activity may execute more than once, so developers must design idempotent activities. The Temporal service is composed of the frontend, history, matching, and worker services, plus persistence and a visibility store. Workers poll task queues to execute the work dispatched by the service. Worker versioning reached general availability in March 2026.

Because Temporal persists every argument passed into a workflow or activity to the history, passing a 30 KB conversation context through a 20-step agent loop can quickly consume a significant portion of your event budget. Developers often handle these large payloads by using a "claim check" pattern to offload data to external storage. For teams that require a different approach, Restate provides a single Rust binary with lower ceremony, while Hatchet uses a Postgres-backed architecture to provide durable tasks.

Building reliable AI agent pipelines

Temporal supports agentic AI workloads through its first-party integration with the OpenAI Agents SDK, which released in April 2026. This integration turns Temporal Activities into OpenAI-compatible tool schemas using an activity_as_toolhelper, which makes the agent’s tool calls durable. The entire agent loop is a Workflow, which provides a massive advantage for teams needing to execute long workflows that require high reliability across many steps, such as multi-step inference or tool-calling agents. Companies like Nvidia already use Temporal to manage microservices, and this new integration extends that capability to AI agents.

However, the history-as-state model struggles with large, frequent LLM payloads because every argument passed into a workflow or activity persists to the history. This reality forces engineers to build custom logic to manage the massive data flow between the model and the orchestration layer. If a single conversation context reaches 2 MB, it can consume a significant portion of the allowed event history. How do you manage the massive context transfers without hitting the 50 MB history cap?