Static Workflow Configuration
Overview
Section titled “Overview”Static Workflow Configuration is the practice of storing curated rules, standards, checklists, and instructions in workflow initialData variables. These are deliberately placed so the agent sees them on every relevant step, ensuring consistent behavior throughout the workflow.
When to Use
Section titled “When to Use”Use static workflow configuration when:
- Agent must follow specific rules consistently across multiple steps
- Instructions are curated and stable (not generated during execution)
- Content is essential for workflow quality (not optional reference data)
- You need the workflow engine to guarantee delivery of instructions to the agent
How It Works
Section titled “How It Works”Start node initialData: planning_standards: "1. Each step must have tests... 2. No code in plan..." code_quality_rules: "1. Fix root cause, not symptoms... 2. Test after changes..." validation_checklist: "□ Requirements met □ Tests pass □ No regressions"
Step directive: "Create plan following {{planning_standards}}"→ Workflow engine injects full text into directive→ Agent sees rules every time, no extra I/O, no hallucination riskWhy Not Files?
Section titled “Why Not Files?”Storing critical instructions in external files and asking the agent to read them creates Anti-Pattern #12: Externalizing Critical Instructions:
| Approach | Delivery guarantee | I/O cost | Hallucination risk |
|---|---|---|---|
| initialData variable | ✅ Engine injects into directive | None | None — text is literal |
| External file | ❌ Agent may skip or read selectively | Extra read per step | High — agent may recall from memory |
Examples
Section titled “Examples”Good: Planning Standards in Development Workflow
Section titled “Good: Planning Standards in Development Workflow”{ "initialData": { "variables": { "planning_standards": { "description": "Rules agent must follow when creating plans", "value": "PLANNING STANDARDS:\n1. Each step implements functionality + tests\n2. No testing-only steps\n3. Verification criteria required..." } } }}Directive references: "Create development plan following {{planning_standards}}"
Good: Validation Checklist
Section titled “Good: Validation Checklist”{ "initialData": { "variables": { "validation_checklist": { "description": "Quality gates for code review", "value": "CHECKLIST:\n□ All tests pass\n□ No type errors\n□ Coverage maintained\n□ No security issues" } } }}Not This Pattern: Dynamic Extraction Results
Section titled “Not This Pattern: Dynamic Extraction Results”// ❌ This is Anti-Pattern #7, not static configuration{ "inputSchema": { "extraction_results": { "type": "object" } }}// Data generated during execution, grows unboundedlyDistinction from Anti-Pattern #7
Section titled “Distinction from Anti-Pattern #7”| Characteristic | Static Configuration (✅) | Dynamic Data Abuse (❌) |
|---|---|---|
| When created | At workflow design time | During execution |
| Content source | Curated by workflow author | Generated by agent/tools |
| Size | Known and bounded | Potentially unbounded |
| Purpose | Guide agent behavior | Pass data between steps |
| Changes | Only when workflow is edited | Every execution |
Size Guidance
Section titled “Size Guidance”Static configuration is acceptable at any size if the content is:
- Deliberately curated (not auto-generated)
- Stable across executions
- Essential for agent behavior
Real-world examples: planning_requirements (6.7KB), code_quality_principles (4.4KB), anti_pattern_catalog (3.2KB) — all legitimate static configuration in production workflows.