“It’s more like a graph than a pipeline in the real world. The editor has a pipeline programmed in, but every time he sends out a request, it comes back to him, and he makes a stateful, reflective decision — what’s missing, what new information came out, where do I go from here. He might go from step 6 back to step 3, and after step 3 back to step 6.” — Lou
Session context: 2026-06-18_Mastermind — Lou demoed his agentic writing team and the state-machine architecture underneath it, drawn from a state-event matrix he used building real-time telecom systems.
Core Idea
Most AI workflows are built as pipelines: step 1 → step 2 → step 3, each output shoved forward whether or not it’s good enough. Real creative and analytical work doesn’t move that way. An editor doesn’t research, draft, and ship in one pass — he sends the researcher out, reads what comes back, decides it’s thin and sends them again, spots an angle nobody considered and loops the room back to brainstorming, then drafts. The control structure is a graph, not a line: any node can route to any other node based on the current state.
Lou’s implementation borrows a state-event matrix from real-time systems: given the current state and the event that just occurred, the intersection names the function to run next. One controller — the editor — owns the decision. Every sub-agent’s output returns to the editor, who makes “a stateful, informed, reflective decision” before dispatching the next job. Crucially, he doesn’t accept the first response; he fine-tunes each handoff so the next step gets richer input. New ideas that surface mid-stream don’t get discarded to protect the pipeline — they go onto a queue the controller pulls from later. The overall pipeline (research → angle → draft → revise → polish) stays intact as a backbone, but movement through it is non-linear.
The architecture also resolves the deterministic/non-deterministic split cleanly. Steps that don’t need judgment — formatting, merging, validation, JSON/Python plumbing — run as scripts (deterministic, cheap, local). Steps that need to think, reflect, categorize, or write return to the model. The state machine is the seam between the two, and it becomes a portable agent you fully control — no third-party agent framework required.
Practical Application
Audit any multi-step AI workflow you run as a straight pipeline. Find the step where you’ve thought, “that output isn’t good enough, but the process pushed it forward anyway.” That’s where you need a controller. Restructure so a single orchestrator role (the “editor”) receives every intermediate output, decides whether to accept / redo / re-route / queue, and only advances when the input to the next step is strong. Put a queue beside it so mid-process ideas are captured, not forced to resolve immediately. Keep deterministic steps as code; send only judgment back to the model.
Related Insights
- Insight - Skill Orchestration — Forking, Quality Gates, and Pipeline Mechanics Make Chains Actually Run — the pipeline mechanics this evolves from a line into a graph.
- Insight - The Quality Gate Pattern — Embed 9-10 Self-Evaluation at Every Pipeline Handoff — “don’t accept the first response” is the editor enforcing a gate at every node.
- Insight - Code Is for Computation, Inference Is for Judgment — the deterministic/non-deterministic split the state machine sits across.
- Insight - Capability-Architect — Compile a Workflow Into an Inheritable Skill Bundle — the compiler that could emit a state-machine agent as a reusable bundle.
- Insight - Fork vs Spawn — Decide Whether the Child Should Inherit What the Parent Knows — how the editor dispatches each sub-job.
Evolution Across Sessions
Builds on Insight - Skill Orchestration — Forking, Quality Gates, and Pipeline Mechanics Make Chains Actually Run by naming the missing control structure: orchestration chains run, but they run linearly. The new development is the editor-led state machine — a stateful controller that treats the workflow as a graph, re-routes freely, queues emergent work, and refuses first-draft handoffs. Lou is using the writing team as a testbed to extract a general state-machine framework members can scaffold into any task (open thread).