How We Got the Knowledge Panel Book Print-Ready With an Agent

How to Get a Google Knowledge Panel by Dennis Yu and Dylan Haugen went from a rough manuscript to a 220-page, KDP-ready paperback plus a matching digital edition in a single directed agent run. The agent did the typesetting, the QA, the positive-mention research, the cover, and the wiring that connects every chapter to a working agent skill. This is the first-hand account of exactly how.

The methodology this build runs on

This is entity-authority work, the same playbook behind Google Knowledge Panels for contractors and owning your name on Google. The book is the general SOP; this article is the specific build. It is a sibling to how we finished the Knowledge Panel book, and it follows the meta-article prompt template so the next agent can copy the pattern.

The task

The goal Dylan set: take the current manuscript and make it genuinely ready to publish. Concretely that meant four things. Typeset it like a real book, not a Word export. Work through Dennis’s QA report without blindly executing it. Wire the book to the free skill library so a reader can hand any chapter to an agent. And make the whole thing durable, so it stays correct as the skills evolve.

Out of scope for the agent: the actual KDP upload, the ISBN (KDP assigns it after upload), and any factual claim the agent could not verify. Those stay with the humans.

Source material the agent read

The build started from real inputs, not assumptions:

• Dennis’s AI QA report against the 267-page draft (treated as a proposal to verify, not a script to run)
• The editorial master document, revised across five versions during the build
• The live Business Authority skill pack (20 skills) and the companion page
• A client video where Sean K. Fay, CEO of Envision Response, thanks Dylan for the knowledge-panel work

That last one produced a real, on-topic testimonial that went on the back cover:

“I so appreciate your help with my Knowledge Panel. You’re going to help a lot of people.”
Sean K. Fay, CEO, Envision Response

The build pipeline

The interior is generated by a Python builder that rewrites the manuscript’s OOXML and renders through LibreOffice. It sets the 6×9 trim and KDP margins, adds the mirrored gutter so even pages pass the inside-margin rule, scales every table to the narrower column, caps images to the text width, and normalizes the PDF MediaBox to exactly 432×648 points.

The table of contents is the tricky part. LibreOffice does not populate a Word TOC field, so the builder renders the book, reads the true page of every Heading 1, writes those numbers back into the contents, and renders again until nothing moves. Every build ends with a verification pass: every folio must equal its physical page, and all 29 contents entries must match.

Wiring the book to the skills

Each chapter ends with a “Hand This to Your Agent” box. Ten of the eighteen already named a skill; eight gave a raw prompt with no skill and no link. The agent read the book, pulled the real chapter-to-skill map out of those boxes, filled the eight blanks with the matching skill, and standardized all eighteen to one pattern:

Run the knowledge-panel-entity-seo skill from the companion page
(localservicespotlight.com/knowledge-panel-book): "Run an entity audit on ..."

The durability move: the book links to one stable page, never to a skill-pack URL that might change. A short note up front frames that companion page as the all-in-one hub, the digital edition plus every current skill and pack. So when the library grows, the reader always lands on the current version and never needs a new edition. The diagram above is that map.

The QA marathon: real bugs and the fixes

The Sitelinks block would not delete

Symptom. The script to remove an obsolete JSON-LD example threw StopIteration and never wrote the file.

Cause. Every schema block ends with an identical closing </script> paragraph. Python’s xml.index() on that string always returned the first one in the document, so the “after this position” check never matched.

Fix. Stopped matching on the paragraph string and searched by character position after the Sitelinks label, then cut to the end of that paragraph. Deleted cleanly.

A part divider jumped to the last page

Symptom. After moving About the Authors to the back, the final page of the book was the PART I / UNDERSTAND divider, and the body had lost its Part I divider entirely.

Cause. The “move About the Authors” slice ran from its heading to the Chapter 1 heading, and the PART I divider sat in between, so it rode along to the back.

Fix. Cut the slice at the PART I paragraph instead. The divider stayed in the body before Chapter 1, only the bios moved, and the book now ends on the authors’ close.

The companion URL broke across a line and stretched the type

Symptom. On the front-matter note, the long URL hyphenated in the middle and the justified lines around it stretched into rivers of white space.

Cause. A long unbreakable token inside a narrow justified column forces the engine to stretch the spaces on that line, and the hyphenator split the URL.

Fix. Lifted the URL onto its own centered line so it cannot break and cannot stretch the prose around it.

Justified text left loose lines book-wide

Symptom. Short lines before a long word showed wide word gaps on many pages.

Cause. Justification in a 6-inch column stretches the few words on a loose line to reach the margin. Aggressive hyphenation tightened the dense pages but could not fix every loose line.

Fix. Switched the whole body to ragged-right and turned hyphenation off. Even word spacing everywhere, natural right edge, no stretched gaps and no hyphens.

Critical decisions with rationale

Verify the QA report against the real file, do not execute it. Several report items were wrong. It flagged “billionaire” on Tommy Mello for removal (the book’s wording was the approved one) and claimed AI Mode had not shipped worldwide (it had). Both stayed. Treating the report as a proposal, not a script, protected the book.

Suppress front-matter folios but keep numbering continuous. The title, copyright, and contents pages lost their running head and page number, but the count keeps running, so every body folio still equals its physical page and the contents stays exact. A page-number restart would have broken that.

Route the book to one companion page, not the skill-pack URL. Skill names are stable; what changes is the library and how skills connect. Pointing every box at the companion page means the page absorbs all future change and the printed book never goes stale.

Cross-reference by chapter and appendix, never by page. The book says “Chapter 13” and “Appendix D.19,” not “see page 148.” So when text reflows, nothing internal breaks. Only the contents and the folios depend on pagination, and the builder regenerates and verifies both every run.

Ragged-right over justified. Justified is a convention, not a quality bar, and it produces loose lines in a narrow column. Ragged-right removed the problem permanently and reads clean, which also suits an agent-readable digital edition.

Effort and cost comparison

Costs use Claude Sonnet public rates of $3 per million input tokens and $15 per million output, derived from roughly 3 million tokens across the run. Human cost is a blended $50/hr covering writing, layout, SEO, design, and project management. That is about 190x cheaper, and the agent did it in an afternoon of wall-clock time instead of a week.

What the agent handled vs what needed a human

Agent handled autonomously: all OOXML editing, the LibreOffice build pipeline, TOC generation and verification, folio and cross-reference checks, the content reorg, the Appendix E rebuild, the nuance edits, front-matter section breaks, the ragged-right conversion, three parallel positive-mention research streams, the mentions tracker, the chapter-to-skill mapping, the durability note, the cover wrap, the proof diagram, and this article.

Required human input: Dylan’s direction and visual approval at each step, the Sean K. Fay video, the editorial calls (keep Confidence Score, go ragged-right), voice corrections on the cover, and the final KDP upload and ISBN. Dennis confirmed the term decisions.

Information ingestion inventory

• 1 QA report audited against the real 220-page PDF
• 5 manuscript revisions produced (Rev 13 through Rev 17)
• 3 live Local Service Spotlight pages read; 20 skills catalogued
• 1 client video transcript mined for a testimonial
• 27 real, sourced positive mentions compiled into a tracker
• 18 “Hand This to Your Agent” boxes mapped to skills
• 29 contents entries and every folio verified on each build
• 1 proof diagram and 1 back-cover redesign produced
• ~3 million tokens across the run

Guidelines compliance scorecard

Why this creates value for the authors

Dennis and Dylan now have a book that is genuinely ready to upload, plus something most books do not have: a system that stays current after it prints. A reader can hand any chapter to a free agent and run the exact work the chapter teaches, and when the skill library improves, the companion page carries the update. The book sells the method and the page keeps the method alive.

Why this creates value for BlitzMetrics

This proves the agentic production line end to end. An agent can take a manuscript to print-ready, run the reputation research that fills a back cover, and wire a book into a living skill library, at about 190x less cost than doing it by hand. That unlocks book-and-skill-pack products for every vertical the Local Service Spotlight network serves, not just this one.

The build pattern

This build instantiates the entity-authority playbook: make the proof machine-readable, then wire the proof to the agents that maintain it. Read the general method in Google Knowledge Panels for contractors, get the book free at localservicespotlight.com/knowledge-panel-book, and compare this build against how we finished the Knowledge Panel book.