Durable execution is becoming the reliability layer for AI agents
An agent that can reason for twenty minutes but loses its place after a restart is not a production system. Durable execution turns long-running agent work into checkpointed, resumable and auditable workflows that survive failures without repeating completed side effects.
What is happening?
Durable execution means the agent’s progress is written to reliable storage at controlled boundaries. When a worker crashes, a deployment replaces a container or an API is temporarily unavailable, another worker can reconstruct the run and continue from the last valid transition. The difficult part is not saving text. It is deciding which events are authoritative, which model or tool calls may be replayed, how to prevent duplicate effects, how approvals remain bound to the exact proposed action, and how workflow code changes without breaking old runs. A durable agent therefore looks less like an endless while-loop and more like a versioned business process: deterministic orchestration around nondeterministic model calls, idempotent activities around external systems, explicit waits for humans or events, and postcondition checks before the run declares success.
Why this trend is moving
- 01Long-running agents increasingly span minutes, hours or days, making process restarts, deploys, rate limits and human waits normal rather than exceptional.
- 02Tool calls can create irreversible effects, so replaying a model step after a timeout may duplicate an email, order, payment, deletion or infrastructure change.
- 03OpenAI, Microsoft, Google, AWS, Cloudflare, LangGraph, Temporal, Dapr and Restate now publish first-party durable-agent or durable-workflow guidance.
- 04Agent evaluation is shifting from single-response quality toward complete task trajectories, recovery behavior and verified final state.
- 05Human-in-the-loop approval requires a workflow to pause without holding a worker or losing the exact proposal being approved.
- 06Multi-agent systems need durable handoffs, bounded retries and explicit ownership when one worker or specialist fails.
- 07Production teams are discovering that chat history is not execution state: it cannot reliably prove which side effects completed or which compensations remain.
What this means in practice
- Conversation memory and durable execution should be separate: one supplies context, while the other records progress, effects and recovery boundaries.
- Model calls, tool calls and external mutations need distinct replay rules because reading a result is not equivalent to repeating an effect.
- Every write-capable activity needs an idempotency key, business-state revision or equivalent deduplication control.
- Human approvals must be parameter-bound, time-bounded and revalidated at commit time rather than treated as reusable permission.
- Workflow definitions and activity contracts need versioning because in-flight runs may outlive several software deployments.
- Compensation is a business decision, not an automatic rollback: some effects can be reversed, some can only be offset, and some require manual resolution.
- Observability should reconstruct the causal trajectory from intent through checkpoints, retries, approvals, effects and authoritative outcome.
- Benchmarks should kill workers, inject timeouts, duplicate events and change dependencies—not merely measure clean-path completion.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production design begins by defining the authoritative business outcome and splitting agent reasoning from durable orchestration. The orchestrator records a workflow ID, input version, policy snapshot and current state. Nondeterministic model calls and external tool calls run as activities whose results are persisted. Read-only activities may retry freely within limits; write activities require idempotency and postcondition checks. Human decisions arrive as authenticated signals bound to a specific proposal digest and expiry. Timers and callbacks suspend the run without consuming a worker. The workflow advances through explicit states, writes receipts for completed effects and schedules compensations when later steps fail. Version gates keep old histories replayable after deployment. At completion, the system verifies the authoritative state rather than trusting a final model message. Audit and observability link every transition, retry and operator intervention.
How inference behaves
Durability is usually implemented through an append-only execution history, checkpoints or both. The runtime replays deterministic orchestration code against recorded events to reconstruct local state, while activity results prevent already-completed nondeterministic work from running again. Commands such as schedule activity, start timer, wait for signal and complete workflow become durable transitions. Activities receive stable business keys and attempt metadata. Before an external write, the activity checks whether the intended effect already exists; after the call, it records or re-reads the postcondition. Retry policies distinguish transient, permanent and ambiguous failures. Ambiguous timeouts are reconciled before retry. Long histories are compacted or continued into a new run while preserving lineage. Code changes use version markers, pinned definitions or compatible migrations so replay remains deterministic.
What the tests can miss
A credible benchmark measures crash recovery, duplicate-effect rate, replay determinism, ambiguous-timeout reconciliation, retry correctness, approval binding, event deduplication, compensation completion, state-version conflict handling, workflow migration, postcondition verification, operator recovery time, latency and complete cost per verified task. The fault matrix should terminate workers before and after model calls, during tool execution and after remote commit but before acknowledgment. It should inject duplicate callbacks, reordered events, stale approvals, expired credentials, partial downstream failures, schema changes, rolling deployments, long pauses, history growth, poisoned tool output and unavailable observability systems. Success means the final authoritative state is correct and every repeated or skipped effect is explainable.
What deployment involves
Start with one multi-step workflow that already causes operational pain when interrupted. Make the current states and side effects explicit before selecting a platform. Put each external interaction behind a narrow activity contract, introduce idempotency and record authoritative postconditions. Add worker-kill and timeout tests before enabling autonomous retries. Run in shadow or approval-required mode until replay, deduplication and compensation evidence are stable. Pin a workflow version for in-flight runs and establish migration or continue-as-new rules. Add operator controls for pause, resume, cancel, retry, compensate and inspect. Expand to multi-agent orchestration only after single-workflow recovery is reliable.
Where the risks sit
A durable history is a high-value control surface because it can influence actions long after the original input. Authenticate signals and callbacks, authorize every resumed action and treat stored model output, tool output and human comments as untrusted data. Bind approvals to the exact action parameters, resource version and expiry. Do not let a replayed historical token or policy decision authorize a new commit. Encrypt histories, isolate tenants, minimize sensitive payloads and apply retention rules. Restrict who can reset, rewind, fork, terminate or edit a workflow. Log operator interventions and version changes. A poisoned checkpoint or forged callback can turn reliable recovery into reliable exploitation.
What it really costs
Durable execution adds storage, orchestration writes, queue traffic, serialization, workflow-version maintenance, observability and operator tooling. It can also reduce repeated model calls, duplicate tool work, abandoned runs and manual reconciliation. Cost should be measured per verified completed workflow, including retries, waiting, compensation, support and retained history—not per model call. High-frequency low-value tasks may need coarse checkpoints, while expensive or consequential tasks justify finer transitions. The economic break-even depends on failure frequency, step cost, side-effect risk and the amount of work recovered after interruption.
What the evidence supports
The evidence is unusually consistent across vendors. Temporal, Azure Durable Task, AWS Step Functions, Google Workflows, Dapr, Restate, Cloudflare Workflows and other systems persist execution state, support retries and wait for events. Agent frameworks are adding direct integrations rather than rebuilding these primitives inside prompts. The remaining differences are important: replay models, determinism requirements, exactly-once claims, workflow versioning, history limits, tenancy, pricing and operational control vary widely. Durable execution does not make an agent correct, safe or authorized. It makes the trajectory recoverable. Correctness still depends on idempotent effects, fresh authorization, compensation, postcondition verification and disciplined workflow evolution.
How it works in practice
Production agents need a durable execution history that separates deterministic orchestration from nondeterministic work, survives failure without duplicating effects, preserves approval boundaries and verifies the authoritative outcome before completion.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 1
Define the outcome and failure boundary
Identify the authoritative final state, side effects, reversibility, ownership and unacceptable duplicates before writing an agent loop.
- 2
Model explicit workflow state
Represent phases, transitions, timers, waits, cancellation and terminal states outside the model context.
- 3
Persist nondeterministic results
Run model and tool calls as activities whose inputs, outputs, attempts and receipts are durably recorded.
- 4
Make effects idempotent and reconcilable
Use business keys, state revisions and postcondition reads so retries do not create duplicate durable effects.
- 5
Bind humans and policy to the commit
Pause durably for authenticated, parameter-bound approval and refresh authorization immediately before consequential writes.
- 6
Handle failure with retry or compensation
Classify transient, permanent and ambiguous failure; retry safely, compensate completed steps or route to manual resolution.
- 7
Version and operate in-flight runs
Keep replay deterministic across deployments and provide inspect, pause, resume, cancel, migrate and repair controls.
- 8
Verify outcome and retain evidence
Read authoritative postconditions, close the workflow only when state is correct and preserve a causal execution record.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
Verified durable completion yield
Y_v = P_c \times P_r \times P_i \times P_a \times P_o The end-to-end chance of a correct durable completion equals checkpoint correctness, recovery correctness, idempotent-effect correctness, authorization correctness and authoritative outcome verification. Strong model quality cannot compensate for a weak transition layer.
- If each of five stages succeeds 99 percent of the time, end-to-end yield is about 95.1 percent.
- Measure recovery and duplicate suppression separately from task quality.
- Use the authoritative business state as the final term.
Expected duplicate-effect exposure
E_d = N_w \times P_t \times P_r \times (1-C_i) Write attempts N_w multiplied by ambiguous timeout probability P_t, retry probability P_r and the uncovered fraction of idempotency control C_i estimates duplicate-effect exposure.
- A low timeout rate becomes material at agent scale.
- Calculate separately for payments, messages, deletions and infrastructure changes.
- Treat reconciliation coverage as part of idempotency.
Complete cost per verified workflow
C_v = \frac{C_{model}+C_{tools}+C_{orchestration}+C_{storage}+C_{retry}+C_{human}+C_{comp}+C_{support}}{N_{verified}} The denominator counts workflows whose authoritative outcome is verified. This reveals the cost hidden by abandoned runs, repeated calls, manual repair and compensation.
- Compare checkpoint granularity, not only platform price.
- Include retained-history and operator costs.
- Separate clean-path cost from fault-injected cost.
Remembering a conversation is not the same as resuming a workflow
Conversation history can tell an agent what was discussed. It cannot by itself prove that an email was sent, a ticket was created, a payment was captured or an approval remained valid when the effect committed.
Durable execution records state transitions and completed effects. It gives the system a restart point and a basis for deciding what may run again. The durable record is therefore operational state, not merely context.
This separation also keeps prompts smaller. The model receives the relevant current state while the workflow engine retains the full execution history and recovery semantics.
- Conversation memory supplies context.
- Workflow history supplies progress.
- Receipts and postconditions supply evidence.
- Authorization supplies current authority.
Put a deterministic shell around nondeterministic intelligence
Workflow replay works when orchestration decisions can be reconstructed from recorded events. Randomness, current time, network calls and model output must therefore enter through recorded activities or approved side channels.
The model can choose among bounded next steps, but the runtime persists that choice before executing consequential work. On recovery, the engine reuses the recorded result rather than asking the model to improvise again.
This does not eliminate nondeterminism. It places it behind explicit boundaries where cost, retries, evidence and policy can be managed.
- Orchestration decides control flow.
- Activities perform nondeterministic work.
- History records completed boundaries.
- Replay reconstructs local state.
Checkpoint at semantic boundaries, not every token
A useful checkpoint follows a decision or effect that would be expensive, unsafe or impossible to repeat. Persisting every token creates cost and noise; persisting only the final answer loses recovery value.
Typical boundaries include model response accepted, tool arguments validated, external effect confirmed, human approval received and compensation completed. Each boundary should have a stable state schema and ownership.
Granularity should reflect side-effect risk and recomputation cost. Cheap read-only reasoning can be repeated; expensive model calls or external writes usually should not be.
At-least-once delivery requires exactly-once business intent
Most distributed workflow systems may deliver work more than once. Exactly-once execution across arbitrary external systems is not a realistic default. The practical target is one intended business effect despite repeated attempts.
Use a stable idempotency key derived from workflow, operation and business resource. Store it where the authoritative effect is committed. A local flag written before a remote call is not enough, because the process can fail between remote commit and local acknowledgment.
When the external system does not support idempotency, reconcile by reading authoritative state before retry and after ambiguous timeouts.
- Stable business key
- Atomic effect or deduplication record
- Authoritative postcondition read
- Explicit ambiguous state
Human approval must survive time without becoming a blank cheque
Durable workflows can wait for hours or weeks without holding compute. That makes them suitable for review, escalation and exception handling.
The approval should identify the exact proposal, parameters, target resource, policy version and expiry. If any material input changes, the approval is invalid and the workflow returns to review.
At commit time, the system refreshes authorization and resource state. An approval proves intent at one moment; it does not guarantee that authority or conditions remain valid later.
Retry, reconcile, compensate and escalate are different actions
A transient network error may deserve exponential backoff. A validation error is permanent until inputs change. A timeout after a remote write is ambiguous and must be reconciled before retry. A later business failure may require compensation.
Compensation is not database rollback. Sending a refund does not erase a charge; sending a correction does not unsend an email. Compensations need their own idempotency, authorization and evidence.
Some workflows should stop for an operator rather than automatically undoing work. The state machine must make that choice explicit.
In-flight runs outlive deployments
A workflow that waits for a customer or regulator may remain active across many releases. If new code cannot replay old history, recovery fails exactly when it is needed.
Use compatible changes, version markers, pinned workflow definitions or migration. Activities can evolve behind stable contracts more easily than orchestration structure.
Test replay against captured production-like histories before deployment. Versioning is part of the runtime contract, not a release-note detail.
Multi-agent handoffs need durable custody
A handoff should record who owns the task, what state was transferred, which tools and authority apply, and what completion or rejection means. A message alone is not custody.
Retries can otherwise create two active owners, while lost acknowledgments can leave no owner. Durable queues and workflow state make assignment, lease, timeout and reassignment visible.
Specialist agents should return structured results and evidence. The orchestrator decides whether the workflow advances, retries, requests review or invokes compensation.
A checkpoint can preserve an attack as reliably as it preserves progress
Stored model output, tool output and human comments may contain prompt injection or false facts. Replay can reintroduce those values long after the original session.
Treat history payloads as untrusted, classify their origin and avoid replaying raw instructions into a more privileged context. Signals, callbacks and operator commands require authentication and authorization.
Administrative controls such as rewind, reset, fork and force-complete are powerful. Restrict them, log them and require dual control where the workflow affects high-value systems.
The workflow history should explain every repeated and skipped effect
A useful trace links workflow ID, state version, activity attempt, idempotency key, policy decision, approval digest, external receipt and verified postcondition.
Operators need to distinguish waiting, retrying, blocked, ambiguous, compensating and failed states. A generic running status is not enough for long-lived work.
Metrics should surface hot retry loops, stuck waits, history growth, repeated ambiguous timeouts, compensation backlog and version-migration failures.
Kill the worker on purpose
Clean-path tests do not establish durability. Terminate workers at every boundary, duplicate callbacks, reorder events, expire credentials and deploy new code while runs are active.
For write operations, simulate the worst timing: the external system commits, the acknowledgment is lost and the worker crashes. The recovered workflow must discover the prior effect rather than repeat it.
Score the final business state, not whether the orchestration endpoint returned success.
Choose recovery semantics before choosing a vendor
Platforms differ in replay model, determinism rules, history limits, retention, tenancy, self-hosting, queues, human tasks and pricing.
The durable contract should remain in your application design: workflow states, activity schemas, business keys, approvals and postconditions. A platform adapter should implement those controls rather than define them implicitly.
Simple tasks may need only a transactional outbox and queue. Long-running, branching, human-reviewed or high-value work usually benefits from a dedicated workflow runtime.
Durability trades small steady overhead for fewer catastrophic repeats
Every checkpoint adds writes and storage. Fine-grained histories can increase latency and operational complexity.
The savings appear when failures occur: completed model calls are reused, tools are not repeated, human approvals remain attached and operators can repair a run instead of restarting it.
Evaluate the complete cost per verified workflow under fault injection. A cheap clean path that duplicates a costly effect is not cheap.
Start with one interrupted workflow and one recovery objective
Choose a workflow where restarts or timeouts already create manual rework. Map its states and effects, then add durable orchestration without changing the user experience.
Introduce idempotency and postcondition checks before automatic retries. Add human approval and compensation only after the basic recovery path is proven.
Operationalize pause, resume, cancel and inspect before expanding autonomy. Reliability controls should arrive before the agent receives broader authority.
The agent loop is becoming a recoverable business process
Models remain probabilistic, but production progress cannot remain ephemeral. Durable execution gives agent systems a stable spine through crashes, waits and distributed failure.
The winning architecture will not be the one that checkpoints the most data. It will be the one that records the right transitions, prevents duplicate intent, refreshes authority and proves the final state.
Persist transitions, not just chats.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Crash recovery correctness | Share of runs that resume from the last valid boundary after worker termination | Proves progress survives infrastructure failure. |
| Duplicate-effect rate | Repeated durable effects per 10,000 fault-injected writes | Detects unsafe replay and retry. |
| Replay determinism | Histories that replay without nondeterminism or state divergence | Protects recovery across restarts and deployments. |
| Ambiguous-timeout reconciliation | Timed-out writes correctly classified before retry | Covers the most dangerous failure window. |
| Retry policy accuracy | Transient failures retried and permanent failures stopped correctly | Prevents both abandonment and retry storms. |
| Approval binding | Commits using valid, unexpired, parameter-matched approvals | Prevents stale approval reuse. |
| Event deduplication | Duplicate callbacks or signals applied once | Protects event-driven workflows. |
| Compensation completion | Required compensations completed and verified | Measures business recovery, not only technical failure. |
| State conflict handling | Stale resource revisions detected before commit | Prevents acting on obsolete plans. |
| Workflow migration success | In-flight histories that survive compatible deployment or migration | Tests long-lived production evolution. |
| Postcondition verification | Completed runs with independently verified authoritative state | Separates endpoint success from task success. |
| Operator recovery time | Median time to diagnose and repair stuck or ambiguous runs | Captures operational usability. |
| Fault-path latency | Time to verified completion under representative failures | Shows the user impact of resilience controls. |
| Complete cost per verified workflow | All model, tool, orchestration, retry, human and repair cost divided by verified outcomes | Supports realistic platform and checkpoint choices. |
Four sensible deployment patterns
Checkpointed single-agent workflow
- Where it fits
- One agent performs a bounded sequence with expensive model or tool calls
- What you take on
- Simple ownership, but workflow code must remain replay-compatible.
Human-gated durable process
- Where it fits
- Publishing, financial, compliance or administrative work requiring review
- What you take on
- Strong control and long waits, with approval identity and expiry complexity.
Saga-style multi-system workflow
- Where it fits
- A task creates effects across services without one distributed transaction
- What you take on
- Business compensation is explicit but cannot always restore the original world.
Durable multi-agent orchestration
- Where it fits
- Specialists hand off work over long periods or across distributed workers
- What you take on
- Scales expertise, but custody, duplicate ownership and authority boundaries become harder.
Where projects usually go wrong
Worker crashes after a model call
What you see: Expensive reasoning is repeated or the run restarts
What to do: Persist the accepted model result before scheduling the next transition.
Remote write commits before timeout
What you see: Retry creates a duplicate email, order or change
What to do: Use external idempotency keys and reconcile authoritative state before retry.
Nondeterministic orchestration code changes
What you see: Old histories cannot replay after deployment
What to do: Version workflow logic and test replay against captured histories.
Duplicate callback advances twice
What you see: Two downstream branches or effects are created
What to do: Deduplicate by event ID and expected state revision.
Stale approval is reused
What you see: Changed parameters commit under an earlier review
What to do: Bind approval to proposal digest, resource version, actor and expiry.
Retry storm amplifies outage
What you see: Downstream service and model limits worsen
What to do: Classify failures, use bounded backoff, jitter and circuit breaking.
Compensation is assumed to be rollback
What you see: Business obligations remain after technical undo
What to do: Model compensations as first-class effects with verification and manual fallback.
History grows without bound
What you see: Replay slows and storage cost rises
What to do: Use Continue-As-New, compaction or archival while preserving lineage.
Two agents own the same task
What you see: Conflicting actions and duplicate work
What to do: Persist custody, leases and atomic assignment transitions.
Poisoned output survives restart
What you see: Recovered run repeats attacker-controlled instructions
What to do: Label provenance, sanitize stored data and reapply policy on resume.
Operator force-completes incorrectly
What you see: Workflow closes while authoritative state is unresolved
What to do: Restrict admin actions, require reason and verify postconditions.
Success response replaces outcome evidence
What you see: Workflow reports complete while business state is partial
What to do: Read and record the authoritative postcondition before terminal success.
A checklist you can actually use
- Define the authoritative outcome and unacceptable duplicate effects.
- Separate conversation memory from execution state.
- Represent workflow phases and terminal states explicitly.
- Place nondeterministic model and tool work behind recorded activities.
- Choose checkpoint boundaries by effect risk and recomputation cost.
- Assign stable workflow, operation and business-resource identifiers.
- Require idempotency for every write-capable activity.
- Reconcile authoritative state after ambiguous timeouts.
- Classify transient, permanent and ambiguous failures.
- Bound retries with backoff, jitter and circuit breakers.
- Bind human approval to exact parameters, resource version and expiry.
- Refresh authorization at the commit boundary.
- Define compensation and manual-resolution paths.
- Make compensations idempotent and observable.
- Deduplicate callbacks, signals and queue events.
- Persist custody during multi-agent handoffs.
- Version workflow logic and activity schemas.
- Replay-test old histories before deployment.
- Control history growth and retention.
- Encrypt and tenant-isolate workflow state.
- Restrict rewind, reset, fork and force-complete operations.
- Verify authoritative postconditions before terminal success.
- Benchmark worker kills, duplicate events, stale approvals and rolling deployments.
Terms worth knowing
- Durable execution
- Execution whose progress is persisted so it can resume after process, host or network failure.
- Workflow history
- An ordered record of commands, events and completed results used to reconstruct a run.
- Checkpoint
- A durable boundary after which earlier completed work should not need to run again.
- Replay
- Reconstructing workflow state by applying recorded history to orchestration code.
- Activity
- A nondeterministic unit such as a model call, API request or tool execution performed outside deterministic orchestration.
- Idempotency
- The property that repeated attempts produce one intended business effect.
- Ambiguous timeout
- A timeout where the caller cannot tell whether the remote effect committed.
- Postcondition
- The authoritative state that must be true before a workflow is considered successful.
- Compensation
- A later business action that offsets or mitigates an earlier completed effect.
- Saga
- A sequence of local transactions coordinated with compensating actions instead of one global transaction.
- Signal
- An external event delivered to a waiting workflow, such as approval or cancellation.
- Continue-As-New
- Starting a new linked execution with compact state to limit workflow-history growth.
- Deterministic orchestration
- Control-flow code that produces the same commands when replayed against the same event history.
- Custody
- The durable record of which agent, worker or team currently owns a task.
- Commit-time authorization
- Revalidating that authority and approval remain valid immediately before a durable effect.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 Temporal durable executiontemporal.io
- 02 Temporal documentationdocs.temporal.io
- 03 Temporal Workflowsdocs.temporal.io
- 04 Temporal Activitiesdocs.temporal.io
- 05 Temporal Workflow Executiondocs.temporal.io
- 06 Temporal Event Historydocs.temporal.io
- 07 Temporal Retry Policiesdocs.temporal.io
- 08 Temporal Activity Executiondocs.temporal.io
- 09 Temporal Workflow message passingdocs.temporal.io
- 10 Temporal detecting workflow failuresdocs.temporal.io
- 11 Temporal Python failure detectiondocs.temporal.io
- 12 Temporal Python Continue-As-Newdocs.temporal.io
- 13 Temporal Python message passingdocs.temporal.io
- 14 Temporal Python versioningdocs.temporal.io
- 15 Temporal Saga patterntemporal.io
- 16 Gemini durable agent with Temporalai.google.dev
- 17 OpenAI Agents SDK running agentsopenai.github.io
- 18 OpenAI Agents SDK human in the loopopenai.github.io
- 19 OpenAI Agents SDK sessionsopenai.github.io
- 20 OpenAI Agents SDK tracingopenai.github.io
- 21 Azure Durable Task documentationlearn.microsoft.com
- 22 Durable Task for AI agentslearn.microsoft.com
- 23 Durable Task Microsoft Agent Framework extensionlearn.microsoft.com
- 24 Microsoft Agent Framework Durable Extensionlearn.microsoft.com
- 25 Durable Functions overviewlearn.microsoft.com
- 26 Durable Functions application patternslearn.microsoft.com
- 27 Durable Functions function typeslearn.microsoft.com
- 28 Durable Functions error handlinglearn.microsoft.com
- 29 Durable Functions timerslearn.microsoft.com
- 30 Durable Functions external eventslearn.microsoft.com
- 31 Durable Functions instance managementlearn.microsoft.com
- 32 Durable Functions diagnosticslearn.microsoft.com
- 33 Durable Functions storage providerslearn.microsoft.com
- 34 Durable Functions task hubslearn.microsoft.com
- 35 Durable Functions entitieslearn.microsoft.com
- 36 Durable Functions eternal orchestrationslearn.microsoft.com
- 37 Durable Functions zero downtime deploymentlearn.microsoft.com
- 38 AWS Step Functions overviewdocs.aws.amazon.com
- 39 AWS Step Functions workflow typesdocs.aws.amazon.com
- 40 AWS Step Functions error handlingdocs.aws.amazon.com
- 41 AWS Step Functions human approvaldocs.aws.amazon.com
- 42 AWS Step Functions callback tasksdocs.aws.amazon.com
- 43 AWS Step Functions service integrationsdocs.aws.amazon.com
- 44 AWS Step Functions execution redrivedocs.aws.amazon.com
- 45 AWS Step Functions execution historydocs.aws.amazon.com
- 46 AWS Step Functions loggingdocs.aws.amazon.com
- 47 AWS Step Functions encryptiondocs.aws.amazon.com
- 48 AWS Step Functions IAMdocs.aws.amazon.com
- 49 AWS Step Functions quotasdocs.aws.amazon.com
- 50 Google Cloud Workflows overviewcloud.google.com
- 51 Google Cloud Workflows retriescloud.google.com
- 52 Google Cloud Workflows error handlingcloud.google.com
- 53 Google Cloud Workflows callbackscloud.google.com
- 54 Google Cloud Workflows executionscloud.google.com
- 55 Google Cloud Workflows parallel stepscloud.google.com
- 56 Google Cloud Workflows connectorscloud.google.com
- 57 Google Cloud Workflows loggingcloud.google.com
- 58 Google Cloud Workflows CMEKcloud.google.com
- 59 Cloudflare Agents durable executiondevelopers.cloudflare.com
- 60 Cloudflare Workflowsdevelopers.cloudflare.com
- 61 Cloudflare Workflows rules of workflowsdevelopers.cloudflare.com
- 62 Cloudflare Workflows sleeping and retryingdevelopers.cloudflare.com
- 63 Cloudflare Durable Objectsdevelopers.cloudflare.com
- 64 Dapr Workflow overviewdocs.dapr.io
- 65 Dapr Workflow authoringdocs.dapr.io
- 66 Dapr Workflow managementdocs.dapr.io
- 67 Dapr resiliency overviewdocs.dapr.io
- 68 Dapr state managementdocs.dapr.io
- 69 Restate durable executiondocs.restate.dev
- 70 Restate servicesdocs.restate.dev
- 71 Restate workflowsdocs.restate.dev
- 72 Restate awakeablesdocs.restate.dev
- 73 Restate idempotencydocs.restate.dev
- 74 Restate retriesdocs.restate.dev
- 75 Restate AI agentsdocs.restate.dev
- 76 DBOS durable executiondocs.dbos.dev
- 77 DBOS workflowsdocs.dbos.dev
- 78 DBOS transactionsdocs.dbos.dev
- 79 DBOS queuesdocs.dbos.dev
- 80 DBOS recoverydocs.dbos.dev
- 81 Inngest durable executioninngest.com
- 82 Inngest stepsinngest.com
- 83 Inngest retriesinngest.com
- 84 Inngest idempotencyinngest.com
- 85 Inngest concurrencyinngest.com
- 86 Inngest wait for eventinngest.com
- 87 LangGraph persistencedocs.langchain.com
- 88 LangGraph interruptsdocs.langchain.com
- 89 LangGraph time traveldocs.langchain.com
- 90 LangGraph durable executiondocs.langchain.com
- 91 LangGraph memorydocs.langchain.com
- 92 LangGraph streamingdocs.langchain.com
- 93 CNCF Serverless Workflow specificationgithub.com
- 94 CloudEvents specificationcloudevents.io
- 95 CloudEvents specification repositorygithub.com
- 96 OpenTelemetry specificationopentelemetry.io
- 97 W3C Trace Contextw3.org
- 98 HTTP Semantics RFC 9110rfc-editor.org
- 99 Problem Details RFC 9457rfc-editor.org
- 100 Webhooks Standardstandardwebhooks.com
- 101 BPMN 2.0 specificationomg.org
- 102 NIST AI Risk Management Frameworknist.gov
- 103 NIST AI RMF Generative AI Profilenist.gov
- 104 NIST SP 800-53 Rev. 5csrc.nist.gov
- 105 NIST SP 800-92 log managementcsrc.nist.gov
- 106 NIST SP 800-207 Zero Trust Architecturecsrc.nist.gov
- 107 OWASP AI Agent Security Cheat Sheetcheatsheetseries.owasp.org
- 108 OWASP LLM Prompt Injection Preventioncheatsheetseries.owasp.org
- 109 OWASP Agentic AI threats and mitigationsgenai.owasp.org
- 110 OWASP Excessive Agencyowasp.org
- 111 MITRE ATLASatlas.mitre.org
- 112 Saga pattern Microsoft Cloud Design Patternslearn.microsoft.com
- 113 Compensating Transaction patternlearn.microsoft.com
- 114 Retry patternlearn.microsoft.com
- 115 Circuit Breaker patternlearn.microsoft.com
- 116 Idempotent Consumer patternmicroservices.io
- 117 Transactional Outbox patternmicroservices.io
- 118 Agent Memory characterization paperarxiv.org
- 119 Commit-time authorization for LLM agentsarxiv.org
- 120 SKILL.nb durable agent workflowsarxiv.org
- 121 AgentSPEX execution languagearxiv.org
- 122 Behavioral firewall for workflow agentsarxiv.org
- 123 The Tail at Scaleresearch.google
- 124 Exactly-once processing in Kafkakafka.apache.org
- 125 PostgreSQL transaction isolationpostgresql.org
- 126 PostgreSQL advisory lockspostgresql.org