Parallel Tasks
Customer onboarding with three independent Steps that all converge on a single goal. Demonstrates how parallelism falls out of the dependency graph automatically, with no fan-out configuration needed.
Scenario
Prepare a customer onboarding package: generate documents, set up the account, and send a welcome email. None of these depend on each other, so they should run in parallel. A final Step records that onboarding completed once all three are done.
Flow Design
Goals: [complete-onboarding]
The planner walks back from complete-onboarding to find its dependencies. Since it needs the outputs of all three upstream Steps and they don’t depend on each other, the engine runs them in parallel.
generate-documents
- Generate the welcome packet
- Needs:
customer_id - Output:
document_url
setup-account
- Create user account and preferences
- Needs:
customer_id,email - Output:
account_id
send-welcome-email
- Send the welcome email
- Needs:
email,customer_name - Output:
email_sent
complete-onboarding (the Goal)
- Records onboarding completion
- Needs:
document_url,account_id,email_sent - Output:
onboarding_complete
Parallelization
(initial)"] A["generate-documents"] B["setup-account"] C["send-welcome-email"] D["complete-onboarding
(goal)"] Init --> A Init --> B Init --> C A -->|document_url| D B -->|account_id| D C -->|email_sent| D style D fill:#c8e6c9
generate-documents, setup-account, and send-welcome-email start as soon as their inputs are available. Since none of them block each other, the engine runs them concurrently. complete-onboarding waits until all three outputs land in Flow state, then runs.
Key Points
- You only declare the most downstream Goal. The planner figures out everything upstream.
- Parallelism is a consequence of the dependency graph, not something you configure for the Flow.
- If you wanted three truly independent outcomes with no convergence, you would list all three as Goals and there would be no
complete-onboardingStep at all.