Multi-Agent Writing and Continuity Governance for Long-Form Novel Generation

The difficulty of long-form narrative automation is not “can it write a decent paragraph,” but “does it still read like the same book after hundreds of chapters.” Many practitioners use general-purpose conversational generation to write ultra-long serials, with common results: the first few chapters adhere to the settings, but the middle and later stages contain only plot summaries; character motivations conflict; timelines and geographical relationships distort; and the writing style fluctuates. The cost of a single API call seems low, but rework, manual patching, and reader churn are often more expensive than token fees. To write a long text into a deliverable serial, creation must be treated as a stateful, QA-checked, versioned pipeline, rather than a single conversation.

Why Single Agents Fail in Ultra-Long Form

No matter how large the context window is, it cannot hold all the facts of an entire novel. In the later stages, the model relies more on recent chapters and keywords in the prompt, diluting early constraints, leading to three types of systemic failures.

The first is framework collapse. The outline is only “read” at the beginning, and subsequent chapters freelance based on local interests, gradually deviating from the main plot progress, power dynamics, and stage goals. The second is memory collapse. Supporting character names, catchphrases, injuries, promises, and unresolved mysteries are not stored structurally; the writer can only paraphrase based on vague impressions, reducing details to “probably happened.” The third is flat pacing. Without external metrics for information density, conflict intensity, and emotional arcs, the model tends to advance with similar sentence patterns, making climaxes and buffers indistinguishable.

Therefore, the engineering goal should be clear: every chapter is written on the same set of retrievable facts and passes explainable checks before being stored, rather than pursuing a single generation that “looks complete.”

Externalizing Novel State from Prompts

Long-text continuity cannot rely solely on system prompts. A more robust approach is to maintain a set of “fact files” (structured truth), stored separately from the body text, versioned, and updated incrementally by chapter. It is recommended to split these into at least the following objects:

• World and Rules: Era, geography, ability boundaries, taboos, and costs to prevent power or institutional inflation across chapters.
• Character Cards: Goals, fears, relationships, known information, and current status; distinguishing between “reader-known” and “character-known” info.
• Timeline and Scene Index: Absolute or relative time, location, and present characters to prevent impossible movements within the same day.
• Foreshadowing Ledger: Setup chapter, expected payoff window, current status (open, deferred, paid off, voided), and constraints on the payoff method.
• Outline and Beats: Volume, act, chapter goals, must-happen events, and allowed side-plot quotas.
• Style Anchors: Narrative perspective, sentence length preferences, dialogue ratio, and banned expressions, explained with a few contrast samples rather than vague adjectives.

These files should be program-diffable. After a chapter is finalized, truth should only be updated via “revision proposals” to prevent the writer from secretly changing settings in the body text. Object storage is suitable for storing body text and large files, while relational or document databases suit queryable entities. The key is that every generation can pull the minimum necessary context by entity ID, rather than stuffing the entire book into the prompt.

An illustrative chapter task structure can be very simple:

chapter_id: 128
goal: The protagonist confirms the informant's identity at the market, but must not expose the mastermind
must_keep: [wounded left arm, unaware of the secret letter's content, rainy night continues]
forbidden: [early payoff of foreshadowing F-17, adding new enhancement abilities]
pov: third-person limited
max_new_proper_nouns: 2

Writing constraints into the task ticket is more effective than appending “please note continuity” at the end of a long prompt.

Multi-Agent Division: Planning, Orchestration, Writing, Review, Revision

When one model plays all roles, it easily grants itself a pass. The pipeline separates conflicts of interest, and every step’s input and output can be recorded.

Planning handles volume-level and chapter-level goals, producing only beats and constraints, not body text. It answers “what must this chapter advance, and what must it not touch.” The Orchestrator tailors the truth files into a writing package: relevant characters, recent timeline, open foreshadowing, style summary, and the hard-connect sentence from the previous chapter’s end. Writing produces the draft based solely on the writing package, prohibiting free retrieval of “I remember it seemed like.” Review checks against a detection checklist to issue a problem list, with each issue bound to evidence (which truth file, which body paragraph). Revision only handles the problem list, without taking the opportunity to rewrite the main plot.

Context budget must be monitored during handoffs. The writing package should have a hard cap: for example, summaries of the last three chapters, full text of relevant entities for this chapter, and only short retrieved evidence for earlier content. If limits are exceeded, continue trimming rather than silently truncating, which causes the latter half to “write vaguely.” Orchestration failure should abort the chapter, rather than letting the writer fabricate with insufficient information.

Human intervention points must also be designed. High-risk chapters (volume finales, identity reveals, major character deaths) default to manual confirmation of outlines and review conclusions; low-risk daily chapters can pass automatically, but the sampling rate cannot be zero. Container tasks, object storage, message queues, and log monitoring commonly found on cloud platforms like Baidu AI Cloud are sufficient to support this asynchronous pipeline: chapter tasks are queued, roles consume statelessly, artifacts are stored, and failures retry with alerts. This uses general cloud capabilities, so business logic need not be tied to any proprietary API.

Detection System: Define Failure Before Generation

Poor quality often stems from a lack of an executable failure definition. It is recommended to make detection an independent rule-and-model hybrid check from the writer, outputting locatable issues rather than vague scores.

Character Memory: Are all state changes in this chapter written back to character cards? Do abilities not present in the cards or actions by dead characters appear? Continuity: Do time, location, attendee lists, injuries, and items conflict with the timeline? Foreshadowing: Are newly planted ones registered? Are alarms triggered for un-paid expired ones? Are payoffs revealed early? Outline Deviation: Are the goal verbs for this chapter completed (e.g., “confirm identity” cannot be changed to “immediate showdown”)? Is the side-plot length over quota? Pacing: Number of scene switches, whether conflicts have a rise-climax structure, whether there are consecutive chapters with only summaries and no scenes. Emotional Arc: Do character emotions jump without triggering events? Style: Perspective breaches, sudden explanatory tone, banned words, and obvious deviations from anchor samples.

Detection results are divided into blocks and warnings. Blocking items (character contradictions, early payoff of core foreshadowing) must be revised before entering the next chapter; warning items can accumulate to be processed at the end of the volume. This prevents the cost explosion of “rewriting every chapter” and stops errors from snowballing.

Style Imitation: Constrain, Don’t Replicate

The reasonable goal of style transfer is a stable narrative voice: person, distance, dialogue density, and the ratio of description to action. The approach is to extract actionable features from authorized reference texts to form a short spec, such as “use fewer abstract judgment sentences; prioritize carrying information through actions and dialogue.” Do not attempt to imitate any copyrighted work sentence by sentence, nor put an author’s name in the prompt as an on/off switch. Reference materials should come from self-owned manuscripts or authorized texts. Extracted results are reviewed and frozen as a style version, iterating with the book rather than recalculating every chapter.

Cost, Quality, and Stop Conditions

The bill for ultra-long forms is primarily composed of ineffective chapters. Levers to control costs are: reducing rewrite times, limiting context per chapter, caching stable truth summaries, using smaller generation configurations for low-risk chapters, and using stricter but shorter inputs for reviews. Do not trade “write the whole book at once” for a low unit price; chapter-level submission and stop-on-failure are usually cheaper.

Stop conditions should be specified in advance: outline deviation exceeds the threshold for consecutive chapters, the number of open foreshadowing items is out of control, blocking review items cannot be auto-fixed, or style version deviation continues to widen. Once triggered, return to Planning rather than continuing to stack chapters on a dirty state. Logs should retain the writing package, problem list, and truth diff for each chapter, facilitating post-mortems and allowing editors to change a single fact and replay subsequent affected chapters.

Implementation Order

You can start with a minimal closed loop instead of deploying all detections on day one. Step one: hand-write ten chapters of truth files and outlines to verify “can it continue writing relying solely on the writing package.” Step two: add blocking-level continuity and character state checks. Step three: add the foreshadowing ledger and pacing prompts. Step four: only then consider style anchors and auto-revision. Each step should regress with the same batch of sample chapters to prevent detection rules themselves from introducing new deviations.

The professional standard for long-form automation is that readers do not feel the pipeline, yet editors can always answer: on what facts is this chapter based, what was changed, and why was it released. By externalizing truth, splitting division of labor, and clearly defining failures, there is a chance to maintain the skeleton of the same novel even after hundreds of chapters; if you only increase prompt length or add a few differently named roles, the later stages will still degrade to “writing a rough idea.”