Feature request: Durable Actions with pluggable workflow engines

[FredKSchott]

Summary

Explore durable Actions as a follow-up to RFC #312: Actions as reusable finite agent orchestration.

The proposed direction is to add a durable Action variant with a Temporal/Inngest/Cloudflare Workflows-style step API:

// src/actions/review.ts
export const review = defineDurableAction({
  input: ReviewInputSchema,
  output: ReviewOutputSchema,

  async run({ harness, input, step }) {
    const analysis = await step.run("analyze", async () => {
      return harness.session("analysis").prompt(input.prompt);
    });

    return step.run("publish", async ({ idempotencyKey }) => {
      return publish(analysis, { idempotencyKey });
    });
  },
});

A configured durability engine would checkpoint completed steps and resume interrupted Action executions. Without such an engine, the same Action could still run locally through an in-process step implementation, but without restart guarantees.

This is a feature direction, not a complete specification. The goal is to validate the model and gather feedback before committing to provider contracts or exact APIs.

Motivation

Flue is intended to be a durable agent framework, but a long-running Action called by an Agent can still be vulnerable to process failure.

For example, an Action may perform 30 minutes of finite orchestration on behalf of an Agent. If the process dies after 20 minutes, Flue needs to know:

• which work completed;
• which work is safe to reuse;
• which work must be retried;
• how to reconnect the parent Agent to the same child Action invocation;
• how to resume against the same sandbox and session state;
• how to eventually deliver the result to the original tool call.

The new Action primitive proposed in RFC #312 is a natural place for durable checkpoints. Actions already represent finite orchestration shared by Agents and Workflows, while Agents and Workflows provide different execution roots.

Proposed model

Ordinary Actions

An ordinary Action executes directly without creating a durable-engine run:

export const formatReport = defineAction({
  async run({ harness, input }) {
    // short, ordinary in-process work
  },
});

This avoids durable execution overhead for small helpers and fast orchestration.

Durable Actions

A durable Action opts into replay-compatible semantics and receives step:

export const review = defineDurableAction({
  async run({ harness, input, step }) {
    const repository = await step.run("load-repository", async () => {
      return loadRepository(input.repository);
    });

    return step.run("review-repository", async () => {
      return harness.session().prompt(repository);
    });
  },
});

defineDurableAction() declares that the Action is written for checkpointed replay. It does not itself choose or configure a provider.

The distinction is primarily about execution cost and programming constraints:

• defineAction() runs as a normal function through Flue’s Action executor.
• defineDurableAction() may create a Cloudflare Workflow, Inngest function run, Temporal execution, or another provider-backed durable execution.

Agents and Workflows should not need their own durable: true flags. They use the configured durability engine automatically whenever they invoke a durable Action.

Durability engine

Durability should generally be configured once for the application or deployment target rather than repeated across every Agent and Workflow.

Conceptually:

export default defineConfig({
  durability: inngest({
    client,
  }),
});

Or target-specific configuration:

export default defineConfig({
  node: node({
    durability: inngest({ client }),
  }),
  cloudflare: cloudflare({
    durability: workflows(),
  }),
});

The exact configuration surface is unresolved. It may be implemented through build/target plugins even if “plugin” is not the user-facing mental model.

The important ownership model is:

Action definition → portable replay-compatible behavior
Agent/Workflow → execution root
Deployment target → durability engine
Invocation → provider-backed step implementation

A future named engine registry could support rare cases where different execution roots require different providers, but this should not shape the initial API without a concrete use case.

Execution semantics

Durable Actions would use checkpoint replay rather than serialized JavaScript continuations.

After an interruption, the engine would:

1. Reconstruct the Action execution scope and harness.
2. Reconnect to the same sandbox identity.
3. Restart the Action function from the beginning.
4. Return stored outputs for completed steps.
5. Execute incomplete or retryable steps.
6. Persist each completed step result before continuing.
7. Complete the Action and return its result to the parent Agent or Workflow.

For example:

async run({ harness, input, step }) {
  const source = await step.run("source", () => loadSource(input));
  const result = await step.run("review", () => reviewSource(harness, source));
  return result;
}

On replay, the Action starts again, but completed source and review steps return their checkpointed outputs instead of rerunning.

This means code outside step callbacks may execute more than once and should be deterministic and free of durable side effects.

Step contract

The smallest useful API may look like:

interface DurableStep {
  run<T>(
    key: string,
    callback: (context: {
      attempt: number;
      idempotencyKey: string;
      signal: AbortSignal;
    }) => T | Promise<T>,
  ): Promise<T>;
}

Potential later configuration:

await step.run(
  "publish",
  {
    retries: 3,
    timeout: "5 minutes",
  },
  async ({ idempotencyKey, signal }) => {
    return publish(result, { idempotencyKey, signal });
  },
);

Step identities must be explicit and stable. Completed outputs must be serializable. A replay encountering an existing step key with incompatible inputs or configuration should fail rather than silently return stale data.

Potential future APIs include:

await step.sleep("cooldown", "10 minutes");

const approval = await step.waitForEvent("approval", {
  timeout: "7 days",
});

Timers, external events, parallelism, and compensation are larger additions and should not be implied by the first step.run() implementation.

Durability guarantees

A checkpointed result may be reused without rerunning its callback, but a generic step callback cannot be promised exactly-once execution.

There is always a possible failure window:

1. the callback commits an external side effect;
2. the process dies;
3. the engine has not yet committed the step result.

The callback may therefore execute again. Durable Actions should expose a stable idempotency key and clearly document at-least-once callback semantics.

Only serializable values should cross step boundaries. Live values such as these must remain inside callbacks and be reacquired after replay:

• harnesses and sessions;
• streams and open processes;
• requests and responses;
• provider clients;
• sandbox handles;
• functions and closures as returned state.

Sandbox recovery

Durable Action recovery should reconnect to the existing sandbox rather than silently create a fresh one.

Flue’s intended durability model assumes that an Agent or Workflow can reacquire the same workspace and continue from persisted session and filesystem state. Replaying completed filesystem steps against an empty replacement sandbox would be incorrect: the engine might skip a completed clone or build step even though its files no longer exist.

A durability-capable sandbox therefore needs a stable, persisted lease or identity that the runner can reacquire after interruption.

If the original sandbox cannot be recovered, the Action should fail or enter a blocked state rather than pretending that checkpoint replay is safe. Automatic workspace reconstruction or snapshots would be a separate feature.

Provider integrations

Cloudflare Workflows

Cloudflare Workflows appears to be a direct fit:

• Flue Workflow/Action execution maps to a Cloudflare Workflow instance.
• step.run() maps to step.do().
• future sleeps and event waits map to native Workflow primitives.
• Cloudflare provides checkpointed step outputs, retries, status, and lifecycle management.

Flue would still own its Action API, scoped harness behavior, sandbox reconnection, Agent integration, schemas, and normalized events.

Inngest

Inngest is also a close conceptual fit. Inngest functions replay from the beginning and memoize completed step.run() results.

A Flue integration could register discovered durable execution roots as Inngest functions and adapt the Flue step facade onto Inngest’s durable step API.

Temporal

Temporal integration appears possible but less direct.

Temporal separates deterministic Workflow code from side-effecting Activities. Arbitrary inline callbacks that capture a Flue harness cannot necessarily be serialized or registered as Activities without build-time support.

Possible approaches include:

• generating or registering named Activities from Flue durable steps;
• hosting a Flue checkpoint/replay executor within Temporal-controlled work;
• adopting stricter named step definitions for a Temporal adapter.

Temporal should remain a potential provider, but the initial portable contract should not claim that every provider can execute arbitrary inline closures identically.

Trigger.dev

Trigger.dev is a plausible engine for long-running Action execution and retries. Its task model may map more naturally to whole Actions or generated named subtasks than to inline checkpoint callbacks.

This is still useful, but it may offer different capabilities from Cloudflare Workflows or Inngest. Provider adapters should declare the durable primitives they support rather than Flue silently weakening guarantees.

Durable Actions called by Agents

The most valuable and difficult use case is an Agent invoking a durable Action as a model tool.

Flue would need to:

1. Derive a stable Action invocation identity from the parent Agent submission and tool-call ID.
2. Durably admit the child Action before executing it.
3. Persist that child identity in the parent operation journal.
4. Suspend or detach the parent operation while the Action runs.
5. Recover or reconnect to the same child execution after interruption.
6. Deliver the completed Action output into the original tool result.
7. Avoid creating a second logical Action invocation for the same tool call.

A model-invoked durable Action remains an Action invocation, not a Workflow Run. It needs internal execution identity and status, while only a createWorkflow() binding creates the public Workflow Run envelope discussed in RFC #312.

This integration should likely follow top-level durable Workflow Actions because it changes Agent tool-call recovery and settlement semantics.

Local behavior without an engine

A durable Action should remain runnable when no external durability engine is configured, especially for local development and reusable packages.

In that mode:

• step.run() executes the callback in process;
• keys and serializable outputs may still be validated;
• no restart or checkpoint guarantee is provided;
• the programming model remains compatible with a real engine.

This lets authors share the same durable Action code regardless of deployment environment.

The local implementation must not imply guarantees it does not provide. Tooling and documentation should clearly identify whether the current runner has a durable engine attached.

Why not make every Action durable?

Flue should make configured durability broadly available by default across Agents and Workflows, but not every small Action should pay the cost of creating a provider run.

Durable execution introduces real overhead:

• provider admission;
• checkpoint serialization;
• remote coordination;
• replay restrictions;
• status and recovery records.

The proposed distinction is therefore:

• the application configures one durability engine;
• every Agent and Workflow can use it;
• defineDurableAction() opts a particular Action into provider-backed durable execution;
• defineAction() remains the lightweight path.

The Action chooses durable-compatible semantics. The deployment chooses the engine and actual guarantees.

Relationship to RFC #312

This proposal builds on RFC #312 rather than changing its core model:

• Actions remain reusable finite behavior over a scoped harness.
• Agents remain persistent, message-driven actors.
• Workflows remain finite run envelopes created with createWorkflow().
• Runners own harnesses and resources.
• Action invocations receive isolated session scopes while inheriting the runner’s sandbox and capabilities.

Durable Actions add another execution option beneath that model:

Agent or Workflow execution root
└── durable Action invocation
    ├── step checkpoint
    ├── step checkpoint
    └── nested scoped sessions/tasks

The Actions RFC should land first because it establishes runner-owned harnesses, stable Action identities, scoped sessions, and a shared Action executor. Those are prerequisites for correct durable replay.

Possible implementation sequence

1. Land the Actions and Workflows model from RFC RFC: Actions as reusable finite agent orchestration #312.
2. Define stable Action invocation and step identities.
3. Add an in-process step implementation for durable Actions.
4. Add sequential provider-backed steps for top-level Workflow Actions on one target.
5. Add sandbox lease persistence and reconnection requirements.
6. Add another provider integration to validate portability.
7. Integrate durable Action invocations with Agent tool-call journaling and recovery.
8. Consider timers, external events, cancellation, parallelism, and nested durable Actions.

Goals

• Make long-running Action orchestration resumable through explicit checkpoints.
• Preserve one portable Action authoring model across local and provider-backed execution.
• Allow Cloudflare Workflows, Inngest, Temporal, Trigger.dev, or future engines to integrate behind Flue semantics where practical.
• Reconnect to the same sandbox during recovery.
• Keep durable execution available to every Agent and Workflow without repetitive per-root configuration.
• Avoid provider overhead for ordinary short Actions.
• Preserve the distinction between Action invocations and public Workflow Runs.

Non-goals

• Exactly-once execution of arbitrary external side effects.
• Serializing the JavaScript stack or arbitrary closures as continuation state.
• Reconstructing a lost ephemeral sandbox automatically.
• Exposing provider-native APIs directly in Action code.
• Guaranteeing identical advanced capabilities across every engine.
• Shipping timers, event waits, compensation, parallel fan-out, or cross-version migration in the first iteration.
• Implementing this as part of RFC RFC: Actions as reusable finite agent orchestration #312.

Open questions

1. Should the public API use defineDurableAction() or defineAction({ durable: true })?
2. Where should the default durability engine be configured for Node and Cloudflare targets?
3. What is the minimum provider capability contract for calling something a durability engine?
4. Should local execution persist checkpoints to SQLite, or remain explicitly in-process only?
5. How should a provider adapter declare support for sleeps, event waits, parallelism, and cancellation?
6. What stable sandbox lease contract should Flue require for durable replay?
7. How should Action and build versions interact with executions that survive a deployment?
8. Should Action input be included explicitly in each step identity or only validated at Action admission?
9. What status and inspection surface should model-invoked durable Actions expose without turning them into Workflow Runs?
10. Which provider would be the best first implementation for validating the abstraction: Cloudflare Workflows or Inngest?

[devnomic]

Another provider integration to look at: openworkflow.dev