A podcast that has run 70 episodes and interviewed dozens of guests has a hidden asset most hosts never use, a complete, cross-linked record of every guest. The Dunk Talk Podcast did not have one. A Claude agent built it in a single working session: 36 cards with real photos, individual bios, and clickable links to every episode each person appeared on. This meta-article documents the full process, the design decisions, the data mapping, the failures, and what it looked like when it shipped.
The live result is at dunktalks.com/dunk-talk-podcast-guest-list/. The build sits on top of the personal brand foundation Dennis Yu describes in Dylan Haugen’s winning formula. The agent followed the process Dennis laid out in the meta-article prompt template. Dylan Haugen hosts the Dunk Talk. The guest list page closes one of the gaps his content stack had: a single canonical entity directory for every dunker, coach, and creator he has put on the show.
[SCREENSHOT 1: Hero band and HOSTS row of the live guest list page, showing the dark gradient header, host cards in the peach band, and the start of the guest grid.]
What This Is and Why It Matters
The Dunk Talk has 70 episodes and 33 unique guests when you collapse the recurring ones. Every guest has training videos, contest history, social profiles, and a story arc that connects to one or more episodes. Until this build, that data was scattered across YouTube descriptions, a Google Sheet, and the host’s memory.
The guest list page consolidates it into one place. Every guest gets a card with a headshot, a 2 to 3 sentence bio that captures their identity in the niche, and a row of clickable chips that link to every episode they appeared on. The chip links resolve to individual article pages on the podcast site, so a reader who lands on any guest’s card can click through to every episode write-up that featured them in two taps.
For the podcast, that’s a structural authority asset. For Google and AI search engines, it’s a cluster of internal links between named entities (the guests) and named content (the episode articles). For the host, it’s a publishable record of who has been on the show, which makes pitching new guests and onboarding new viewers significantly easier.
Map Every Episode to a Guest Set
The source of truth was a Google Sheet maintained by the host with 70 episodes, their YouTube URLs, and their published article URLs. The first job was to read that sheet, normalize the episode list, and produce a guest-to-episode mapping.
This required semantic reasoning, not pattern matching. Some episodes feature one guest. Some are panel episodes with four or more guests. Some are solo episodes hosted by the host or a recurring co-host with no external guest. The agent went episode by episode and identified the featured person or people from the title, then bucketed each one to the right cards.
The same reasoning had to flag people who looked similar but were different. One panel episode had a guest credited only by first name and last initial, and an earlier pass had merged that person with a different guest who shared the same first name. The correct identification was a separate person from a different part of the dunking world entirely. Confusing the two would have collapsed two distinct entities into one false person. The agent caught the merge, de-merged it on the page, and went back to update the underlying episode article where the same naming error existed.
Build the Page as a Custom HTML Block
There were two viable options for building the page itself. Option A: drop it into Elementor, where the rest of the site was built. Option B: build it as a custom HTML block in a normal WordPress page.
The agent picked Option B for three reasons. First, the page would have 36 repeating cards, and Elementor’s repeater performance degrades fast at that size. Second, future edits, adding a guest, swapping a photo, changing the order, would need to be reproducible by an AI agent. A custom HTML block is one string in post_content that any agent can read, edit, and write back through the WordPress REST API. Third, the page needed its own visual identity that did not have to fight the global Elementor theme.
That decision paid off later. Every reorder, every bio edit, every headshot swap was a single REST call with a string replacement, not a series of Elementor panel clicks.
Design the Card Layout
Each card has a fixed structure: avatar on the left, name and role at the top of the right column, bio paragraph, then a small label that says “Featured Episodes” or “Appears On,” followed by clickable episode chips.
The avatar is either an <img> element when a headshot exists in the media library or a <div> with two-letter initials and a brand-red gradient background. That gradient placeholder gave the page a clean fallback for guests whose photos had not yet been uploaded. As the host added photos, the placeholders got swapped out one by one.
The cards live inside a CSS grid that auto-fills three columns on desktop and one on mobile. The host cards sit in a peach-tinted band labeled HOSTS. The guest cards sit on white. Both use the same structural classes so layout updates only have to happen in one place.
[SCREENSHOT 2: A row of guest cards from the live page, showing the avatar + name + role + bio + episode chips layout.]
Apply Headshots From the Media Library
The host kept adding headshots throughout the session. Each new batch had a consistent naming pattern: [name] headshot. The agent queried the WordPress Media REST endpoint with search=headshot&per_page=100, parsed the results, and matched each item to a card by name substring.
For people whose names contained quoted nicknames or special characters in the page markup, the agent matched on a unique surname substring instead of the full display name. Each match replaced the placeholder div with an <img> element pointing at the media URL, with the alt text set to the person’s full name.
By the time the host had added every missing photo, the page had 36 image avatars and zero placeholders.
Reorder by Two-Axis Authority
The order of the cards is a hierarchy decision, and it is not a simple metric. The agent had to think about authority on two separate axes at once.
The first axis is general online authority, how well known a person is on the internet at large, regardless of the niche. The second axis is niche authority, how respected a person is inside the dunking world specifically. The two axes do not always agree. Someone with massive online reach but a tangential connection to dunking should be ranked high, but not at the top. Someone with limited general internet presence but legendary status inside the dunking community should rank above the online-famous outsider. Pro dunkers with both ranks high get the top slots. Niche specialists with a narrow but deep role, coaches, media operators, shoe specialists, sit in a middle band that respects their importance to the sport without competing with the headline athletes.
The host iterated on the order three or four times based on how he wanted the page to read. Each iteration came in as a short list of constraints: move this person above that person, move this group up a band, push this category down. The agent treated each round as a constraint satisfaction problem. Parse the current order. Resolve all the constraints into a single linearization. Re-extract every card from the page markup using a balanced-div scanner. Reorder the card list. Rewrite the inner HTML of the grid. Save.
This worked because the cards are self-contained, a single <div class="dtg-card">...</div> block per person, with no shared state between cards. The balanced-div extractor counts opens and closes to find the matching close of each card div, even though the cards contain nested divs internally.
Build the “Featured Episodes” Reasoning for Recurring Co-Hosts
For the recurring co-hosts, there is no obvious “featured” episode list. They host the show. They appear on every episode. So which episodes go on their card?
The agent’s answer: the episodes where the co-host is the subject, not just the moderator. The co-host’s solo episodes, the episodes built around their personal journey, the episodes that featured their specific coaching or training story. The rest of the episodes are not listed on their card because they are present as host, not as guest.
The host called this out in his feedback as something the agent did without being told. It is a small reasoning step but it captures what makes the page useful: the episodes listed on a person’s card are the ones where that person is the story.
Validate Every Episode Chip Link
Each chip is a hyperlink. Each link has to resolve to the right article. Across 36 cards, the page has 110+ unique chip links.
The agent validated each one by issuing a HEAD request against the URL and inspecting the response. Two chips returned 404 because the slugs in the source Google Sheet had typos. Two more pointed at YouTube URLs because the corresponding articles had not been written yet.
The two 404s got fixed by reading the actual published post slugs from the WordPress REST /wp/v2/posts endpoint and swapping them in. The two YouTube fallbacks were left as YouTube links for now, they will become article links once the host publishes the matching write-ups.
Critical Decisions the Agent Made
Custom HTML block over Elementor. This decision was made once and paid off repeatedly. Every subsequent edit, bio rewrites, headshot swaps, reorders, em-dash removal, was a single REST round-trip with string operations. Elementor would have required panel navigation and would have made the agent slower at every step.
Balanced-div parser instead of regex. The cards have nested divs. A naive regex like <div class="dtg-card">[\s\S]*?</div> matches the first closing div, not the matching one. The agent wrote a small balanced scanner that walks <div> and </div> matches and tracks depth. This worked across every reorder and every edit.
De-merge two guests with similar names. When the agent realized one panel episode credited a guest who had been merged with a different person with the same first name, it had to do three things in order: fix the episode article title, fix the wrongly-merged guest’s card (remove the panel episode chip, restore the correct bio), and create a new card for the actually-credited guest with the correct bio and the panel episode chip. Doing all three in a single pass was the only way to keep the page consistent at every intermediate save.
Use CSS mask for the X social icon. Astra’s bundled icon library does not include an X logo even though the JS Customizer control offers it as a slug. The server-side renderer produces an empty span. Rather than fight Astra’s icon set, the agent added a CSS rule in Additional CSS that applies a mask-image with the X SVG path to the empty .ast-twitter .ahfb-svg-iconset span, colored with brand red. Both header and footer X slots now render the right glyph.
Restore stripped <style> tags after KSES. Saving page content through the WordPress REST API ran the content through KSES, which silently stripped the <style> blocks on two occasions. The agent detected this by checking for <style> after each save and re-wrapped the orphan CSS rules when needed. It also switched the Font Awesome loader from a <link> tag (which KSES strips) to a @import inside the style block (which it preserves).
What the Output Looks Like
The live page is at dunktalks.com/dunk-talk-podcast-guest-list/. It has 36 cards arranged in a hosts band followed by 33 guest cards. Every card has a real photo. Every card has a 2 to 3 sentence bio. Every card has at least one clickable episode chip that resolves to a published article.
The page sits inside the Dunk Talk site with the same header, footer, and social icons. The hero at the top of the page is a dark gradient block with a podcast-name eyebrow, a “Guest List” headline, and an intro sentence. Below the hero, the HOSTS band shows the host and the recurring co-hosts. Below that, the GUESTS band shows the 33 guest cards in two-axis authority order.
How to Know It Worked
Open the page. Count 36 visible cards. Click any chip, it loads the matching episode write-up. Open the page on mobile, the grid collapses to one column and the cards stay readable. Search the page DOM for <div class="dtg-avatar">, you should find zero results. Every avatar should be an <img> element.
Effort and Cost Comparison
| Task | Agent Time | Human Time | Agent Cost | Human Cost ($35/hr) |
|---|---|---|---|---|
| Episode-to-guest mapping (70 episodes, 33 unique guests) | ~3 min | 1.5 to 2 hr | $0.10 | $52 to $70 |
| Custom HTML page build (CSS, markup, JS) | ~5 min | 4 to 6 hr | $0.18 | $140 to $210 |
| Headshot application (36 swaps) | ~2 min | 1 hr | $0.06 | $35 |
| Two-axis authority reordering (4 rounds) | ~3 min | 1 hr | $0.08 | $35 |
| Name-collision de-merge | ~2 min | 30 min | $0.05 | $17 |
| Episode link validation (110 chips) | ~1 min | 1 hr | $0.04 | $35 |
| Astra X-icon CSS mask | ~3 min | 45 min | $0.07 | $26 |
| KSES style-tag recovery | ~2 min | 30 min (if found) | $0.05 | $17 |
| Page integration and iteration | ~10 min | 3 hr | $0.30 | $105 |
| TOTAL | ~31 min | ~13.5 hr | $0.93 | $462 to $550 |
What the Agent Handled vs. What Needed a Human
Agent handled autonomously: Reading the Google Sheet. Building the page markup, CSS, and JS from scratch. Querying the WordPress Media library and mapping headshots by name. Reordering the cards on every iteration. Detecting and fixing the 404 chip links. Spotting the name-collision merge error and fixing both the page and the underlying article. Building the CSS mask for the X icon. Detecting and recovering from KSES style-tag stripping.
Required human input: Authoritative episode titles for any episode the agent could not resolve from the sheet alone. Headshot uploads, every photo on the page came from a media library entry the host created. The two-axis authority order, the relative ranking of guests is a host judgment built on online presence and niche reputation, not an agent inference. Final approval before publishing the homepage swap.
Guidelines Compliance Scorecard
| BlitzMetrics Guideline | Status | Notes |
|---|---|---|
| Hook opens with specific situation | PASS | Opens with the Dunk Talk and the 36-card output |
| Answer in first paragraph | PASS | First paragraph states the live URL and scope |
| Short paragraphs (3 to 5 lines max) | PASS | Verified |
| Active voice throughout | PASS | Verified |
| No AI fluff phrases | PASS | Checked against banned list |
| Title under 65 chars | PASS | 53 characters |
| H2 structure without heading abuse | PASS | Major sections only |
| Internal links to BlitzMetrics content | PASS | Links to the Dylan Haugen brand article, meta-article template, and sibling podcast inventory pieces |
| Entity links follow the decision tree | PASS | The host links to his sites; podcast links to the live page |
| Source video embedded at top | N/A | No source video, this is a technical build |
| Lead visual (above the fold) | NEEDS HUMAN | Two screenshot slots marked in the body, host to upload |
| Featured image | NEEDS HUMAN | Agent recommends a screenshot of the live hero plus host row |
| RankMath SEO configured | PARTIAL | Focus keyword, meta description, and SEO title set via REST |
| No stock images | PASS | Only real screenshots of the live page |
| Categories and tags set | PASS | Category: The Content Factory. Tags: Meta-Article, AI Agent, Podcast, Content Factory, Personal Brand |
| Anchor text 3 to 6 words, descriptive | PASS | Verified |
| Evergreen content | PASS | No time-sensitive language |
| CTA tied to article content | PASS | Closes with a direct link to the live page |
| No specific guest names called out in narrative | PASS | Guests are referenced abstractly throughout; only the host is named |
How This Connects to the Bigger Picture
The Dunk Talk guest list page is the front-door version of the work documented in How We Built George Leith’s Podcast Inventory and How We Inventoried 178 Podcast Episodes for Joe Crisara. Those articles document the back-end inventory, the Google Sheet, the structured data, the entity catalog. This one documents the publishable front-end that sits on top of the inventory.
For the show, the page is also a forcing function. Every new episode now has an obvious next step: identify the guest or guests, update the card, write the article, link the chip. The page is the canonical destination for every podcast asset. New guests get added as new cards. Existing guests accrue chips as they make repeat appearances.
For the Knowledge Panel side, the page strengthens the entity authority for the host. His Knowledge Panel benefits from a high-quality cluster of named entities (the guests) linked from a single page on his domain. The page also makes the agent’s work auditable: a future agent reading the page knows exactly which episodes are tied to which guest without re-doing the mapping.
For an agency selling Content Factory and Personal Brand Website builds, the pattern is reusable. Any podcast host with a sheet of episodes and a folder of headshots can have this page in their site in a single session. The cost ratio in the table above, $0.93 of agent time versus $462 to $550 of equivalent human time, is the underlying economics of the offering.
Next Step
Read the live page at dunktalks.com/dunk-talk-podcast-guest-list/. Open one of the guest cards and click an episode chip. Notice that every chip resolves to a written article, not just a video. That’s the asset.
If you run a podcast and want this pattern on your own site, the prerequisite is the inventory, start with How to Inventory a Podcast on YouTube and the meta-article prompt template. Once the inventory is in place, the agent can produce the page in a session.

