Workflow Intelligence

The workflow engine processes multi-step LLM workflows as an AsyncGenerator, yielding WorkflowEvents that drive the SSE stream to the client. Each step can reference upstream outputs, inject external context, pause for human review, fan out into parallel sections, or generate competing alternatives.

Template Variable System

All step prompts are templates with {{variable}} placeholders resolved at execution time by resolvePrompt(template, ctx).

Complete Variable Reference

Resolution Logic

The resolver processes each {{token}} match in order:

1. Context injections (consolidations, memory, project.wisdom, claudemd, docs) — sanitized
2. Fan-out context — transient, set per-section during fan-out execution
3. Input resolution — ctx.initialInput or specific fields
4. Step output resolution — digest vs. full vs. notes vs. sections
5. Unresolved tokens — returned as-is {{token}}

Content Sanitization

All user-controlled content injected via context variables passes through sanitizeContextContent():

1. Template escape: {{ is replaced with \{\{ to prevent recursive variable resolution. Without this, content from GitHub files or memory entries could contain strings like {{steps.Analysis.content}} that the resolver would interpret.

2. Suspicious pattern detection: Six regex patterns check for prompt override attempts (ignore previous instructions, you are now, [SYSTEM], etc.). These trigger a console.warn log but do not block the content — observe-and-log, not reject.

ChainContext Architecture

The ChainContext accumulates state across the entire workflow execution. Each loader populates a specific portion; downstream steps reference upstream data through it.

interface ChainContext {
  workflowId: string;
  tenantId: string;
  userId: string;
  initialInput: unknown;
  stepOutputs: Map<string, unknown>;        // keyed by step label
  stepLabels: Map<string, string>;
  stepDigests: Map<string, string>;         // compressed versions
  consolidationContent: string;
  memoryContent: string;
  documentationContent: string;
  documentationByProject: Map<string, string>;
  claudeMdContent: string;
  fileTreeContent: string;
  personaSystemPrompts: string[];
  projectWisdom: string;
  fanOutSection?: string;                   // transient, per-section
  fanOutHeading?: string;                   // transient, per-section
  stepSubOutputs: Map<string, SubOutput[]>; // fan-out results
  stepReviewNotes: Map<string, string>;     // checkpoint notes
}

Loaders run before step execution and populate the context:

1. Consolidation content loaded from the linked consolidation
2. Memory content loaded from linked insights via MemoryPicker selection
3. Project wisdom assembled from consolidation + code patterns for the linked project
4. Documentation loaded from linked repository files
5. Persona system prompts concatenated from all assigned personas

Digest Compression

For steps producing outputs exceeding 2000 characters, an automatic digest is generated via Claude Haiku. The digest retains approximately 15–25% of the original output size.

compression_ratio ≈ 0.15 - 0.25

When a downstream step uses {{steps.Label.content}}, the resolver automatically returns the digest if available. To force the full output, use {{steps.Label.full}}.

The token savings compound across long workflows. For a 5-step workflow where each step produces 3,000 completion tokens:

• Without digests: 4,000 (sys) + 5 × 3,000 = 19,000 tokens
• With digests: 4,000 (sys) + 5 × 600 = 7,000 tokens
• Savings: 63.2%

Digests are generated as a separate async operation after the step completes. They're stored in WorkflowStep.digest and linked from the step output.

Fan-Out Parallelism

Fan-out steps split a source step's output into sections and process each section independently via separate LLM calls.

Configuration on the step:

{
  stepType: "fan-out",
  sourceStepLabel: "Research",          // which step to split
  splitPattern: "###\\s+\\d+\\.",       // regex to detect section boundaries
  promptTemplate: "Analyze this section in depth:\n\n{{fanOut.section}}"
}

Sub-outputs are stored in stepSubOutputs keyed by step label. Downstream steps can reference individual sections via {{steps.FanOut.section[0].content}} or the full sections list via {{steps.FanOut.sections}}.

Sub-outputs appear as tabs in the workflow UI, letting you review each section's analysis independently.

Step Types

Review steps additionally run key point extraction and inject all workflow personas as team context (the only step type that does this).

Context Compression Engine

For workflows that accumulate large amounts of context across many steps, the Context Compression Engine (CCE) manages token budgets deterministically.

The 80K token budget is allocated across sources with a recency-weighted strategy:

RECENCY_WINDOW = 5  // number of recent steps whose full output is preserved

Steps outside the recency window are replaced with their digests. The CCE never calls an LLM for compression — it's a deterministic selection algorithm. This guarantees token overflow prevention without adding latency or cost.

Event Types

The AsyncGenerator yields these event types over SSE:

The client uses an EventSource connection and the useSSE hook to receive and render these events in real time.