Redactor -- AI-Powered Book Generation

TL;DR

Redactor is a personal project that generates structured book content from high-level outlines using retrieval-augmented generation (RAG) and AI workflow orchestration. The system takes a book outline, enriches it with relevant context through RAG, then uses a LangGraph-based workflow to produce coherent book chapters. It is currently at prototype stage.

Problem

Writing a full-length book from scratch is a massive undertaking. Even with a detailed outline, the gap between bullet points and polished prose requires enormous time and cognitive effort. Existing AI writing tools tend to produce either short-form content or long text without consistent structure, tone, or factual grounding. I wanted to see whether a structured workflow – combining outline decomposition, RAG for context enrichment, and iterative drafting – could produce book-quality content from a minimal starting point.

Role and scope

Solo project. I designed the architecture, implemented the pipeline, and continue to iterate on the prototype. The scope covers the full pipeline from outline input to chapter output, but does not currently include publishing, formatting, or distribution features.

Constraints

• Single developer: Every component from prompt engineering to data pipeline to deployment was my responsibility.
• LLM costs: API calls to language models are the primary operating cost; the pipeline must minimize unnecessary calls while maintaining output quality.
• Context window limits: Book-length content far exceeds any model’s context window, requiring careful chunking and state management across the generation workflow.
• Quality consistency: Generated content must maintain consistent voice, factual accuracy, and structural coherence across chapters that are generated sequentially.

Architecture and decisions

The system uses LangGraph to define a state-machine workflow that guides the generation process through discrete stages:

1. Outline parsing – The input outline is parsed into a structured representation of chapters, sections, and key points.
2. RAG enrichment – For each section, relevant context is retrieved from a knowledge base (documents, references, web sources) to ground the generated content in factual information.
3. Draft generation – Using the outline and enriched context, the system generates a first draft for each chapter section.
4. Review and refinement – Each draft passes through review stages that check for consistency, factual accuracy, and style adherence before proceeding.
5. Assembly – Approved sections are assembled into chapter documents.

I chose LangGraph over simpler sequential pipelines because the generation process benefits from conditional branching – for example, sections that fail review can be routed back for revision rather than requiring a full restart.

Implementation

[Details to be added on specific implementation choices, libraries, and code structure.]

Key implementation areas include:

• Workflow graph definition using LangGraph state machine patterns
• RAG pipeline for context retrieval from the knowledge base
• Prompt templates for consistent generation across chapters
• Output formatting to produce structured Markdown or text files

Reliability, security, and evaluation

The prototype has been tested on book outlines of varying complexity. Evaluation focuses on:

• Output quality consistency across chapters of the same book
• Relevance of RAG-retrieved context
• Pipeline reliability (error handling when API calls fail)
• Cost per generated chapter

No user data is stored – the system operates on explicitly provided outline files. API keys are managed through environment variables.

Result

The prototype can take a multi-chapter book outline and produce structured chapter drafts that maintain reasonable consistency in voice and structure. [Details to be added on specific output quality metrics and user testing results.]

Trade-offs and lessons

• Workflow engines vs. direct generation: LangGraph’s state machine approach adds complexity but provides control and debuggability that a single-shot generation call cannot match. For small projects, the overhead might not be worth it.
• RAG dependency: The quality of output is directly proportional to the quality of the RAG context. A poorly curated knowledge base produces confidently wrong content.
• Cost vs. quality: Higher-quality models produce better output but at significantly higher cost per chapter. The sweet spot depends on the use case.
• Iterative refinement: The biggest quality gains came not from better prompts but from adding review-and-refine loops. This insight shaped the entire architecture.