In a static workflow, business logic is code, and changing a rule means shipping a release. In a dynamic workflow, business logic is data the code reads at runtime, so the same pipeline behaves differently tomorrow without anyone deploying.
Static workflows hardcode rules into the execution logic. Dynamic workflows query current rules at runtime.
def deduplicate_records():
# Strategy hardcoded
return db.query("""
SELECT DISTINCT ON (email) *
FROM user_events
ORDER BY email, created_at DESC
""")This runs the same way every time. If the deduplication strategy changes (now use composite key on email + device_id), the code must change. This is why static pipelines break when business logic evolves.
def deduplicate_records():
# Query current rules
rules = context.get("deduplication_strategy")
# rules.key_fields: ["email", "device_id"]
# rules.sort_priority: "created_at DESC"
return db.query(f"""
SELECT DISTINCT ON ({', '.join(rules.key_fields)}) *
FROM user_events
ORDER BY {', '.join(rules.key_fields)}, {rules.sort_priority}
""")Same workflow code. Different execution based on current deduplication strategy. When rules update, behavior changes without redeployment. This approach requires separating decision logic from pipeline code.
Static: Business logic is code
Dynamic: Business logic is data
Static: Rule changes require deployment
Dynamic: Rule changes update metadata
Static: Each system reimplements logic
Dynamic: Each system queries shared context
Agents that need to validate current rules
Multi-system workflows that must stay consistent
Business logic that changes frequently
Compliance rules that update externally
Related: What is a context-aware workflow?