Skip to content

[Feature]: Support incremental composition of parallel operations #614

Description

@zhongkechen

What would you like?

Please add an incremental composition API for Durable Execution parallel
operations.

The current Python API requires the complete sequence of branch functions when
context.parallel(...) is called:

result = context.parallel(
    [run_research, run_analysis],
    name="agent-tasks",
)

This is convenient when every branch is known up front, but it does not let a
workflow create a parallel operation, register and start branches as work is
discovered, and then explicitly seal and await the operation.

Incremental composition is especially useful for agentic AI workloads. An
agent may checkpoint a generated plan, discover tool calls or specialist tasks
from that plan, and add branches as those tasks become known. Ready work could
start immediately, subject to max_concurrency, while later branches are
still being assembled.

The Java Durable Execution SDK already exposes this lifecycle:

ParallelDurableFuture parallel = context.parallel("agent-tasks");
try (parallel) {
    DurableFuture<ResearchResult> research =
        parallel.branch("research", ResearchResult.class, branch -> runResearch(branch));

    if (plan.requiresReview()) {
        DurableFuture<ReviewResult> review =
            parallel.branch("review", ReviewResult.class, branch -> runReview(branch));
    }
}

parallel.branch(...) registers and starts each branch, and closing/getting the
parent seals registration and waits for completion.

Benefits include:

  1. Branches can be registered and started as a workflow plan is constructed.
  2. Ready work need not wait for the entire branch sequence to be materialized.
  3. Conditional and dynamic fan-out can use normal control flow without first
    building an intermediate list.
  4. Individual branch handles can compose naturally with later workflow logic.
  5. The programming model supports agentic orchestration and other workloads
    where the amount of work emerges incrementally.
  6. It improves cross-SDK parity with Java.

The existing sequence-based context.parallel(...) API should remain available
for the common case where all branches are predefined.

Possible Implementation

An additive builder/handle API could provide a registration phase followed by
an explicit completion phase. The exact naming is open for discussion; this is
only an illustrative Python shape:

parallel = context.create_parallel(
    name="agent-tasks",
    config=ParallelConfig(max_concurrency=4),
)

research = parallel.branch("research", run_research)

if plan.requires_review:
    review = parallel.branch("review", run_review)

summary = parallel.complete()
research_result = research.get()

A context-manager variant could also make the completion boundary explicit:

with context.parallel_builder("agent-tasks") as parallel:
    research = parallel.branch("research", run_research)
    if plan.requires_review:
        review = parallel.branch("review", run_review)

research_result = research.get()

The API should ideally:

  • allow branches to be registered until complete() or context-manager exit
    seals the operation
  • allow registered branches to start immediately, respecting
    max_concurrency
  • preserve branch names and registration order for deterministic replay
  • retain existing completion strategies, serialization, summary generation,
    and per-branch error behavior
  • reject branch registration after completion has begun
  • preserve the existing sequence-based API as a convenience wrapper

Incremental registration must not weaken Durable Execution's deterministic
replay contract. For agentic workloads, model-generated plans or tool-call
sets should first be produced in a checkpointed step. Replay should then
register the same branches in the same order, with the SDK detecting
inconsistent registration.

Is this a breaking change?

No. This can be introduced as an additive API.

Does this require an RFC?

Yes. The registration lifecycle, completion semantics, replay validation, and
interaction with early completion strategies should be specified.

Additional Context

References:

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestparityProvides parity with other language implementations of the SDK

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions