Problem
When resuming a workflow from a persisted checkpoint, applications currently need two separate workflow.run calls:
- Restore or hydrate the workflow from the checkpoint.
- Submit the new user input and continue execution.
This creates an unnecessary round trip and complicates integrations that receive one logical request.
Desired behavior
Allow a workflow to restore its checkpoint and process new input atomically in one run.
An illustrative API could be:
response = await workflow.run(
messages=new_user_message,
checkpoint=checkpoint,
)
Alternatively, a dedicated API could make the intent explicit:
response = await workflow.resume(
checkpoint=checkpoint,
messages=new_user_message,
)
The exact API shape is open for design.
Expected semantics
The combined operation should:
- Restore and validate the checkpoint.
- Hydrate the workflow state.
- Apply the new user input.
- Continue workflow execution.
- Return the resulting response or response stream.
The hydration step should not produce a separate intermediate response visible to the caller.
Benefits
- Removes an unnecessary workflow execution and round trip.
- Avoids exposing an intermediate hydration response.
- Simplifies HTTP, hosted, and other request/response adapters.
- Preserves a single execution lifecycle for tracing, cancellation, errors, and streaming.
- Makes checkpoint-based workflow resumption behave more like session-based agent continuation.
Acceptance criteria
- A workflow can accept both persisted checkpoint state and new input in one call.
- Checkpoint restoration occurs before the new input is processed.
- Existing two-step usage remains backward compatible.
- The behavior supports both streaming and non-streaming runs.
- Checkpoint validation and restoration failures are returned without executing the new input.
- The pattern is documented with a runnable example.
Related checkpoint recovery work: #7809.
Problem
When resuming a workflow from a persisted checkpoint, applications currently need two separate
workflow.runcalls:This creates an unnecessary round trip and complicates integrations that receive one logical request.
Desired behavior
Allow a workflow to restore its checkpoint and process new input atomically in one run.
An illustrative API could be:
Alternatively, a dedicated API could make the intent explicit:
The exact API shape is open for design.
Expected semantics
The combined operation should:
The hydration step should not produce a separate intermediate response visible to the caller.
Benefits
Acceptance criteria
Related checkpoint recovery work: #7809.