This is the second post in a series about the systems I’ve built to co-write a “meganovel” (targeting 1,000,000 words or more) with an AI agent. The first post covers the context management problem and the search/MCP tooling I built to solve it. This one is about how we plan together, how I think about the collaboration, and the architectural contract that keeps the robot from surfacing things it shouldn’t.

If you’ve used an agentic coding tool, you probably have picked up the flow of gathering context, building a structured understanding of the problem, producing a spec, then letting the agent execute autonomously from the spec. I use the same process to write chapters of a novel. The “problem” is a chapter. The “spec” is a beat sheet with dialogue intent and character notes. It’s a little more fun than a software spec (although some engineers might say the opposite), but it’s more the same than not.

Planning a Chapter#

The planning process has four phases. Each one has a direct parallel to spec-driven software engineering. I don’t think that’s a coincidence. The pressures are the same: early on, I gave the robot loose briefs and got loose output. I tightened the briefs and the output improved. I formalized the tightening into a reproducible process, and encoded it in a skill the robot loads. It’s not perfect - prose isn’t code, and as I said in the first post, failure modes are more varied and subtle than a testable code failure. But it’s much more consistent from round to round, and much better. It also sounds and feels more like something I’m writing, even though the sentence- and paragraph-level generation is going to the robot.

Context Gathering#

Before the robot asks any planning questions, it assembles a briefing. I start with a draft plan with high-level notes on what the chapter needs to do. I like to write dialogue, so I usually give it a lot of dialogue examples and flow. It reads this file, and it also reads the state file (where the story is right now), the preceding sequences, and the relevant character sheets. It also runs MCP queries to establish timeline position, relationships called out in the draft plan, and other possible context of use in the narrative. This produces a structured briefing: character states, relationship dynamics, world state, open threads, unresolved items. The robot shares the context list with me first: “I’ll gather from these files; any additions?” I can steer the retrieval before it begins.

It’s the same thing an agentic coding tool does when it reads the codebase before proposing a change, although I’d say more complex. The connections between logical groupings of language are unambiguous and clear in a codebase, unless the engineering history is very weird. You should have function call, interface, composition, inheritance relationships that clearly signal this code connects to this other code, so keep reading. The relationship of one of my characters to the institutional history of an imaginary university that I mentioned once 100,000 words ago is a little harder to suss out. If the robot works without understanding the current state, it produces worse output. In fiction, “worse output” means continuity errors, flattened relationships, or scenes that contradict what came before.

Collaborative Interview#

The robot asks one question at a time. What should the reader feel at the end of this sequence? What’s the structural shape? How do we play out these beats? When you say in the draft plan that you want “imagery” in this scene, what does that look like? Each answer informs the next question. This is a structured exploration of design space, where I provide creative constraints and the robot proposes options within them.

I emphasize “one question at a time” because the default behavior is to be overwhelming. The robot wants to ask twelve questions at once, or present a complete plan for your approval. I’ve learned to insist on the sequential interview. It produces better plans because each answer shapes the next question, and it keeps me engaged as a creative participant on a closer level of detail, rather than a reviewer approving someone else’s work.

The Plan File#

The conversation produces a structured plan document: timeline anchors, beat-by-beat breakdowns, character focus, continuity notes and key background reading, resolved questions and open ones. This is the spec. The robot generates from it.

Intent vs. Literal#

One of the subtler problems in the planning process: when I write dialogue in a plan, it looks like dialogue but it’s actually intent. If I write Bram: "We didn't know. It wasn't our war." the robot will transcribe it verbatim into the draft, producing staccato thesis-statement exchanges instead of organic conversation.

So the plan uses [INTENT: ...] tags to distinguish “what this conversation should accomplish” from “literally say these words.” It’s the difference between a user story and acceptance criteria. The tag tells the robot: this is the emotional shape of the exchange, not a script. Find the words yourself.

The Quality of the Spec Bounds the Quality of the Output#

The lesson for anyone building agentic systems: invest in the planning layer. Make it structured, collaborative, and auditable. The agent generating from a good plan produces dramatically better output than one generating from a vague prompt, regardless of model capability. This is true for code. It’s true for prose. I suspect it’s true for anything you ask an agent to do autonomously.

The Showrunner#

From the get-go of this process, I wanted to have a frame for it. Our understanding of creative engagement with AI at this point in our world is, to put it mildly, fraught. I wanted to make sure I could think and speak clearly about how I’m relating to it, what my role is, what elements of the process I consider “mine.” I’m not the writer of this novel. The robot isn’t the writer, either. One participant has the creative vision. The other has the generative capacity. Both contribute creatively.

In television, a showrunner creates and maintains the creative vision but works collaboratively with writers, directors, and actors, all of whom have creative roles. The showrunner doesn’t write every script, but every script serves the showrunner’s vision. This felt like the right metaphor, and it’s shaped how I interact with the robot at every level.

In practice: the planning process is deeply collaborative. I provide the trajectory of the narrative, spans of dialogue, psychology notes, key plot beats, the emotional shape of what I want. The robot proposes structural choices, suggests character moments, raises continuity considerations. We go back and forth until there’s a detailed spec. Then the robot generates autonomously from that spec.

What surprised me most is that the robot contributes genuinely creative ideas. In one case, the robot introduced a background character in a scene, just a detail, a man taking notes. I saw something in it. I took that character and developed him into one of the novel’s key figures. The generation isn’t paint-by-numbers execution of a plan. It has innovations I can run with. The collaboration is hierarchical - only one of us is driving - but it is a collaboration.

Plan Boldly, Revise Mechanically#

The planning prompt explicitly tells the robot to maximize creative range. Pitch unexpected connections. Challenge my assumptions. Suggest directions I haven’t considered. This might sound like a strange instruction for a system that also has hundreds of lines of style constraints, but the separation is deliberate.

As we’ll discuss in the next post, I’ve built pipelines that guardrail text generation for consistency. We let up on guardrails during planning. Planning is where bold ideas belong. The robot should take risks during planning, because the revision pipeline catches problems after generation. If you constrain creativity during planning, you get safe plans that produce safe prose. If you constrain creativity during revision, you get bold plans that produce polished prose. I’d rather start with too much and cut than start with too little and wonder what I missed.

This separation of concerns, creative latitude during planning and mechanical precision during revision, is the design philosophy behind the whole system. The next post will get into the revision side.

The Three-Layer Problem#

There’s an architectural problem that sits underneath the collaboration model, and it took me a while to diagnose it.

LLMs collapse the distinction between “context for the agent” and “material for the output.” If you give the robot background knowledge, it will surface that knowledge in the output. Every time. It treats context as material to be deployed rather than subtext to inform choices. (For example, in an earlier draft of this post, the robot started referencing the generative pipeline in the section above like it knew about it, even though we won’t get to that until the next post).

I mentioned in the first post that I built the characters from qualities of the Sefirot, Kabbalistic archetypes, so the robot would have easy reference to archetypal models. The robot loved this. Too much. Characters started “giving off Hesod energy” or being described as “completely Binah.” Every session, I had to remind it: this isn’t for the reader. They don’t know what these words mean. Writing involves not showing all your cards.

The same problem appeared in other ways. Characters would call each other by names they hadn’t learned yet. They’d think about events five chapters in the future. The robot had access to the full timeline as defined, and it couldn’t resist using it.

The Three-Layer Solution#

The fix was architectural. I separated the project into three content layers with an explicit contract:

Scaffolding contains the story-generation tools: archetypal mappings, thematic structures, psychological dynamics between characters, tension guides, future directions. The robot reads scaffolding before generating, but the contract is explicit: this layer is invisible to the reader. It informs choices. It never appears in prose.

Reference contains narrative truth: what exists in the story world, what characters know, what has happened. This is material the robot can surface, because it represents facts within the fiction.

Narrative is the finished prose.

This wasn’t designed upfront. It emerged from the repeated experience of the robot collapsing “things that inform the writing” and “things that appear in the writing” into one pile. Once I separated scaffolding from reference, generation fidelity improved significantly. The robot could use psychological notes about a character’s development without having the character deliver a monologue about their own psychology.

The parallel for engineers building any agentic system: if your agent uses background knowledge to shape decisions, you need an architectural boundary between “context for the agent” and “material for the output.” The LLM will not maintain that boundary on its own. You have to build it into the structure.

This series was written using the process it describes. I planned the structure with Claude Code in an interview-style session, provided editorial direction and personal detail, and edited each draft. The agent drafted from the shared plan and incorporated my feedback across revision passes.