curiositech SKILL: Workflow Patterns - Systematic Coordination Design
When to Use This Skill
Activate when encountering coordination complexity beyond simple sequential task execution: multi-agent orchestration, parallel processing with synchronization, conditional routing, iterative refinement, or system evaluation for workflow capability.
Decision Points
Pattern Selection Tree
IF designing coordination structure:
Sequential dependency only?
- Yes → Pattern 1: Sequence
- No → Continue to branching analysis
Multiple parallel branches needed?
- All branches required → Pattern 2: AND-split/join
- Conditional subset → Pattern 6: OR-split (need runtime branch determination)
- Exactly one branch → Pattern 4: XOR-split/join
Synchronization requirements?
- Wait for all branches → AND-join or OR-join
- First completion wins → Pattern 9: Discriminator
- N out of M completions → Pattern 8: N-out-of-M-join
Decision timing?
- Process determines → XOR-split (internal condition)
- External event determines → Pattern 16: Deferred choice
- Runtime data determines → OR-split
Iteration needed?
- Fixed structure loop → Use sequence + XOR back-edge
- Dynamic/arbitrary cycles → Pattern 10: Arbitrary cycles
- Multiple concurrent instances → Pattern 12: Multiple instances
System Evaluation Decision Tree
IF evaluating orchestration systems:
- Map required patterns → List all coordination structures your domain needs
- Test basic patterns → Sequence, AND-split/join, XOR-split/join (if these fail, stop)
- Test advanced branching → OR-split, discriminator, N-out-of-M (most systems fail here)
- Test structural patterns → Cycles, multiple instances, implicit termination
- Test interactions → Combine patterns your workflow uses together
- Measure complexity → >10x workaround complexity = unsupported
Decision criteria:
- Natural implementation = supported
- Workaround required = capability gap
- External code needed = wrong architecture
- Race conditions appear = semantic mismatch
Failure Modes
1. OR-Split Confusion (Symptom: Wrong branches activate)
Detection: OR-split activates all branches instead of runtime-determined subset, or requires manual branch selection Root cause: System conflates OR-split with AND-split or lacks runtime evaluation capability Fix: Implement true OR-split with condition evaluation at runtime, or redesign using multiple XOR-splits
2. Discriminator Race Conditions (Symptom: Multiple completions processed)
Detection: "First wins" logic processes multiple completions, late arrivals not ignored, state corruption on near-simultaneous finish Root cause: Missing atomic completion detection or lack of proper discriminator semantics Fix: Implement atomic first-completion detection with explicit late-arrival ignoring, use proper discriminator pattern not AND-join
3. Deferred Choice Polling (Symptom: Active waiting for external events)
Detection: System polls for external conditions instead of event-driven activation, high CPU usage during wait states Root cause: No event-driven external choice mechanism, treating deferred choice as sequence + condition check Fix: Implement event-based deferred choice with proper external stimulus handling, avoid polling-based workarounds
4. Cycle Termination Deadlocks (Symptom: Infinite loops or stuck processes)
Detection: Workflows with cycles never terminate naturally, require manual intervention, or deadlock on exit conditions Root cause: No implicit termination support or cycle exit condition evaluation Fix: Implement proper cycle semantics with exit conditions, use state-based termination detection
5. Pattern Interaction Failures (Symptom: Unexpected behavior when patterns combine)
Detection: Individual patterns work but combinations crash, undefined behavior at interaction boundaries Root cause: Ad-hoc pattern implementations without unified execution model Fix: Use systems with formal execution semantics (Petri nets, process algebras) or explicitly test all pattern combinations
Worked Examples
Example 1: Multi-Agent Code Review Orchestration
Scenario: Code review requiring parallel analysis (security, performance, style) with first-completion wins logic and iterative refinement.
Pattern identification:
- AND-split: Parallel agent execution
- Discriminator: First satisfactory review wins
- Arbitrary cycles: Revision loops
- Cancellation: Abort remaining agents when one succeeds
Decision walkthrough:
- Need parallel branches? Yes → multiple review agents
- All branches required? No → discriminator pattern (first success wins)
- Iteration needed? Yes → arbitrary cycles for revisions
- External events? Yes → human reviewer can trigger revision
Expert insight: DAG-based orchestrators fail here because they cannot express discriminator + cycles combination. Need state machine or Petri net model.
Novice mistake: Using AND-join instead of discriminator, causing system to wait for all agents even after first success.
Example 2: Dynamic Pipeline with Conditional Stages
Scenario: Data processing pipeline where downstream stages depend on upstream results and data characteristics determine stage activation.
Pattern identification:
- OR-split: Runtime determination of active stages
- OR-join: Synchronize variable number of active branches
- Deferred choice: External quality check determines retry vs. proceed
Decision walkthrough:
- Branching logic? Runtime data determines → OR-split
- Synchronization? Must wait for activated branches only → OR-join
- Decision timing? External quality service → deferred choice
Expert insight: OR-split/OR-join combination requires the join to know which branches were activated by the split. Many systems lack this state tracking.
Novice mistake: Using XOR-split with manual branch tracking instead of true OR-split, losing semantic clarity and introducing bugs.
Example 3: Competitive Agent Auction with Fallback
Scenario: Multiple agents bid on task, first acceptable bid wins, with timeout fallback to direct assignment.
Pattern identification:
- AND-split: Parallel agent activation
- Discriminator: First acceptable bid
- Deferred choice: Timeout vs. bid acceptance
- Cancellation region: Abort auction on timeout
Decision walkthrough:
- Parallel execution? Yes → AND-split for simultaneous bidding
- Completion semantics? First acceptable → discriminator
- External event handling? Timeout can interrupt → deferred choice
- Cleanup needed? Cancel pending bids → cancellation region
Expert insight: This requires discriminator inside deferred choice inside cancellation region. Pattern interaction complexity eliminates most orchestrators.
Novice mistake: Manual timeout handling instead of proper deferred choice, creating race conditions between bid acceptance and timeout.
Quality Gates
- All required coordination patterns identified and mapped to specific taxonomy entries
- System evaluation tests actual pattern implementation, not just feature claims
- Pattern combinations tested for workflows using multiple patterns together
- Workaround complexity measured (>10x baseline = unsupported)
- Decision points explicitly modeled (who/what decides routing at each choice point)
- Synchronization semantics verified (what triggers join completion)
- Cancellation boundaries defined with cleanup semantics
- External event handling mechanisms identified for deferred choice patterns
- Cycle termination conditions specified for iterative patterns
- Implementation gaps documented as architecture information (not just limitations)
NOT-FOR Boundaries
This skill is NOT for:
- Data flow design → Use data pipeline patterns instead
- User interface workflows → Use UI state management patterns
- Sequential scripting → Use basic programming constructs
- Database transaction design → Use ACID transaction patterns
- Error handling → Use exception handling patterns
- Performance optimization → Use performance analysis skills
- Domain modeling → Use domain-driven design patterns
Delegate to other skills:
- Task logic design → Use domain-specific problem solving skills
- Agent capability design → Use agent architecture skills
- Data transformation → Use data processing pipeline skills
- System monitoring → Use observability and monitoring skills
- Security coordination → Use security architecture patterns
Boundary indicator: If you're designing WHAT agents do (task logic), use domain skills. If you're designing HOW agents coordinate (control flow), use this skill.