Architecture explainer · updated 26 July 2026

The static book is not the endpoint.

Agentic publishing is not simply prompting a model to produce an ePub. It is a design direction in which a work is source-aware, versioned, adaptable to a reader’s legitimate context, and available through useful interfaces—not merely a fixed file.

Important boundary: this is a reference architecture and product direction, not a claim that every component is currently available in Agentic Book Publishing. A system should describe live features, roadmap items, and experiments separately.

What changes when a book becomes a system?

A conventional digital book is a fixed artifact. A more agentic publishing system can preserve a canonical source while generating reader-appropriate views, retaining provenance, exposing an understandable interface, and recording what version of a work a reader received. The goal is not infinite personalization; it is a more useful relationship between a bounded source of knowledge and a reader’s actual task.

Phase 1: asynchronous editorial workflows

Long-form factual work should not depend on a single unreviewed model call. A robust workflow separates research, drafting, verification, editorial review, and publishing decisions. Event-driven jobs or durable queues can help manage long-running work, retries, approvals, and version transitions.

Retrieval-augmented generation can ground a draft in selected sources, but it does not guarantee truth or eliminate hallucinations. Retrieval quality, source quality, citations, and review still matter.

Before a workflow retrieves or renders anything, it needs a durable provenance record. The Source Ledger Validator is a local-only utility for checking the basic identity, version, scope, access, and distribution fields of that record.

Phase 2: just-in-time compilation

A canonical manuscript can support multiple legitimate renderings: a reader’s technical stack, level of familiarity, locale, accessibility needs, or selected chapter path. The system should keep the source work stable while making every substitution traceable and reviewable.

Phase 3: the book as an endpoint

For technical and operational work, an interactive reading layer can be more useful than copying passages between windows. A reader may need to ask a constrained question, retrieve a cited section, compare versions, or bring authorized book context into an IDE or research workflow.

The first delivery layer is narrower: Published Release Manifests expose only explicitly approved public metadata at stable JSON URLs. Private and authorized-reader releases do not resolve through that public interface.

The standard: source, scope, and reader control

The useful distinction is not static versus AI. It is opaque automated text versus a source-aware, versioned, reviewable system that gives readers control. Good agentic publishing preserves the author’s canonical work, identifies what changed for a specific rendering, respects authorization and privacy boundaries, and does not overstate what an AI workflow can verify.

Where Agentic Book Publishing fits today

The current public product focuses on an author workflow: using a manuscript description and an agent’s public MSWL to prepare a query-letter draft for the author to review. It does not submit letters, guarantee representation, or claim to provide the full architecture described above.

See the first public prototype: The Maha Principle Context Pack Explorer records book identity, permitted destinations, version, release boundary, and exclusions in a human- and machine-readable form—without distributing protected book text.

For the current workflow, read how the query generator works, how MSWL analysis works, and the questions and answers page.