Why AI novels fall apart at chapter nine

We tried to write a novel in a single conversation with a model. Chapters one through eight read well enough. Chapter nine is where it broke. A character who died in chapter seven walked into a room and spoke like anyone else. Another explained a fact the reader only learns four chapters later. The prose was still clean, which made it worse: nothing looked broken at the level of the sentence.

The first instinct was to fix the prompt. We added a paragraph listing every character, a rule against contradictions, an instruction to preserve the voice. Chapter ten came out slightly better and chapter eleven worse. The model had not forgotten the instruction. It no longer had the story.

What actually happens around chapter nine

A conversation is not a document. On every turn the model receives the whole exchange again, and the context window has a limit. Anthropic's documentation on context windows says that as token count grows, accuracy and recall degrade, a phenomenon it calls context rot. When a conversation approaches the limit, compaction summarises the earlier part so it can continue. Claude Code does this automatically, and its cost documentation describes auto-compaction as summarising older history when the session nears the window.

A summary is written for a general reader of the conversation, not for the next chapter. It keeps what happened and loses what mattered. Chapter nine is not a magic threshold. It is roughly where a manuscript reaches the limit of a workflow that keeps its state in chat, and the more context you load at the start, the sooner it arrives.

How it fails, specifically

The prose drifts toward the average

A voice lives in examples, not in adjectives. When the model can no longer see the narration from chapter two, "write in the same voice" becomes a description, and descriptions converge on the statistical middle. Sentences get a little longer, metaphors get safer, the narrator starts explaining feelings that were previously shown. Each chapter becomes a fresh approximation of the voice instead of a continuation of it.

Critique leaks into drafting

If a review of chapter four sits in the same conversation, it stays in context. The model writing chapter five has read "the pacing sags in the middle" and writes defensively: shorter scenes, more incident, a paragraph explaining why the scene matters. An observation about one draft becomes an instruction for the next. A separate critic with a separate context is not a formality. It is what keeps the two jobs from blending.

Continuity dies inside the summary

Compaction keeps plot and loses texture. "Mara confronts Ionescu at the harbour" survives. The facts that Mara is left-handed, that she promised her brother she would not go back to the harbour, and that the harbour closes at dusk do not. Those details are exactly what later chapters need. The model is not lying when it writes that the harbour is busy at midnight. It is working from a summary that never contained the constraint.

A dead character reappears

The summary says Mara dies in chapter seven, but her name is still in the character list and in references such as "Mara's flat". The model can generate her as present. Or it does not know about the death at all, because that chapter fell out of the window. There is no lookup into memory. The only evidence is whatever remains in context.

Knowledge arrives before its chapter

Who knows what, and when they learned it, is state rather than text. A summary saying "the conspiracy is revealed" does not record that only two characters were in the room. So a third one reacts to it in chapter ten. A reader feels the mistake immediately, even without being able to point at it.

Why a better prompt cannot fix this

A prompt is a rule. State is data. "Never contradict an earlier chapter" is a rule the model cannot obey without the earlier chapters. Repeating it more forcefully changes the tone of the failure, not its cause. Longer prompts also make the problem arrive sooner, because a larger initial context leaves less room before compaction. Tuning the prompt is optimising the wrong artifact.

Keep state in files, not in the conversation

The mechanism that works is unglamorous. Move everything that must survive out of the chat and into files that are read at the start of every chapter.

• Canon: characters, places, timeline, the rules of the world.
• Character state: alive or dead, location, what they know, what they want in the current chapter.
• Open promises: setups that must pay off, with the chapter where each was planted and the earliest chapter where it can resolve.
• Voice: a short profile measured from the author's own prose, not a list of adjectives.
• Chapter log: one entry per finished chapter, recording what changed in the world and in each character's knowledge.

A chapter session starts by reading the state card, drafts, then writes the changes back. The conversation becomes disposable. If it is compacted or lost, the next session rebuilds from the files. That is the difference between a model that remembers and a model that can be reminded.

The card should fit on one screen. A canon document of forty pages is just another context problem. Load the few facts the next chapter depends on, and keep the rest in files that a gate opens when it needs them.

Gates that read the files and refuse

A gate is a check with a pass or fail result and a consequence. It is not a suggestion inside a prompt. Three gates cover most of the problem:

• An approved outline before any prose. The chapter cannot start until the outline exists and has been accepted.
• A continuity check before a draft is accepted. It reads the draft against the state files and returns concrete violations, with the chapter and the passage.
• A reader pass before export. Someone who did not watch the draft being written reads it against a rubric fixed in advance.

A violation has to be specific enough to act on. "Continuity problem in chapter twelve" is not useful. "Chapter twelve, paragraph four: Mara speaks, but the state card records her death in chapter seven" is. The same applies to knowledge: "Ionescu mentions the ledger, which he only learns about in chapter fourteen" tells the writer exactly what to change.

The important property is that a failed gate stops the loop. A warning the model is free to ignore is not a gate, it is decoration. When the check fails, the draft goes back with the list of violations, not with an instruction to try harder.

Separate the writer from the critic

Role isolation means the writer never sees the critique and the critic never writes prose. In practice that means separate contexts and separate output files. The critic reads the chapter and writes a report. The writer reads the report and the state files, and nothing else from the critic's process. It is also cheaper: the critic's long analysis does not have to stay in the writer's context, where it would both bias the prose and consume the window.

Let a script answer the mechanical questions

Some questions do not need a model. Is this character dead at this point in the timeline? Has this name been used before? Does the chapter mention an object that was destroyed? Is a fact referenced before the chapter that establishes it? A small script over plain text files answers those exactly, in milliseconds, at no token cost.

We keep the script deliberately small and dumb. It does not judge prose. It checks names, dates, chapter numbers and a knowledge ledger: facts mapped to the chapter where each character learns them. A model can do this too, but it costs tokens and it can be wrong with great confidence. The mechanical layer should be deterministic. Save the model for the work that requires judgement.

If a question has an exact answer, do not ask a language model for it.

This is engineering, not a model upgrade

None of this makes the prose better. It stops specific failures, which is a different job. A stronger model raises the ceiling for a single chapter. It does not hold state across thirty chapters, and it should not be asked to. State belongs somewhere durable. The discipline is real work: file formats, gates, a small engine, the habit of writing state back after every chapter. But the work compounds, and it is the difference between a demo and a manuscript.

A working implementation

Vellum is our implementation of this approach, at vellum.danubelabs.net. It is a Claude Code plugin: one command runs the chapter loop, three hard gates decide whether the loop continues, sixteen agents hold isolated roles, and a Python engine checks continuity so the model does not spend tokens on it. It is not a model, and it does not write better sentences than the model inside it. It is the scaffold that keeps the state and refuses to continue when the state is missing.

Where to start

If you are building a long-form workflow, start with the state files, not the prompt. Write down what must be true at the start of every chapter. Then write the gate that checks it. Then let the model write. The prompt is the last thing to tune, and usually the least important.

Danube Labs builds AI systems that have to hold up over months, not just in a demo. See our AI systems work or book a free intro call.