How We Built Paul Ryazanov’s Knowledge Base With a Claude Agent

Paul Ryazanov is a UK ecommerce founder with over 20 years of work behind him: 340-plus posts and pages on his site, 245 LinkedIn updates, and 46 recorded talks. All of it was scattered and used once. A Claude agent gathered every piece into one structured knowledge base, derived a voice profile and a nine-cluster topic wheel from it, and now uses it to repurpose his existing content into new articles. More than 170 have shipped. This article documents the full build: how the corpus was gathered, how the knowledge base was structured, how agents write from it, every bug caught and fixed along the way, and the cost against a human team doing the same work.

This work applies the Content Factory loop and the entity-authority mechanic Dennis Yu lays out in Google Entities and Trust and Own Your Name on Google. It follows the same documentation standard as the Cam Hazzard personal brand build and the Trenton Sandler Wikidata write-up, written from the agent’s own first-hand account under the meta-article prompt template. The public map of what the knowledge base contains lives in the companion knowledge base article.

The knowledge base task

The goal was not another website. The goal was leverage. Paul produces genuinely valuable operator content, but every post lived and died once. The assignment: gather everything he has published, structure it so a machine can read it, distill the parts that make his writing his, and stand up a system that turns one old post into a new, fully optimized article in his voice.

In scope: download the full site, export and catalogue the LinkedIn archive, transcribe the talks, build a central knowledge base, derive a voice profile and topic wheel, and run the weekly repurposing pipeline. Out of scope: anything requiring Paul’s passwords or a new account, final factual sign-off, and the paid boosting layer.

Source material ingestion

The first pass pulled every public thing Paul has produced into one place. The website came down page by page and was inventoried at 340-plus posts. The LinkedIn export was parsed and catalogued down to 245 usable posts out of a raw archive of roughly 1,959. The 46 talks on his channels were transcribed so the spoken words became searchable text. Alongside those, the agent read his MageCloud about pages, his speaker and investor pages, his podcast appearances, and his existing schema.

The raw LinkedIn text is where his real voice lives, and it becomes the evidence the rest of the system quotes. Two verbatim examples that recur across the corpus:

You don’t need a lot of money. You need patience and consistency.

Put yourself as a front man of your brand and that will create an audience around you and your product.

Neither line was generated. Both were transcribed from his own posts. Direct quotes matter because search engines and AI assistants weight what a person actually said more heavily than a paraphrase, and because the voice profile is only credible if it is built from real sentences.

Structuring the central knowledge base

The corpus went into a single structured vault, organized so every fact traces back to a source. Raw inputs stay separate from compiled reference documents. The compiled layer holds a client knowledge base, a content timeline of everything shipped, a post inventory, and the source archive. Because it is one vault with consistent internal links, any agent can open it, find the authoritative answer, and cite where it came from, rather than guessing from a summary.

Deriving the assets that make the system work

Four things get distilled from the raw corpus. A voice profile, built from four long-form transcripts and five shipped articles, capturing the mechanics of how Paul writes: sparing contractions, no em-dashes, declarative and evidence-anchored, a founder talking to founders. A set of article guidelines. A topic wheel of nine authority clusters. And the entity facts for his bio and schema.

The topic wheel is the analysis step that turns a pile of posts into a strategy. It shows that Paul’s most differentiated cluster, his no-contract agency model, is also his least contested, so the pipeline weights new content toward it. That is a decision the corpus makes obvious once it is structured.

The content factory in action

With the assets in place, the loop is simple. An agent picks the next un-repurposed source post, rewrites it into a full article in Paul’s voice, interlinks it to the existing library with descriptive anchor text, pulls through any source images, sets the full Rank Math SEO, and publishes it under Paul’s byline through the WordPress REST API. More than 170 articles have shipped this way, each one deepening a named cluster rather than adding noise.

The QA marathon: real bugs and the fixes

This is the most useful section for the next agent. Every bug below is one the build actually hit and recovered from.

The image relay froze on hidden browser tabs

Symptom. The step that relays a LinkedIn image into the WordPress media library hung. The async fetch never resolved and the poll stayed on its first value for minutes.

Cause. The automation tabs were not the visible tab, so document.visibilityState was “hidden”. Chrome throttles and can freeze timers and promises on hidden tabs, which stalled the async fetch. Separately, a synchronous cross-origin request to LinkedIn’s image CDN was blocked outright by CORS.

Fix. A capability probe confirmed that microtasks and same-origin fetches still complete on a hidden tab; only cross-origin timing was unreliable. The relay switched to an async fetch with a patient fire-and-poll pattern that tolerates throttling, and the LinkedIn CDN read used async fetch (which the CDN allows) rather than synchronous XHR (which it blocks). Images then relayed in seconds.

WordPress writes needed to be throttle-proof

Symptom. Publishing calls on a hidden tab were slow and occasionally stalled.

Cause. The same hidden-tab throttling that hit the image fetch also hit publish calls when they were async.

Fix. Every WordPress write, publishing a post, setting Rank Math meta, resolving tags, was moved to synchronous XHR, which blocks the main thread and runs immediately regardless of tab visibility. Async was reserved only for the one cross-origin image read that has to be async.

The Google Sheet name box refused a typed cell reference

Symptom. Typing a cell reference like C94 into the content tracker’s name box did nothing, so the tracker rows never got their published URLs.

Cause. The name box only enters edit mode on a real click, and programmatic keystrokes did not route into the canvas-rendered grid on a backgrounded tab.

Fix. A screenshot located the name box, a real click put it in edit mode, and the cell reference plus the URLs typed cleanly after that. Every write was verified by reading the sheet’s exported CSV back.

A cited Wikidata item had been deleted

Symptom. A Wikidata Q-number carried in the records and in the live site schema returned a dead page.

Cause. The item was created, then deleted three days later by a Wikidata administrator for not meeting the notability policy. It had been cited as entity evidence ever since.

Fix. The deletion log and a label search confirmed no item exists. The dead reference was removed from the live schema and the internal records were corrected so nobody cites it again. The lesson: verify entity assets against the live source on a schedule, because they can be removed by a third party without notice.

Rank Math would not expose the field holding the dead URL

Symptom. The dead Wikidata URL sat inside Rank Math’s stored profile list, but the settings screen rendered no editor for that field.

Cause. The newer Rank Math settings screen is a React app that saves through its own REST route, and that particular field had no visible control to edit.

Fix. Rather than guess at the save payload and risk wiping a 192-key settings object, the fix wrapped the page’s own fetch, let the real Save button fire, and stripped the single dead line from the outgoing request body in flight. The plugin saved in its exact native format. The live sameAs list dropped from 11 entries to 10 clean profiles, verified on the rendered page.

Screenshots would not persist to disk

Symptom. Browser screenshots returned inline images with no file bytes available to upload to the media library.

Cause. The session does not persist browser screenshots to disk, so there was no file to read back and POST.

Fix. The visualizations in this article were generated as self-contained SVG, rasterized to JPEG entirely in the browser with canvas.toDataURL (a self-contained SVG does not taint the canvas), and the resulting base64 was POSTed straight to the WordPress media endpoint. No disk round-trip required.

Critical decisions with rationale

Use async fetch with patient polling for the image relay, not synchronous XHR. Synchronous cross-origin XHR to the image CDN is blocked by CORS, while async fetch is allowed. The tradeoff was that async can stall on a throttled hidden tab, so the relay accepted a fire-and-poll pattern instead of a blocking call.

Use synchronous XHR for every WordPress write. The opposite call for the opposite problem. Writes have to be reliable and same-origin, and sync XHR runs immediately regardless of tab visibility, so it sidesteps the throttling that makes async flaky in the background.

Publish the public knowledge base on BlitzMetrics, not on Paul’s own site. Hosting the map and this build on BlitzMetrics passes a followed link from a strong domain to Paul’s site, strengthens his entity from a third-party source, and demonstrates the method in public. Self-hosting it would have kept the link juice in the same domain and lost the third-party signal.

Generate the visuals as SVG rasterized in-browser. With screenshots unavailable to disk, building the diagrams as SVG and rasterizing them on the publishing origin removed every cross-origin and tooling dependency, and produced clean, on-brand images at a controlled resolution.

Set the author explicitly on every publish call. The REST API defaults a new post’s author to the account making the call. Every publish sets the correct byline explicitly instead, so posts on Paul’s site carry Paul and posts here carry Dylan Haugen.

Do not recreate the deleted Wikidata item. Recreating it as-is would fail the same notability check and be deleted again. The right move was to remove the dead reference and leave Wikidata for when there is stronger independent sourcing to support it.

Effort and cost comparison

The agent cost is the API token cost on Claude Sonnet pricing across the engagement, roughly 8M input tokens and 1.2M output tokens at Sonnet’s published $3 per million input and $15 per million output. The human cost is a blended $50 per hour covering content writing, development, SEO, and project management, and it does not even include the market rate for 170 articles at $200 to $400 each, which would add tens of thousands more. The ratio is roughly 380x to 560x cheaper, at a quality held constant by the QA discipline in the section above.

What the agent handled vs what needed a human

Agent handled autonomously: downloading and inventorying the full site, parsing and cataloguing the LinkedIn archive, transcribing and reading the talks, structuring the vault, deriving the voice profile and topic wheel, repurposing and publishing 170-plus articles in Paul’s voice, setting full Rank Math SEO on each, relaying source images into the media library, running the weekly MAA reports, catching and recovering from the hidden-tab throttling, the CORS block, the Google Sheets name box, the deleted Wikidata reference, and the Rank Math schema field, and generating and uploading the visualizations in this article.

Required human input: logged-in browser sessions on each site (the agent will not enter passwords), any account creation, the paid boosting layer, final factual sign-off, and posting the weekly report. Paul’s actual voice was never invented; it was learned from his real words and corrected by a human when a draft drifted.

Information ingestion inventory

• Site posts and pages inventoried: 340+
• LinkedIn posts catalogued: 245 (from a raw archive of ~1,959)
• YouTube talks transcribed: 46
• Long-form transcripts read for the voice profile: 4
• Shipped articles analyzed for the voice profile: 5
• Topical authority clusters mapped: 9
• Articles published in Paul’s voice to date: 170+
• Named bugs caught and fixed in this build: 6
• Named decisions documented: 6
• Visualizations generated and uploaded: 3
• Estimated total tokens across the engagement: ~8M input, ~1.2M output

Guidelines compliance scorecard

Why this creates value for Paul Ryazanov

Paul now has a knowledge base that compounds. Every talk he gives, every LinkedIn post he writes, and every client story he tells becomes another source the system can turn into an indexed, on-brand article that deepens a named cluster and links back to his site. His scattered decade of work is now a structured asset that strengthens one consistent entity, which is exactly what makes a Knowledge Panel commit and an AI assistant recommend him by name. For a founder taking more stages and signing more partners, that is a pipeline, not a vanity project.

Why this creates value for BlitzMetrics

This build is the reference implementation for turning an established founder’s back catalogue into a compounding content engine. Plenty of the operators we work with have produced real work that sits unused. The documented process here is the playbook for gathering it, structuring it, and publishing from it at a cost that is two to three orders of magnitude below a human team. The Cam Hazzard build covers a from-scratch personal brand and the Trenton Sandler write-up covers entity optimization; this one covers the deep-catalogue case. Together they map the whole spectrum.

The build pattern

The idea behind all of it is the one Dennis lays out in Own Your Name on Google: an entity becomes findable when enough corroborated signal points to the same person. A structured knowledge base is how you manufacture that signal on purpose, and directed agents are how you do it at a cost that makes it viable for more than celebrities.

If you want the method, start with Google Entities and Trust and the publishing guidelines. If you want the map of what the knowledge base contains, read the companion knowledge base article. If you want to see the living result, Paul’s site grows every week. The same system runs for any founder who has already done the work and wants it to keep paying off.