Skip to content

Static Workflow Configuration

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.

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
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 risk

Storing critical instructions in external files and asking the agent to read them creates Anti-Pattern #12: Externalizing Critical Instructions:

ApproachDelivery guaranteeI/O costHallucination risk
initialData variable✅ Engine injects into directiveNoneNone — text is literal
External file❌ Agent may skip or read selectivelyExtra read per stepHigh — agent may recall from memory

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}}"

{
"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 unboundedly
CharacteristicStatic Configuration (✅)Dynamic Data Abuse (❌)
When createdAt workflow design timeDuring execution
Content sourceCurated by workflow authorGenerated by agent/tools
SizeKnown and boundedPotentially unbounded
PurposeGuide agent behaviorPass data between steps
ChangesOnly when workflow is editedEvery execution

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.