By Q2 2026, every agent architect on the planet has a story about an agent that disappeared at the 15-minute Lambda timeout. The research agent that was halfway through synthesizing a 200-page report. The migration agent that had moved 14,000 of 80,000 records before vanishing into the void. The scheduled enrichment job that ran every Sunday and silently produced wrong outputs every time a downstream API took longer than 14 minutes and 59 seconds. The fix is durable execution: a category of infrastructure that gives an agent's process resumable state, exactly-once side-effects, and replayable history — so it can run for hours, days, or weeks without losing its mind. This lesson walks the three reliability primitives every durable executor must provide, then compares the three production-grade options dominating 2026: Temporal (code-first, polyglot, the original), Inngest (serverless event-driven, the developer-experience leader), and LangGraph Platform (the LangChain-stack-native option). The 15-minute Lambda timeout has a name now: the "agent that disappears at the timeout" failure mode. Architects in 2026 know to avoid it.

The Agent That Disappears at the Timeout

The canonical 2026 cautionary tale, anonymized but stitched together from incidents we have seen at multiple organizations during 2025:

A 70-person SaaS company built a research agent in March 2025. The agent's job: when a sales rep flagged a prospect, the agent would spend 20-30 minutes researching the prospect, reading their public filings, checking news mentions, summarizing competitive positioning, and producing a 4-6 page briefing document. The team built the agent as a single AWS Lambda function triggered by a Slack workflow. They tested with three prospects. It worked.

The agent went into production in May. Within the first week, the team noticed that briefings were sometimes incomplete. Sometimes the agent finished cleanly; sometimes the briefing showed up with only the first three sections filled out and the last two sections empty. The team's initial theory: prompt issues. The team's second theory: an upstream API was rate-limiting. The team's third theory, after enabling Lambda metrics: the function was being killed at the 15-minute Lambda execution timeout.

Lambda has a hard 15-minute execution ceiling. AWS will not run a Lambda function for longer than 15 minutes. When the timer hits, the runtime is terminated. The function returns nothing; the agent's in-progress reasoning loop is gone; the partial outputs that had been streaming to memory are gone; the prospect briefing is half-written and the team has no way to resume.

The team's first attempted fix: chunk the agent's work into shorter Lambda invocations, with a coordinator function that orchestrates. It worked for a month, then broke when one chunk's research grew to 18 minutes and got killed mid-chunk; the coordinator had no way to resume that chunk, only to retry from scratch, paying for the redo.

The team's second attempted fix: move the agent to ECS Fargate, where the timeout is effectively unlimited. The agent runs to completion, mostly. Then a Fargate task dies for a different reason — a node replacement, a deploy, an OOM kill, a 5xx from one of the upstream APIs that the agent didn't gracefully handle. Each failure restarts the agent from scratch. Each restart costs $4-7 in LLM tokens to re-do work that had been done. The team's monthly research-agent LLM bill quadrupled from June to October 2025 — not because they were doing more work, but because they were re-doing work after every restart.

The team migrated to a durable executor (Temporal, in their case) in late 2025. Re-do work went to near zero. Their monthly LLM bill for the research agent dropped 65% in the first month after the migration. The Slack workflow stayed the same. The agent's logic stayed the same. Only the execution substrate changed.

The 2026 failure mode is named: "agent that disappears at the timeout." It is the predictable consequence of running long-horizon agents on infrastructure built for short request-response patterns. Lambda, cron-scheduled jobs, and naive ECS tasks all fail this way. Durable executors are the response.

The Three Reliability Primitives

Any durable executor worth running in 2026 production must provide three primitives. If a tool doesn't have all three, it isn't durable execution; it's wishful execution with extra steps.

1. Resumable state

The agent's progress — every decision made, every tool result observed, every partial output produced — must survive process crashes, host failures, deploys, and rolling restarts. If the host running the agent dies, another host must be able to pick up exactly where the dead one left off. This is the difference between a workflow that costs $4-7 to retry and a workflow that picks up at step 47 of 80 for free.

Mechanism: the executor persists state at well-defined checkpoint boundaries (typically after each completed activity or step). On resume, the executor replays history up to the last checkpoint, restoring local variables and call stack, and continues from there. The agent's code is written as if state were ambient; the executor makes that real.

2. Exactly-once side-effects

An agent that retries its work must not re-do its external work. If the agent has already sent the customer email, the retry must not send a second one. If the agent has already written a refund to Stripe, the retry must not write a duplicate. If the agent has already inserted a row into the warehouse, the retry must not insert a duplicate row.

Mechanism: every external side-effect (LLM call, tool call, API call, database write) is wrapped in an idempotency-keyed activity. The executor records "activity X with idempotency key Y produced result Z." On retry, before re-executing the activity, the executor checks whether activity X with key Y has already produced a recorded result; if so, it returns the recorded result instead of re-executing. The semantics are exactly-once from the application's perspective, even when the underlying API has at-least-once semantics or the agent's process crashed mid-call.

3. Replayable history

Every step the agent took, every input it observed, every output it produced — all are recorded in a durable event log. The history is replayable: you can take the log of a workflow that ran in March and re-execute it deterministically against current code, current models, current tools, and see how the new version would have behaved. The history is auditable: regulators, security teams, and post-incident investigators can reconstruct what happened, in what order, with what evidence, weeks or months later.

Mechanism: append-only event log per workflow, with strong ordering guarantees. Logs are typically retained for 30-90 days online (queryable for debugging) and longer in archive (for compliance and forensics). The agent's runtime is deterministic relative to the log — same log, same code, same result — which is what makes replay work.

These three primitives are not three features you can pick from a list. They are interdependent. Resumable state is meaningless without exactly-once side-effects (you'd re-do external work on every resume). Exactly-once side-effects are weak without replayable history (you can't debug or audit). Replayable history is impotent without resumable state (you can read it, but you can't act on it). The three together — the trinity of durable execution — are what makes long-running agents production-viable.

Temporal: The Code-First Original

Temporal is the spiritual descendant of AWS Simple Workflow Service, started in 2019 by the team that built Cadence at Uber. By 2026 it is the most mature, most widely-deployed durable execution platform — and the choice of teams that want a code-first, polyglot, "do the durable thing in the language we already use" experience.

The Temporal model

You write two kinds of code: workflows and activities. A workflow is the orchestration logic — your agent's high-level reasoning loop, the sequencing of steps, the conditionals, the retries, the timeouts. Workflows must be deterministic; the Temporal runtime replays workflow code from history during recovery, so non-deterministic operations (random numbers, system clock, direct API calls) are forbidden in workflow code. Instead, all non-determinism is delegated to activities.

An activity is a side-effectful piece of work — call an LLM, invoke a tool, write to a database, send an email. Activities run on workers and produce results that are recorded in the workflow's event log. From the workflow's perspective, every activity is exactly-once: the workflow asks for the activity to run, Temporal handles retries on the worker side, and when the activity completes, the result is recorded and returned to the workflow.

For agent workflows, this maps cleanly: the agent's reasoning loop is a workflow (deterministic orchestration), and every model call, tool call, and side-effect is an activity (the actual work). Temporal handles state persistence, retries, replay, and audit out of the box.

Polyglot SDKs

Temporal SDKs in 2026: Go (the original), Java, Python, TypeScript, .NET, PHP, Ruby. Python and TypeScript are the dominant SDKs for agent workloads. The Python SDK has first-class support for async/await, integrates cleanly with LangChain, LlamaIndex, and the major model SDKs, and has a growing ecosystem of agent-specific patterns.

Operational footprint

Temporal has two deployment modes. Temporal Cloud, the managed offering, hosts the durable backend (the event store, the orchestrator) and you bring workers; this is the default for teams that don't want to operate distributed systems. Self-hosted Temporal runs on your own infrastructure (Kubernetes, typically) with Cassandra or PostgreSQL as the backing store; this is the choice for regulated industries, on-prem requirements, or teams that have already invested in distributed-systems operations.

When Temporal is the right pick

• Polyglot environments (you have Go, Python, and Java services that all need to participate in the same workflows).
• Code-first teams that want full programmatic control over the workflow logic, with the language they already use.
• Highly stateful, long-running, multi-step workflows where the deterministic-workflow model maps cleanly to your domain.
• Regulatory environments where self-hosting and on-prem are required.
• Teams that have already invested in distributed-systems operations or are willing to use Temporal Cloud.

Inngest: The Serverless Event-Driven Developer Experience Leader

Inngest, founded in 2021, emerged as the developer-experience-led durable execution platform for the serverless and event-driven ecosystem. Where Temporal asks you to think in workflows and activities, Inngest asks you to think in functions and events. Where Temporal favors long-running stateful agents, Inngest excels at workflows triggered by external events with rich step-level retries and a beautiful local-development experience.

The Inngest model

You define functions that respond to events. Each function is composed of steps. Each step is durable: its result is persisted, it can be retried independently, and the function can resume from the last completed step on failure. Steps can call APIs, invoke tools, run model calls, sleep for arbitrary durations (hours, days, weeks), or wait for other events. The function looks like a plain async TypeScript or Python function with step.run(), step.sleep(), and step.waitForEvent() calls; the SDK handles durability.

Event-driven by design

Inngest's first-class concept is the event. Functions trigger on events; functions emit events; multiple functions can subscribe to the same event with fan-out. This maps cleanly to agent architectures where work is triggered by external actions (a customer message, a webhook from a tool, a scheduled trigger) and where you want fan-out (one event triggers multiple specialist agents).

Local development

Inngest's Dev Server is the standout feature of 2026 developer-experience comparisons. Run npx inngest-cli dev locally; get a UI for triggering events, replaying functions, inspecting state, and debugging step-by-step. The local environment is bit-for-bit compatible with production. The developer-experience gap between writing a durable workflow and writing a regular async function is the smallest in the category.

Serverless-native

Inngest functions deploy as HTTP endpoints — to Vercel, Cloudflare Workers, AWS Lambda, your own Kubernetes, anywhere that can run an HTTP server. The Inngest platform orchestrates: it knows when to invoke your function, what state to pass it, when to retry. Your function code runs serverlessly; the durability lives in the Inngest backend. This is a sharp contrast with Temporal's worker model, where you run long-lived worker processes.

When Inngest is the right pick

• Serverless deployments (Vercel, Cloudflare Workers, Lambda) where you can't run long-lived workers.
• TypeScript-first stacks; the TS SDK is the most polished.
• Event-driven architectures where many agents respond to many events; fan-out is first-class.
• Teams that prioritize developer experience and want the lowest-friction path from "I want a durable workflow" to "I have a durable workflow."
• Moderate complexity workflows; very large long-running orchestrations are possible but less natural than Temporal.

LangGraph Platform: The LangChain-Stack-Native Option

LangGraph Platform, GA mid-2024 and rapidly maturing through 2025-2026, is the durable execution layer purpose-built for agent workflows expressed as state graphs. If your team is already on the LangChain stack — LangChain for the agent logic, LangGraph for the state machine, LangSmith for tracing — LangGraph Platform is the path of least resistance to durability.

The LangGraph model

You define your agent as a state graph: nodes (steps the agent can take) and edges (transitions between steps, often determined by the agent's reasoning). The state graph is explicit; you can see, in code, every state your agent can be in and every transition between them. LangGraph runs the graph; LangGraph Platform makes the runs durable.

State graphs are the natural representation for agents that have well-defined control flow with a few branching points: a tool-use loop with retries, a multi-step pipeline with conditional branches, a planner-executor pattern with a step-back. They are less natural for free-form reasoning agents that can take arbitrary actions in arbitrary orders — though even those can be expressed as a graph with a single "decide what to do next" node.

First-class agent primitives

LangGraph Platform ships features that other durable executors require you to build: built-in checkpointing for agent state, human-in-the-loop interruption (the workflow pauses and waits for a human to confirm or modify state), thread-based persistent memory for conversational agents, native support for streaming partial results, and tight integration with LangSmith for tracing.

Cloud and self-hosted

LangGraph Platform Cloud is the managed offering; you point your LangGraph app at the cloud endpoint and durability comes along. Self-hosted is available for teams that need it, with a PostgreSQL backing store.

When LangGraph Platform is the right pick

• You are already on the LangChain stack and your agent is already expressed as a LangGraph state graph.
• Conversational agents with persistent thread state and human-in-the-loop interruptions.
• Teams that want agent-specific primitives (state graphs, interruptions, checkpoints) built in rather than re-implementing them on a general workflow engine.
• Tight LangSmith integration is a hard requirement.
• The agent's control flow is well-modeled as a state graph — not pure free-form reasoning.

How to Pick Between the Three

The choice is rarely close once you align on three constraints: your stack, your deployment model, and your workflow shape.

Stack alignment

If you are polyglot (Go, Java, Python in the same workflow), Temporal is the only option that handles this natively. If you are TypeScript-first with serverless deployments (Vercel, Cloudflare Workers), Inngest is the default. If you are already on LangChain and have invested in LangSmith, LangGraph Platform is the obvious continuation.

Deployment model

If you run long-lived workers (Kubernetes deployments, ECS services, bare metal), all three work; Temporal's worker model is the most mature. If you deploy serverless (Lambda, Vercel, Cloudflare Workers), Inngest's HTTP-endpoint model is purpose-built for this; Temporal requires long-lived workers, which fits awkwardly with serverless. LangGraph Platform supports both via its cloud and self-host modes.

Workflow shape

If your workflows are long-running, highly stateful, multi-step orchestrations with deep determinism requirements (financial transactions, multi-system migrations, regulated processes), Temporal's workflow-and-activity model is the strongest fit. If your workflows are event-driven, fan-out heavy, with moderate complexity and many concurrent runs, Inngest's event-and-step model is the best fit. If your workflows are agent state machines with human-in-the-loop, streaming, and thread state, LangGraph Platform is the most agent-native.

What we have observed in 2026 teams making this choice: the alignment is usually clear. The teams that struggle picked a tool that didn't align with all three constraints and are paying the integration tax. Pick for stack + deployment + workflow shape, and the rest follows.

Agent-Specific Durable Execution Patterns

Four patterns we've seen successful 2026 agent teams adopt across all three platforms:

1. Idempotency keys on every model call and tool call

Every LLM call and every tool invocation gets an idempotency key derived deterministically from (workflow ID, step ID, input hash). The activity layer checks the key before executing and returns the cached result on retry. This makes restarts free at the work-already-done layer.

2. Checkpoint after every meaningful agent decision

Don't just checkpoint at activity boundaries; checkpoint after every decision the agent makes. If the agent decides "I will call tool X next," checkpoint that decision before calling tool X. On resume, you don't re-make the decision (which might come out differently with a non-deterministic LLM); you act on the recorded decision.

3. Bound the retry budget per step and per workflow

An agent that retries unbounded will retry forever, accumulating cost. Set a retry budget per step (typically 3-5 retries with exponential backoff) and per workflow (typically total runtime under 24 hours, total LLM tokens under a budget). When budgets are exceeded, escalate to a human, do not retry silently.

4. Human-in-the-loop for high-stakes branches

For agent decisions with material impact (financial transactions over a threshold, customer-facing communications, irreversible operations), insert an explicit human-in-the-loop interrupt. Temporal supports this with signals; Inngest with step.waitForEvent; LangGraph Platform with native interruptions. The agent pauses, waits for human input, and resumes. Without durability, this is impractical; with it, it's natural.

Three Real 2026 Deployment Shapes

A 120-person B2B SaaS, Temporal. A research agent that produces detailed prospect briefings; runs 25-40 minutes per prospect; ten to thirty prospects per day. Migrated from Lambda (where they were losing 15-25% of runs to the timeout) to Temporal in November 2025. Re-do work went from 18% of runs to under 1%. Monthly LLM bill for the agent dropped from $11,200 to $4,100 — same prospect volume, far less duplicated work. Temporal Cloud, Python SDK, six workers on Kubernetes.

A 30-person YC-startup B2C, Inngest. A multi-step user-onboarding agent that runs over 48-72 hours (welcome message, day-1 check-in, day-3 nudge, day-7 follow-up). The agent's logic lives in TypeScript on Vercel. Inngest handles the scheduling, the durability, the fan-out (different user cohorts get different sub-flows). Total durable-execution code: about 800 lines for the entire system. Inngest Dev Server is the team's most-used development tool — they ship multiple times per week with confidence because they can replay any failed workflow locally.

A 200-person regulated-industries provider, LangGraph Platform. A compliance review agent that processes loan applications through a multi-step workflow (eligibility check, KYC, fraud screening, manual underwriting review for edge cases, decision). The agent is expressed as a LangGraph state graph with explicit human-in-the-loop branches for any application that triggers manual review. LangGraph Platform handles the durability, the thread state, the interruption-resume cycle. LangSmith provides the audit trail regulators ask for. Average workflow runtime: 8 minutes for clean approvals, 4-12 hours for human-in-the-loop branches. Zero "agent disappeared at the timeout" incidents since the LangGraph Platform migration.

What to Avoid

• Running long agents on Lambda or short-timeout serverless. The 15-minute Lambda timeout is a hard ceiling. If your agent can take longer than that, you must use durable execution or pay the re-do tax.
• Cron-scheduled long-running scripts. A cron-scheduled script has no durability. If it dies mid-run, you get an alert (maybe) and lose all in-progress work.
• Naive ECS tasks or Kubernetes pods. Long-running pods die at the worst possible moment: during a deploy, during a node replacement, during an OOM event. Without checkpoints, every death is an expensive restart.
• Building your own durable executor. The trinity of resumable state, exactly-once side-effects, replayable history is hard to get right. Temporal, Inngest, and LangGraph Platform have absorbed the learnings of teams who tried; you should benefit from them, not repeat their bugs.
• Picking the wrong tool for your stack. Running Inngest from a polyglot Java/Go/Python environment is awkward; running Temporal from a serverless-only TypeScript stack is awkward; running LangGraph Platform when you're not on LangChain is awkward. Align tool to stack.
• Skipping idempotency keys. Every external side-effect needs an idempotency key. Without it, retries duplicate work — duplicate emails, duplicate payments, duplicate database writes. The durable executor cannot save you from the lack of idempotency keys; you have to provide them.
• Unbounded retries. "We'll retry until it works" becomes "we'll retry until the LLM bill bankrupts us." Bound retries per step and per workflow; escalate on budget exhaustion.
• Forgetting human-in-the-loop for high-stakes branches. Some decisions should not be automated end-to-end. Durable execution makes human-in-the-loop natural; use it where the stakes warrant.

The Five-Step Migration Routine

The routine we walk teams through to migrate an existing long-running agent off Lambda or cron and onto a durable executor. Two to six weeks of focused work depending on agent complexity.

1. Pick the executor. Apply the stack-deployment-workflow alignment test. Pick one. Do not run a bake-off — the cost of a six-week bake-off exceeds the cost of picking the second-best option and shipping.
2. Inventory the agent's side-effects. Every LLM call, every tool invocation, every API call, every database write. For each, derive a deterministic idempotency key and decide what the retry behavior should be (retry, fail-fast, escalate).
3. Re-express the agent's logic in the executor's primitives. Workflow + activities for Temporal. Functions + events + steps for Inngest. State graph + nodes for LangGraph Platform. Keep the agent's reasoning logic; change the orchestration substrate.
4. Add observability. Wire the durable executor's tracing into your existing trace store. Confirm that every workflow run is visible, every retry is logged, every human-in-the-loop branch is tracked.
5. Run shadow mode, then cut over. Run the new durable version in shadow alongside the old version for 1-2 weeks; compare outputs; verify the new version is at least as good. Cut over. Keep the old version as a fallback for one more week. Remove.

Key Takeaways

• The 2026 failure mode is named: "agent that disappears at the timeout." Lambda's 15-minute ceiling and analogous limits in cron and naive ECS tasks kill long-running agents mid-run, losing all in-progress work and forcing expensive restarts.
• Three reliability primitives every durable executor must provide: resumable state (survives crashes), exactly-once side-effects (idempotency-keyed activities), and replayable history (auditable event log). The three together are the trinity; none alone is enough.
• Temporal is the code-first, polyglot original. Workflows plus activities. Python, TypeScript, Go, Java, and more SDKs. Cloud or self-hosted. Best for stateful long-running orchestrations and polyglot environments.
• Inngest is the serverless event-driven developer-experience leader. Functions plus events plus steps. TypeScript-first. HTTP-endpoint deployment compatible with Vercel, Cloudflare Workers, Lambda. The Dev Server is the standout developer-experience feature of 2026.
• LangGraph Platform is the LangChain-stack-native option. State graphs plus nodes. Built-in checkpoints, human-in-the-loop interruptions, thread state, LangSmith integration. The path of least resistance for teams already on LangChain.
• The choice is rarely close once you apply the alignment test: stack, deployment model, workflow shape. Pick the one that aligns on all three; the rest follows.
• Agent-specific patterns to adopt regardless of executor: idempotency keys on every model and tool call; checkpoint after every meaningful agent decision; bound retry budgets per step and per workflow; human-in-the-loop for high-stakes branches.
• The 2025-2026 migration story is repeatable: a 120-person SaaS dropped LLM bill 65% migrating off Lambda. A 30-person startup shipped multi-day onboarding agents in TypeScript without long-lived workers. A 200-person regulated provider got their HIPAA-style audit trail from LangSmith plus LangGraph Platform.
• What to avoid: long agents on Lambda, cron-scheduled long-running scripts, naive ECS or Kubernetes pods without checkpoints, building your own durable executor, mismatching tool to stack, skipping idempotency keys, unbounded retries, forgetting human-in-the-loop where stakes warrant.
• The five-step migration routine: pick the executor, inventory side-effects, re-express in the executor's primitives, add observability, run shadow mode then cut over. Two to six weeks of focused work.