“I don’t have to now define an architecture. I have the state machine framework. So I just say, break it down into a work breakdown structure, and then generate all the skills and agents and state machine, and a simple UI, and we’re good to go.” — Lou
Session context: 2026-07-02_Mastermind — Lou demoed a work-in-progress that turns a grilling interview into a runnable state-machine app, and framed it as the thing that unifies “all the bits and pieces you’ve seen me working on.”
Core Idea
Once you fix two things — the framework (a finite state machine) and the format (a PRD written as a work breakdown structure) — building an app stops being an architecture problem and becomes a conversation. That’s the move. Lou has settled on the state machine as his universal runtime (Insight - Build the Agent as a Graph, Not a Pipeline — The Editor-Led State Machine): states as rows, events as columns, and each cell names the skill or agent to run next. Because that scaffolding never changes from app to app — “the infrastructure and the framework is all going to be the same, you’re just going to have a different set of steps” — the only thing left that varies is which skills, in what order, with what transitions. And that can be elicited.
So the generator has two halves. The front end is a grilling interview (his wbs-prd command) that brainstorms the app’s job, constraints, and blind spots with you, then emits a product requirements doc structured as a work breakdown structure — a tree decomposed to atomic units of work. The back end is a coding algorithm reduced to a single recursive goal: process every element of the work breakdown structure until it either decomposes further or completes as code. Walk down the tree, and at each leaf either reuse a skill already in your library or generate a new one; walk back up, and you have every skill and agent written plus the state table that wires them together. “By the time you come back out of the tree, you have all the skills and agents written, and you just run it.”
The payoff Lou keeps circling: the conversation is the only human input left. “I’ve coded the entire program, and all I had to do was the front-end conversation.” The state machine also earns its keep at runtime, not just at build time — because it’s a directed graph, the orchestrator can jump from any state to any other based on the result it gets back, so a bad outline sends the machine back to reset assumptions rather than forcing a broken draft forward (the non-linear editor behavior). Two deliberate governors: it can consult and extend a shared skill library instead of re-creating capabilities, and the self-improvement loop is held behind a human gate — it logs improvement ideas rather than rewriting itself, “because I think it can get really out of control.”
Practical Application
Before you build your next AI tool, stop and define your reusable substrate once: pick a control structure (a state/event matrix is a strong default for any non-linear process), and pick a fixed PRD format that a generator can consume mechanically (a WBS tree is one). Then split the build cleanly. Run a grilling interview first — job, constraints, blind spots, the skills and experts the app needs — and force the output into that fixed PRD format. Hand the PRD to a coding loop whose only instruction is “recursively satisfy every node.” Gate two things by hand: whether to reuse a library skill vs. generate a new one, and whether any self-improvement idea actually ships. Everything else is conversation.
Related Insights
- Insight - Build the Agent as a Graph, Not a Pipeline — The Editor-Led State Machine — the runtime this generator emits; that insight is the machine, this one is the machine that writes the machine.
- Insight - Explore the Whole Tree Before You Write the PRD — the grilling front end; here the tree exploration is formalized as the WBS that becomes the spec.
- Insight - Write Loops, Not Code — Goal-Seeking Loops Are the New Atomic Unit of AI Work — the recursive “process every node until done” back end is that loop applied to a tree.
- Insight - Use a PRD-First Workflow to Build Apps Without Getting Lost — the PRD-first discipline, now with a machine-consumable structure so the PRD is the program.
- Insight - Use the LLM as the UI — Conversation as Interface for Internal Tools — why no UI needs designing: the interface is always the conversation.
- Insight - Capability-Architect — Compile a Workflow Into an Inheritable Skill Bundle — the same compile instinct, aimed at generating a whole runnable app rather than one bundle.
Evolution Across Sessions
Builds directly on Insight - Build the Agent as a Graph, Not a Pipeline — The Editor-Led State Machine ([2026-06-18]), which established the editor-led state machine as the runtime model. The new development is that Lou has turned that runtime into a target for automatic generation: a grilling interview → WBS-structured PRD → recursive generation of all skills, agents, and the state table. It also closes the loop with Insight - Write Loops, Not Code — Goal-Seeking Loops Are the New Atomic Unit of AI Work ([2026-06-25]) — the coding step is now literally one loop over a tree. Open thread: Lou intends to release this to members so non-coders can build finite-state apps by conversation alone, and to fold in his own skill-writing skill so generated skills carry his design rules (eigenthinking, outside-the-modal) rather than Claude’s defaults.