Static Workflow Configuration

Overview

Static Workflow Configuration is the practice of declaring curated rules, standards, checklists, and instructions as global variables in the workflow variableRegistry with a default value. These are deliberately placed so the agent sees them on every relevant step, ensuring consistent behavior throughout the workflow.

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

variableRegistry (with default values):
  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 the registry default into the directive
→ Agent sees rules every time, no extra I/O, no hallucination risk

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
variableRegistry default	✅ 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

Good: Planning Standards in Development Workflow

{
  "variableRegistry": {
    "planning_standards": {
      "type": "string",
      "description": "Rules agent must follow when creating plans",
      "default": "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

{
  "variableRegistry": {
    "validation_checklist": {
      "type": "string",
      "description": "Quality gates for code review",
      "default": "CHECKLIST:\n□ All tests pass\n□ No type errors\n□ Coverage maintained\n□ No security issues"
    }
  }
}

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

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

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.