Static vs Dynamic Data Workflows

Static vs. Dynamic Workflows

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 Workflow

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.

Dynamic Workflow

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.

What Actually Changes

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

When Dynamic Matters

Agents that need to validate current rules

Multi-system workflows that must stay consistent

Business logic that changes frequently

Compliance rules that update externally