Parallel Tasks
Customer onboarding with three independent Steps that all lead to a single goal. Demonstrates how the dependency graph lets Steps run in parallel automatically, without configuration for one-to-many execution.
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 starts from complete-onboarding and finds its dependencies. Since it needs the outputs of all three earlier Steps and they do not 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 declare only the final Goal. The planner identifies all earlier required Steps.
- 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.