A Multi-Agent Narrative Engine With a Planner, Writer, and Validator
A narrative generation system that splits writing into planner, writer, and validator sub-agents coordinated over tmux with SQLite as shared state.
NovelEngine is a narrative agent system. Instead of asking one model to hold an entire story in its head and produce coherent prose in a single pass, it splits the work across specialized sub-agents that hand off to each other. The package is small on purpose: an orchestrator prompt, the sub-agent prompts, tmux runner instructions, and a SQLite schema. You drop it into an agent and it ingests.
Why Split the Roles
Long-form narrative is where single-agent generation tends to fall apart. The model drifts, forgets what it established three chapters ago, and produces text that reads fine locally but does not hold together as a whole. The bet behind NovelEngine is that these are actually different jobs and should be different agents.
A planner decides what happens and in what order. A writer turns those beats into prose. A validator checks the output against what was supposed to happen and against what has already been written. Separating the roles means each prompt can be sharp about one responsibility instead of vague about all of them. The writer does not have to also be the continuity police, and the planner does not have to also be a stylist.
SQLite as the Shared Memory
The piece that makes the hand-offs work is the SQLite schema. The sub-agents do not pass the whole story back and forth in context, which would balloon fast and lose fidelity anyway. They read and write structured state to a database. Plans, drafts, and validation results all live in tables the agents can query. That gives the system a durable memory that survives any single agent's context window and lets a later step reason about an earlier one without re-reading everything.
Running it over tmux keeps the orchestration honest and observable. Each agent is a real process in a pane you can watch, rather than a hidden call buried inside a framework. When something goes sideways you can see which role produced it.
The takeaway I would carry forward is that giving agents a shared database beats trying to keep everything in context. Once state is external and structured, the roles stay small and the whole pipeline becomes something you can inspect a table at a time.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →