Validated against reality: Tested the engine's predictions against 3 published real-world A/B tests before building the full product. Called all 3 correctly. That's the only number that matters.
The Problem
You can't know if a piece of copy will land until real people see it. By then it's cost you the thing you were trying to protect.
- Email A/B tests burn half a list on the losing version
- Landing pages get shipped and judged weeks later, on traffic that's already spent
- Small audiences can't split meaningfully at all
- Every losing variant burns real engagement, real traffic, or both
Across every channel, the feedback that would actually make you better at writing comes back too slow and too expensive to build real intuition from. You end up flying on gut feel with occasional data confirmation, and the data arrives too late to be useful.
The Idea
OpenBeat replaces the wait with simulation. Before you send an email, publish a page, or ship any piece of copy meant to make someone act, a population of AI personas reads it first and reacts the way a real audience would.
No score, no keyword grade. Just a predicted outcome (open rate, conversion rate) with a confidence interval, plus the actual reasoning each persona used. You see who engaged, who didn't, and why, in the vocabulary native to that content type.
All of it in under 60 seconds, before a single real person sees the content.
How It Works
For any submitted piece of content, OpenBeat generates 50 AI personas calibrated to the target audience and runs them through a staged reaction pipeline.
Stage 1: Persona Generation
50 personas are generated in parallel, anchored to real audience data (SaaS operators, DTC shoppers, newsletter readers, cold-outreach recipients) instead of generic demographic templates or LLM guesses. Before generation, the engine queries its calibration database (real outcomes from previous campaigns with the same audience type) and anchors the personas to realistic baseline behavior.
Stage 2: First Contact
Each persona makes an initial engage/disengage decision, native to the content type: an email gets open / skip / maybe, a landing page gets stay / bounce. "Maybe" personas are in the middle of something else. For email, they get pulled back several simulated hours later and make a final decision with the message still unread, the same way real inbox decisions actually happen.
Stage 3: Deep Engagement
Personas that didn't bounce evaluate the actual substance: preview text and body for an email, headline and CTA for a landing page. This stage catches whether the hook over-promised or actually matched what was inside.
Stage 4: Decision
A content-type-native action space closes out the reaction. An email persona might unsubscribe or buy_immediately. A landing-page visitor might click_cta, share_with_team, or leave_undecided.
Stage 5: Report & Verification
A report agent synthesizes all persona reactions into a predicted outcome with a statistical confidence interval. If the prediction deviates significantly from the calibration baseline, the agent runs a second pass with historical data injected as an anchor, forcing it to justify any large deviation from real-world norms.
Stage 6: Quality Scoring (background)
After the result comes back, a background job scores the simulation itself on four dimensions: realism, persona diversity, reasoning coherence, calibration accuracy. These scores accumulate over time and surface systematic biases before they affect predictions.
Why It Generalizes (and Where the Line Is)
The mechanism underneath (persona population, staged reaction, engagement decision, synthesis) isn't specific to any one channel. What's specific to a channel is the vocabulary of decisions, the framing of the reasoning, and whether a "maybe" reaction gets reconsidered later or resolves in a single session.
Each content type is a self-contained plugin: its own prompts (written natively, not templated from another channel), its own decision vocabulary, its own persona framing, its own contradiction-repair logic. Two content types ship today, email and landing pages, proven out with a real landing page run end to end and checked against what a real visitor's reasoning should actually look like, not an email reader's reasoning wearing a different label.
That plugin boundary is also what makes the roadmap concrete instead of aspirational. SMS/push copy is next (likely simpler than a landing page, one round, no body/CTA structure), pitch decks after that. Social posts, paid ad creative, AI-citation prediction are deliberately out of scope. The decision there isn't really psychological, so those are already won by statistical optimization at scale or belong to a different problem (retrieval ranking) wearing content's clothes.
The Slope - Where This Goes Next
Content types don't get added randomly. Each one has to clear the same bar the landing-page feasibility spike set: is the reader's decision actually psychological, something a persona can reason its way through, or is it already a solved statistics problem that a bandit optimizer does better with real traffic data? Only the first kind is worth building.
| Content type | Status | Why it clears (or doesn't) the bar |
|---|---|---|
| Shipped | The original case: open/skip/maybe, subject line + preview + body | |
| Landing pages | Shipped | Proven via feasibility spike, same attention → engagement → decision shape, native stay/bounce/click_cta vocabulary |
| SMS / push notifications | Next | Same psychological decision, but simpler than a landing page: a single round, no body/CTA structure to evaluate |
| Pitch deck / fundraising copy | Roadmap | A real psychological decision, but structurally different. No clean "open" moment, so the round semantics need rethinking, not reuse |
| Social posts / paid ads / AEO-GEO citation | Rejected | Wrong side of a data-volume fight already won by statistical optimization, or the wrong mechanism entirely (retrieval ranking, not reader psychology) |
The slope isn't "add every channel." It's a narrowing filter. Each new content type has to be a real decision a human persona can reason through, has to be reachable by a plugin (new prompts + new decision vocabulary, no pipeline changes), and ideally shares a buyer with an existing content type.
What Makes It Different
| Approach | What you get |
|---|---|
| Keyword scoring tools | A grade based on word lists and sentiment rules, no audience model |
| Traditional A/B testing | Real data, but you've already spent half your list or traffic to get it |
| OpenBeat | A predicted outcome from a simulated audience, with reasoning and confidence range, before you ship anything |
The key difference: this doesn't score the content in isolation. It simulates how a specific audience actually behaves when it encounters the content, in the context that content type is actually consumed in, an inbox, a landing page visit, a scroll.
The Validation
Before writing a single line of product code, I tested the core prediction against three published real-world A/B tests, cases where the winning subject line was already publicly known. The simulation ran blind: given only the two subject lines and the audience type, it had to pick the winner.
It called all three correctly.
That's not proof of generalizability. Three tests is not a statistically significant sample. But it is proof the underlying mechanism works: simulating audience psychology produces predictions that track reality. The landing-page content type was proven the same way, a real page run through content-type-native prompts, with concrete checks that the reasoning holds up for a single-session visit rather than an inbox. The calibration corpus is how that proof becomes statistical as the product runs and real outcomes get fed back in.
Key Features
- Predicted outcome (open rate / conversion rate) with a statistical confidence interval, per content type
- Per-persona reasoning transparency: see who engaged, who didn't, and why, in the vocabulary native to that content type
- Baseline calibration grounded in real campaign and conversion data
- Live persona reveal via Server-Sent Events as the simulation runs
- Drift detection against historical norms
- A content-type plugin architecture: new channels are new prompts and a new decision vocabulary, not a new pipeline
Tech Stack
Backend: Python, FastAPI, ARQ (background job queue), Redis, PostgreSQL
AI / LLM: Claude (Anthropic) and OpenAI GPT with a provider abstraction layer, Pinecone for semantic memory of past simulations, LangChain for orchestration
Frontend: Next.js, TypeScript, Tailwind CSS, Server-Sent Events for live persona reveal during simulation
Infrastructure: Docker for local development, AWS for production, Supabase for managed Postgres
Status
Live and running. OpenBeat isn't positioned as an email tool that also happens to handle landing pages. It's a simulation arena for any content meant to make a human decide to act. The calibration corpus grows with each campaign that submits actual results after the fact. The accuracy of the simulation, not the breadth of channels, is what compounds into something a template competitor can't replicate.