Beyond the Chat Box: SOUL.md — one file for tone, voice, rules, and red lines

Post nine of a series on what live audience engagement actually looks like when there's an AI team in the room.

There's a question that comes up early in every conversation about deploying AI in a customer-facing context: how do you make sure it sounds like us?

The standard answer is some flavour of "prompt engineering." The vendor — or the prospective customer's own team — writes a long system prompt that describes the brand voice, lists the things the AI should and shouldn't say, defines the tone, names the red lines. The prompt is updated when something goes wrong. It's tweaked for each new use case. It accumulates conditionals over months until nobody's quite sure what's in it anymore.

This is how most AI products handle voice. It's a mess.

Prompts are unversioned, unreviewable, hard to diff, harder to roll back, and impossible to share between teams without copy-paste. They live in some configuration screen the marketing team can't access, edited by the one engineer who knows the prompt. When something goes wrong, the postmortem question — why did the AI say that? — has no clean answer, because the prompt has changed seventeen times since the event and nobody saved the version that produced the bad output.

ReactLive doesn't do prompt engineering. We do SOUL.md.

What SOUL.md is

SOUL.md is a single text file, written in plain language, that defines how the AI should behave for a given context.

It lives in the event configuration. It's read by the Orchestrator at the start of every event and propagated to every specialist agent. It's the source of truth for tone, voice, vocabulary, escalation rules, and red lines.

The file looks something like this:

# SOUL.md — Q3 All-Hands

## Voice
Direct, calm, slightly informal. We don't use corporate language.
We say "we're hiring 200 people next year," not "we are committed to
talent acquisition initiatives across the organisation."

## Vocabulary
- "the team" not "our employees"
- "customers" not "users"
- "the strategy" not "our strategic priorities"
- Avoid acronyms unless first defined in the event

## Red lines
- Never speculate on share price
- Never name specific employees in answers unless they're named
  in the question
- Never confirm or deny rumours about M&A activity
- Forward-looking statements only if they're already public

## Escalation
- Any question that names a specific manager → moderator
- Any question about pay equity, layoffs, or restructuring → moderator
- Any question the speaker has flagged as "I'll take this live" → moderator
- Any question the audience has upvoted past 50 → moderator,
  even if the agent could answer it

## Tone calibration
This is a tense quarter. Audience may be sceptical. Don't sound chirpy.

That's a SOUL.md. It's not exhaustive — most are longer — but the shape is exactly that simple. Plain text. Plain language. Versioned in your repo or your event configuration. Diffable. Reviewable. Shareable.

Why a file beats a prompt

Five reasons, each load-bearing.

Versionable. SOUL.md lives in version control (or a versioned configuration store, depending on how you've set it up). Every change is a commit. Every commit has an author, a timestamp, and a message explaining why the change was made. When something goes wrong six months from now, the postmortem question why did the AI say that? has a clean answer: here's the version of SOUL.md that was active during that event. You can see exactly what the agent was working with.

Reviewable. Comms reviews comms. Legal reviews legal. The CFO can read the red lines for an earnings event. The diversity team can review the language guidance. Nobody needs to know what a system prompt is. Nobody needs to log into a configuration UI hidden behind an admin role. The file is plain text, which means anyone in the organisation who can read can review it.

Reusable. The SOUL.md you wrote for last quarter's all-hands is the starting point for this quarter's. The voice doesn't change every quarter; the specifics do. Cloning the file, updating the relevant sections, and committing the new version is a five-minute task. Building the same configuration from scratch in a UI every time is a thirty-minute task that, in practice, doesn't happen — so the configuration just gets reused without the relevant sections being updated, and the agent runs against stale guidance.

Auditable. Regulated industries care about this one. Show me the policies that governed AI behaviour at last Tuesday's earnings call. With a prompt buried in a configuration UI, the answer is "uh, we'll get back to you." With SOUL.md, the answer is the file at commit a3f2c91, attached to the audit log for that event. Same file, same version, same content the agent actually saw.

Shareable. Different events can reference different SOUL.md files. The earnings all-hands has its file. The product launch has another. The internal weekly AMA has a third. Common patterns get factored out into shared partial files that the event-specific ones include. The result is a library of reusable behaviour configurations, evolving over time, owned by the people who actually own the voice — not by the engineer who first wrote the prompt.

What goes in a SOUL.md

There's no rigid schema. The file is read by the Orchestrator and propagated to the agents — they pick up the content holistically, not by parsing fixed sections. But in practice, every working SOUL.md ends up covering five things:

Voice. How does this organisation sound when it's at its best? Direct or formal? Warm or measured? Playful or precise? The voice section is what makes the difference between an AI answer that reads like a corporate press release and one that reads like an actual person from this organisation talking.

Vocabulary. Specific word choices that matter to this organisation. The product is called the platform, not the solution. Customers are teams, not users. The annual all-hands is the all-hands, not the quarterly business review. Vocabulary is the most boring section to write and the one that most directly determines whether the AI sounds native or alien.

Red lines. The things the AI must not say or do, regardless of how confident it is or how reasonable the question is. These are usually about regulatory compliance, organisational sensitivity, or topics where the cost of being wrong is asymmetric. A red line in SOUL.md is enforced across every agent — Protect won't let a question through if answering would violate it, Answer won't generate a response that crosses it, Engage won't surface it as a poll topic.

Escalation rules. When does the agent stop and ask a human? Some escalations are about content (any question naming a specific manager), some are about audience signal (any question upvoted past a threshold), some are about phase of the event (the first ten minutes, when the speaker is still warming up). The escalation section is where the host's editorial judgment about what the AI should not handle alone gets encoded.

Tone calibration. Event-specific notes that don't fit the other sections. This quarter is tense. The room may be sceptical. The CEO is recovering from a difficult board meeting. Don't sound chirpy. This is the section that makes the file feel like a brief from one human to another rather than a configuration spreadsheet.

SOUL.md is read by every agent

This is the part that makes SOUL.md a primitive rather than a feature.

The Orchestrator reads SOUL.md once at the start of the event and propagates it to every specialist:

• Setup uses it to apply defaults that match the voice — a SOUL.md that says "direct, calm, slightly informal" leads to different default polls than one that says "formal, measured, precise."
• Protect uses the red lines to define what the moderation policies actually mean for this event. Never speculate on share price becomes a moderation rule, not just a guideline.
• Engage uses the voice and tone calibration to know what kind of polls and prompts will land. A tense-quarter SOUL.md leads to careful, low-frequency engagement; a celebratory-quarter one leads to more touchpoints with a warmer tone.
• Answer uses the voice to generate answers in the right register, the vocabulary to use the right words, and the red lines as hard gates on what it will say.
• Report uses the voice to write the post-event recap in the same register as the event itself, so the recap reads like a continuation rather than a foreign object.

One file, read once, propagated everywhere. That's the architecture.

The implication: changing how the AI sounds across the entire event is a single-file edit. Not five separate configuration screens for five separate agents. Not an engineer rewriting five separate prompts to keep them in sync. One file. One commit. Done.

Why this is structurally important, not stylistically

There's a temptation to read SOUL.md as a nice idea — a more pleasant way to configure an AI — without grasping the structural shift it represents.

The shift is this: the people who own the voice and policies of an organisation are now the people who configure the AI.

In the prompt-engineering world, voice and policies live in a system prompt that only the engineer who set up the AI can edit confidently. Marketing has opinions but can't apply them directly. Comms has red lines but can't enforce them without going through a ticket queue. Legal has compliance constraints but no visibility into whether they're actually encoded in the prompt that's running.

In the SOUL.md world, all of those people can read and propose changes to the file directly. Marketing can update the voice section. Comms can add a red line. Legal can review the file before an earnings event the same way they review any other document. The bottleneck of "the engineer who knows the prompt" disappears, because there's no prompt to know — there's a file, and the file is human-readable.

This is the same shift that happened to infrastructure when configuration moved from clicking around in admin UIs to text files in version control. Infrastructure as code changed who could safely make infrastructure changes, what postmortems looked like, how fast organisations could move. SOUL.md is the same idea applied to AI behaviour configuration: AI behaviour as code, owned by the people who own the behaviour.

That's why we call it a primitive. A feature is something you turn on and off. A primitive is something the rest of the system is built around. SOUL.md is the latter.

The naming, briefly

A note on the name, because we get asked.

SOUL.md is part of a small family of files we use throughout ReactLive's architecture: AGENTS.md (defines what each agent is), SKILL.md (defines what each agent can do), USER.md (captures preferences for a specific user), MEMORY.md (persists context across events). These conventions echo similar patterns in agentic AI systems generally — the idea that a coordinated set of agents needs a small set of human-readable configuration files, not a sprawling configuration UI.

SOUL.md gets its name because of what it actually does: it's the closest thing the system has to a personality. Voice, values, red lines — the things that make this AI sound like this organisation rather than a generic chatbot. Calling that file SOUL.md was deliberate. We could have called it voice.yaml or policy.json or personality_config.toml. We didn't, because the name should make clear that this file is the soul of the event — and getting it right is the difference between an AI that fits and an AI that's foreign.

What SOUL.md does not do

It is not a replacement for human judgment. SOUL.md encodes guidance, not decisions. The agents still have a dial. The moderator still has override. The host still has final say. SOUL.md is the document the agents work with, not the document that runs the event.

It is not a guarantee of behaviour. The agents are calibrated to follow SOUL.md, but they're probabilistic systems and they can be wrong. The combination of SOUL.md plus the dial plus moderator override is what produces consistent behaviour — not SOUL.md alone.

It is not exclusive to ReactLive. The convention of small, plain-text configuration files for AI behaviour is increasingly common across agentic AI systems. We didn't invent the pattern. We've adopted it because it works — and because the alternative, prompt engineering, is a mess we don't want any of our customers to inherit.

The bigger argument

The case for SOUL.md isn't really about ReactLive. It's about how AI should be configured anywhere it's deployed in a serious production context.

Prompts are an artefact of how AI products were built in 2023 and 2024 — the era when prompt engineering was a job title and "the prompt" was a moat. That era is ending. The prompt-as-mystery-document model can't survive contact with real organisational requirements: regulatory compliance, multi-team ownership, version control, audit trails, change management. Every serious deployment of AI in 2026 and beyond is going to need a configuration model that looks more like SOUL.md and less like a system prompt buried in an admin UI.

We just got there first for live events.

The Orchestrator reads SOUL.md. The agents follow it. The humans own it. That's the architecture that makes audience engagement at scale actually work.

Next up: The Orchestrator doesn't outrank your moderator. Why "Auto" doesn't mean "unsupervised," what override actually looks like in practice, and why the agent system is built to make humans more powerful, not less.

Join the waitlist to get early access. Three free events. Locked-in pricing.