Does Saying Your Name and Company on a Podcast Help AI Understand Who You Are?

What we already measured

Before designing an experiment, it is worth establishing what the ecosystem already does, and the answer is very little.

The Podcasting 2.0 namespace defines a podcast:person tag whose stated purpose is to identify "people like hosts, co-hosts and guests". It takes optional role, group, img and href attributes; if role is missing, "host" is assumed, and "guest" is an explicit value. The href attribute links to "a relevant resource of information about the person, such as a homepage or third-party profile platform".

That is a precise, documented mechanism for stating in machine-readable form that a named person appeared on an episode and linking to who they are. We checked how many feeds use it.

Of 52 podcast feeds examined in September 2026, six declared podcast:person: Changelog, JS Party, Practical AI, Acquired, Security Now and TWiT. Genuine role="guest" values appeared in only four. Every business and interview show in our sample — the shows a guest is actually booked on — declared none.

The concentration is as striking as the rate. Changelog's three feeds account for 4,817 of the 5,309 person declarations we counted, which means a single publisher is responsible for the overwhelming majority of machine-readable guest identification in our entire sample. Remove that one organisation and the practice barely exists.

Why that finding matters before any experiment runs

Because it tells you where the question actually lives.

If the machine-readable channel for stating who appeared on an episode is used by roughly one feed in nine, then for the overwhelming majority of appearances the only route by which a person's name reaches a machine is text on a page — show notes, an episode description, or a transcript.

That collapses the original question into something narrower and more answerable. Saying your name and company aloud puts it in the audio. Audio is opaque to anything that does not transcribe it. So the spoken association reaches a machine if, and only if, something turned it into text.

Which means the experiment is not really about speaking. It is about whether the transcription path — a published transcript, or platform captions — carries the association accurately enough to be useful.

It also reframes what a guest is actually buying. An appearance on a show that declares people in its feed produces a structured, linkable statement that a named individual with a stated role participated. An appearance on the other eight feeds in nine produces, at best, a name in a paragraph — which is readable but carries no role, no link and no assertion a machine can rely on without inferring it.

So the interesting variable was never how clearly anyone spoke.

The design

Four conditions across matched appearances, with the association stated differently in each.

Condition A: the subject states name and company clearly in the recorded conversation, and the show publishes a transcript on a crawlable page. Condition B: the same spoken statement, but the show publishes no transcript. Condition C: no spoken statement, but the episode description and show notes name the subject and company in text. Condition D: both spoken and written.

At each measurement window the protocol records whether the association appears in the episode page text, in any published transcript, in platform captions, and in responses to fixed prompts asking who founded or leads the company.

The prediction that makes this worth running: conditions A, C and D will produce a machine-readable association and B will not, regardless of how clearly the subject spoke. If that holds, the practical advice changes from "say your name and company" to "appear on shows that publish text".

Matching matters more here than in the other protocols, because the conditions differ in publishing practice rather than in anything the subject does. Shows should be paired on audience size and subject area so that the only meaningful difference between condition A and condition B is whether a transcript gets published — otherwise the design measures show quality and calls it transcription.

Four conditions is the minimum that separates speech from text; fewer collapses the question.

The confound nobody mentions

Automatic captions get names wrong, and a wrong name is worse than no name.

YouTube's guidance warns that automatic captions "might misrepresent the spoken content due to mispronunciations, accents, dialects, or background noise", and tells creators they "should always review automatic captions and edit any parts that haven't been properly transcribed".

Company names and personal names are exactly the material speech recognition handles worst: proper nouns, often invented, frequently unfamiliar to the model. An executive whose surname or company is mangled in captions has produced searchable text asserting the wrong thing, on a page they do not control.

So the protocol records not just whether the association appears, but whether it appears correctly, in each transcription path. That distinction is the one most likely to produce a finding a guest can act on, because it is checkable within days rather than months.

There is a reasonable mitigation a guest can apply immediately: spell the company name aloud once, or ensure the host writes it correctly in the show notes. Neither costs anything, and both give the transcription path a correct string to anchor on rather than a phonetic guess.

The same problem applies to the company name in reverse. A distinctive invented brand is hard for speech recognition and easy to search for once correct; a generic dictionary-word brand transcribes reliably and is then indistinguishable from ordinary prose, which is its own kind of invisibility.

What this cannot test

Whether any of it changes what an assistant believes about the person.

As documented throughout this series, no major operator publishes how entities are recognised or how sources are selected for citation. Google's knowledge panel documentation explains what a panel is and how to claim one, and never explains how an entity enters the graph. Its AI features documentation states eligibility conditions and stops before selection.

So a positive result would show that an association became machine-readable, which is a precondition, not an outcome. Attributing any change in assistant behaviour to it would be exactly the inference this series has spent seventy reports declining to make.

The honest scope is therefore modest: this design tests whether a spoken association survives into text that a machine can read, and where in the chain it is lost. That is a question with an answer, unlike the one it is usually mistaken for.

A reader should treat any vendor claiming otherwise as describing a mechanism nobody has published.

What a guest can do now, without waiting for the study

Three things, all immediate and none dependent on any result.

Ask whether the show publishes transcripts, and check a recent episode page yourself rather than taking the answer on trust. Our own measurement found episode pages ranging from 448 to 53,552 words among established shows.

Check the captions after publication, on YouTube if the episode is there. If your name or company is mangled, you have found a correctable problem in days rather than discovering it in a search result months later.

And publish the association somewhere you control: an episode round-up on your own site naming the show, the date, and what was discussed. Media Morpheus books podcast appearances, and this is the part of the entity question that requires no permission from anyone — the show controls its transcript, and you control whether a correct, linked, text version of the association exists at all.

None of the three requires the host to agree to anything, which is what makes them worth doing first.

Methodology and limitations

This report combines one original measurement with a study protocol that has not been executed. The measurement retrieved 52 podcast RSS feeds in September 2026, selected purposively across technology, business, news, interview and general-interest categories, and counted podcast:person declarations and role attribute values. Six limits apply. First, the feed sample is purposive and not representative; the adoption rate describes these 52 feeds only. Second, the unit is the feed rather than the show. Third, TWiT and Security Now expose only ten episodes in-feed, so their declaration counts are not comparable with full archives. Fourth, absence of the tag does not mean a guest is unnamed: show notes and transcripts routinely name guests in prose that the tag would have made machine-readable. Fifth, the four-condition experimental design is published in advance of execution and no results from it are reported or implied. Sixth, as no operator publishes entity recognition or citation selection criteria, the design cannot attribute any downstream change to a mechanism.

Conclusion

The mechanism for telling a machine who appeared on a podcast already exists and almost nobody uses it. The podcast:person tag identifies hosts, co-hosts and guests, defaults role to host, and accepts guest as an explicit value with a link to a profile — and six of 52 feeds we examined declare it, with real guest roles in four. For everyone else the spoken association reaches a machine only if something turned the audio into text, which reduces an interesting question about speech to a mundane one about publishing. The experiment worth running tests where in that chain the association is lost, and whether captions preserve a name correctly. Speaking clearly is not the variable. Whether anyone wrote it down is.

Frequently Asked Questions

Sources

1. vendor research Media Morpheus, September 2026. Original measurement of podcast:person declarations across 52 RSS feeds. Method and limitations stated above.
2. official Podcasting 2.0 namespace specification. podcast:person, for the tag's purpose, attributes and role values.
3. official YouTube Help. Automatic captions, for the accuracy warning on machine transcription.