I thought the post was finished. My readers disagreed.

I had finished the post announcing Roundtable. I thought it was good - maybe a bit technical, but I was proud of it. Then I went to do what I always do before shipping: paste it into an AI and ask whether it held up. I got two clicks in before the irony struck me. The post argues that a single AI has a structural incentive to nod along, that it is the worst possible judge of work it helped produce. And there I was, asking it to judge the post it had helped me write. I had walked straight into the thing I was warning about.

So I decided to run the post through the tool it was promoting. The trouble was, none of the standard five panels were good fits. Six Hats organises by cognitive mode. Historical Figures by intellectual tradition. Stakeholder Map by affected party. All useful for working through a decision. None of them reflects the main thing that matters when you are writing: the people who will actually read the thing.

Why "looks good" is useless

The thing I find most difficult when writing is finding the flaw that loses a specific reader. A line that reassures an early adopter can be the same line that loses an IT Director. A claim that satisfies a technical reviewer can be the one that makes a marketer ask who the post is for. A single AI averages all of those readers into one voice and tells you it "looks good".

I did not want a generic critic. I wanted to know which specific readers would object, and why.

Designing the panel around the readers

I decided to build a panel where each persona is a reader who may be interested in the blog, and let them argue.

I picked six archetypes that span who reads Associative Trails and who has to be convinced for a software tool to be implemented:

• David, IT Director - operational risk and supportability
• Marcus, Technical Director - rigour and architecture
• Maya, Graduate - practical day-to-day usefulness
• Priya, HR Manager - organisational impact
• Sarah, Lead Consultant - delivery reality
• Sophie, Marketing and Comms Manager - clarity and positioning

Between them they cover the four reasons a professional services reader rejects a new tool: it will not survive procurement due diligence (David), the argument is thin (Marcus), I cannot act on it (Maya and Sarah), it ignores how my organisation actually works (Priya). Sophie is there to catch the post failing as a piece of communication.

Match the panel to the job in hand. For a decision, principle-based panels work. For writing, the aim is "who will read this and what will they think"?

How it was built and run

In Roundtable, a custom panel is a folder containing a text file for each persona. You can either write these yourself or ask the AI to generate one for you - for example:

Add an ethics advocate to the Blog Reader panel

# Name - Role

## Background
2-3 sentences: seniority, experience, domain, defining career context.

## Approach
The frameworks, mental models and instincts they bring.

## Priorities & constraints
What they optimise for. What they will not compromise on.

## Blind spots & biases
One or two honest tendencies that make their view distinct but limited.

## Voice & tone
How they communicate. 2-3 adjectives plus a sample sentence.

## The question they always ask
One signature question they reliably raise.

The signature question is what stops a persona regressing into a generic reviewer with a job title. Here are David's and Sophie's, because they are the furthest apart:

The custom panel lives in a subfolder, sitting alongside the standard-issue panels. Roundtable picks up any folder matching the naming convention, so a custom panel needs no code change. It is simply text files in a directory.

Running it was one line: "Give me panel feedback on this post from the Blog Readers panel" with the blog text attached. Each persona returns scored, structured feedback, and a final synthesis pulls out the agreements, the disagreements, and the one change worth making first.

What came back scored 7 out of 10 overall, with individual reads from 6 to 8:

What the panel found that I could not

Two things jumped out immediately.

• Four personas arrived at the same conclusion: the post was written entirely for the solo practitioner who has full control over their own tooling. David wanted deployment guidance for a managed environment. Maya wanted a path as an individual inside a large firm where she cannot just clone a repo onto a work laptop. Priya wanted the team and organisational dimension. Sarah wanted implementation honesty that went past personal use. I had written the post for the only reader I could see clearly, which was me.
• Three personas independently flagged a diagram placeholder still sitting in the draft text. Unfinished work - the kind of thing an author stops noticing somewhere around the fortieth read and can often end up being published.

What surprised me was two personas pulling in opposite directions. Marcus wanted the technical architecture stated more precisely, because to him the compressed "a folder of files is a multi-agent system" claim was weak. Sophie wanted exactly the opposite: more precision would deepen the post for the few and shrink an audience that was already too narrow. Both were right inside their own terms of reference. The panel didn't settle the argument. It showed me what the trade-offs were.

That is the whole reason for building the thing in the first place. An answer-dispensing machine would have told me which way to go. The panel forced me to decide.

The interesting part is that this isn't six different AI models. It's one model constrained six different ways. A generic review lets the model average perspectives into a safe verdict. Fixed personas force it to commit to specific concerns and create disagreement that would otherwise disappear.

What changed, and when to do this

The version of the launch post that I eventually published has a section called "A note on scope." It addresses managed enterprise environments, names the data-processing reality of routing through external models, and invites firms that want a version inside their own infrastructure to get in touch. That section only exists because the Blog Readers panel told me my post was ignoring one of my largest audiences.

I should be clear on what this is not. It is not six independent "minds" - it is one LLM denied its usual escape into hedging. Blind spots shared by all six personas will still be there. Its strength is catching the objection that belongs to one persona and vanishes the moment you average them.

So, when is this worth doing?

Build a custom panel when the job has a known set of stakeholders and you are too close to be all of them at once. Transactional writing¹ is where this helps most. But proposals, pricing pages and pitch decks are the same kind of thing - a document that has to clear several different readers, written by one person who can only really see through their own eyes.

The default Roundtable principle-based panels are useful when you are exploring a problem rather than defending a finished artifact. Audience panels are different. They show you the objections that disappear the moment everyone gets averaged together. They will not resolve genuine trade-offs for you, but they will identify them and help you judge the best way through them.

Roundtable is free and on GitHub. Download it and add your own target audience - the people who need convincing, the ones who ask the questions you have been hoping nobody notices. Then run it before you press "send".²

(1) Yes - we're a household that has just been through GCSEs and we're all very happy they are over. Until mid-August. Fingers crossed.

(2) And yes, I did run this post through the Blog Readers panel. It didn't cause a singularity, but David is demanding 10% and Sophie is starting a spin-off podcast.