DAG Orchestration & SWARM

The Brainstorm Reactor does not operate on a simple "chat transcript" loop. Instead, complex cognitive workflows (Recipes) are executed as Directed Acyclic Graphs (DAGs). This architecture allows the engine to decouple individual reasoning steps, isolate system prompts, and orchestrate massive parallel AI operations.

The Recipe as a Graph

A Recipe is fundamentally a network of Methods (nodes) connected by Dependencies (edges).

When a user triggers a Recipe in the UI, the Orchestrator compiles the DAG and determines the execution order. If Node B requires the output of Node A, it waits. If Node B and Node C both only require the initial user input, they execute simultaneously.

[!NOTE] By forcing AI operations into discrete nodes, we prevent context degradation. An AI generating code (Node C) is only fed the structural blueprint from the Architect (Node B), rather than the entire polluted history of brainstorming that happened in Node A.

SWARM Execution (Parallel Processing)

The true power of the DAG architecture lies in the SWARM.

When the Orchestrator identifies nodes without overlapping dependencies, it fires them concurrently via Server-Sent Events (SSE).

Practical Example: The "Red Team" Simulation

If a user submits a business idea, a Recipe might spin up three antagonistic AI personas:

1. The Cynic (Security flaw analysis)
2. The Competitor (Market cannibalization)
3. The CFO (Financial viability)

Because these three personas do not rely on each other's output, the Orchestrator initiates a SWARM. All three models process the input simultaneously, and the UI streams their responses in parallel vertical columns. This reduces a 45-second linear wait time to just 15 seconds.

Context Merging & Passthrough

Once a parallel SWARM resolves, the DAG often converges back onto a single node (e.g., a "Synthesizer" or "Judge").

The Orchestrator automatically handles the Context Merge. It takes the binary output, markdown, or JSON payloads from the previous nodes, injects them as structured <context> blocks into the final node's prompt, and triggers the final execution.

Reliability Guards

Running multi-agent SWARMs places heavy strain on both Serverless Functions and upstream Provider APIs. To guarantee stability, the DAG Orchestrator utilizes:

• Provider-Aware Stale-Stream Watchdogs: If one node in a SWARM hangs mid-generation, a custom watchdog terminates the stalled stream after a model-specific timeout (e.g., 25s for reasoning models, 5s for fast logic models), allowing the rest of the DAG to proceed.
• Null-Chat Protocol: State is maintained in the Next.js frontend state manager (usePureStreamWorkflow), not in a centralized backend database. This ensures parallel requests don't cause database race conditions.

// Conceptual Flow of a Reactor DAG
Input -> [ Node A: Architect ] -> (Wait) -> [ Node B: Frontend ] (Parallel)
                                            [ Node C: Backend  ] (Parallel)
                                                      |
                                                   (Merge)
                                                      v
                                        [ Node D: Final Code Review ]