When Rich Brooks opened a blog draft his Claude project had written from a podcast transcript, one detail jumped out: the word “actually” appeared seven times in roughly 2,000 words.
At first glance, that looks like a model problem. In practice, it was a source problem.
Rich’s own speech uses “actually” about that often, so Claude had not drifted away from his voice. It had reproduced it with unsettling accuracy. That is the uncomfortable part of working from transcripts, webinars, livestreams, or customer interviews: if the source speaker has habits, the model will learn the habits too.
For teams trying to turn spoken material into publishable writing, that changes the job. The goal is not just “make it sound like the speaker.” The goal is “make it sound like the speaker, while controlling the habits that show up too often.”
Why voice cloning from transcripts produces repetition
This is not specific to one model. If the input contains repeated phrasing, filler words, or a favorite turn of phrase, the output is likely to inherit those patterns when the prompt asks for voice matching.
That makes source selection and editing strategy more important than most workflows assume.
If you feed an AI a transcript of a webinar, you are not only giving it ideas and structure. You are also giving it the speaker’s verbal fingerprints. The model can learn those fingerprints so well that the draft feels authentic, but also slightly too authentic. It may preserve the cadence, the transitions, and the recurring words that a human editor would usually trim.
Rich’s example is useful because it shows the difference between style and habit. “Actually” can be part of someone’s natural voice, but once it appears seven times in 2,000 words, it stops reading like voice and starts reading like noise.
Make voice rules observable
The most practical idea in Rich’s workflow is to define voice rules in a way the draft can be checked against.
That is a better pattern than writing a vague instruction like “sound authentic.” Authentic to whom? Based on what? How would anyone know whether the model succeeded?
A checkable rule is different. It gives the editor something concrete to verify.
For example, instead of asking for “natural-sounding prose,” you can ask for rules like:
- Limit the use of a specific filler word.
- Keep the speaker’s preferred rhythm, but remove repeated openers.
- Preserve the speaker’s directness while reducing redundant transitions.
Those are not just style preferences. They are behaviors. A draft can either follow them or fail them. That makes the editing loop much tighter.
This matters because the model is not judging quality in the same way a human editor would. It is matching patterns. If your instructions are too abstract, the system can produce output that technically resembles the voice while still missing the editorial standard you actually care about.
Put the correction in the final check
Rich’s setup goes one step further: the project’s final notes tell him what it did.
That detail seems small, but it is the difference between hoping the rule worked and confirming that it fired.
On the show, one example he read back said: “Double-checked, removed all but one of the actuallys.”
That sentence matters because it creates an audit trail. Instead of trusting the draft blindly, Rich can see whether the rule was applied. The model reports the action it took, which makes the workflow easier to inspect and debug.
For content teams, that kind of feedback loop is valuable. If a draft still feels too repetitive, you can ask a very specific question: did the cleanup step run, and if so, what did it remove? If the model says it reduced repeated language, you can evaluate the result against the rule you set. If it did not, you know where the process needs adjustment.
This is a stronger pattern than relying on a one-pass prompt and hoping the output lands in the right place.
The tradeoff: setup time now, editing time later
The obvious downside is that this takes work upfront.
Rich said he spends a lot of time on setup so he does not have to spend a lot of time on it each week. That is the tradeoff. The workflow gets slower before it gets faster.
But the payoff is real. He now spends about five to 10 minutes editing a blog post, compared with two to three hours writing one from scratch. He did not get there by nailing the prompt on the first try. He got there by iterating on the project.
That is the part worth emphasizing for anyone building a similar system: the value is in the accumulated list of rules, not in a perfect first draft.
You are not trying to eliminate editing entirely. You are trying to move recurring decisions into the workflow so they stop costing you the same mental energy every week.
Treat the rule list as the asset
The strongest operational lesson from this approach is that the list itself becomes the asset.
Every time you notice a repeated phrase, an overused opener, or a habitual transition, you can turn that observation into a rule. Over time, the list becomes a practical style guide for the model. It captures the things the AI should keep, the things it should limit, and the things it should report back on.
A simple way to start is to look at the last 10 captions or drafts your AI produced and find the phrase that appears most often. Then write one line that caps it.
That small step is more useful than trying to define voice in the abstract. It gives the model a constraint it can follow and gives you something to inspect in the output.
The source material already contains the voice. Your job is to decide which parts of that voice are signal and which parts have become repetition.
A practical takeaway for builders
If you are building a content workflow around transcripts or speaker-led material, the lesson is not “AI gets voice wrong.” It is more specific than that.
AI can capture voice extremely well, including the parts you may not want repeated. The solution is not a looser prompt. It is a tighter editing system:
- identify the speaker’s recurring habits,
- turn those habits into explicit rules,
- make the final step report what it changed,
- and iterate until the workflow is cheap to run.
That is how you get something that sounds like the speaker without carrying every tic into the published draft.
For the original discussion, see [https://www.agorapulse.com/blog/social-media-marketing/train-your-ai-on-your-voice-then-edit-out-the-tics-it-learned/] and the fuller episode breakdown at [https://www.agorapulse.com/blog/ai-social-playbook/e8/].
Top comments (0)