Backstory: when the AI needs to know who you are

This blog post you're reading right now was drafted by a persona that knows me. Not in a "the model has read my tweets" way. In a real, structured way. It knows I came up through vRA in the 2010s. It knows about OneFuse. It knows the names of the homelab nodes (engine-01, core-01, store-01). It knows the day my AI agent deleted production. It knows I drop the word "leverage" on sight, and that I prefer "use." If you read this paragraph and thought "yeah, that sounds like Sid", that's the persona doing its job.

Here's the part that surprises people: the persona that books my dentist appointment knows none of that. It doesn't know what a 386 is. It doesn't know I have a blog. If you asked it to draft a tweet for me, it would either refuse or do a worse job than a stranger. And that is (and I cannot stress this enough) exactly what I want.

Backstory is a tool, not a setting. You give it to the personas whose job requires it. You withhold it from the ones whose job doesn't. The default is no backstory. You earn it by needing it.

Why I framed it this way

For a while I thought every persona should know everything about me. Same model, same memory, just different "modes." That's the shape most AI assistants are still in today, one big pile of context, and the assistant picks what's relevant.

The problem is that "picks what's relevant" is doing a lot of work in that sentence. The assistant doesn't actually know what's relevant. It has a guess. And when the guess is wrong, you get the well-worn failures: the family dinner planner that suggests inviting a coworker because "you mentioned them a lot last week." The work email that opens with the same dry humor you use with your brother. The customer-facing reply that mentions your divorce because the model thinks empathy means oversharing.

Every one of those is the same bug. The AI had access to information it didn't need, so it used it.

So I stopped trying to teach the AI when to be quiet, and started taking the information away from the ones who didn't need it. That's the persona move. The Family persona doesn't know my brand voice, so it can't accidentally use it. The blogging persona doesn't know the names on a family calendar, so it can't slip them into a post. The withholding isn't a guardrail. It's the architecture.

When backstory earns its keep

Backstory is purposeful when the persona has to represent me, sound like me, or make judgment calls a stranger couldn't make. Three buckets:

Personas that write in my voice. This blog is the clearest example. The blogging persona has to know my references, my era, my scars, the substitution list I drag every "leverage" into "use" through. Without that, the writing comes out as anonymous LinkedIn slurry. The voice is the product.

Personas that represent me publicly. The persona that replies to comments on this blog has its own email address (more on that in the first-class-identity piece). When it responds, it's speaking as a stand-in for me. It needs to know enough about me to do that without embarrassing either of us.

Personas making customer-facing judgment calls. If I ran a one-person consultancy and had a persona drafting replies to clients, that persona would need to know my engagement style, what I do and don't agree to over email, the lines I draw on scope. That's lived-in context. You can't ship that as a tone slider.

In all three, the persona has a purpose that requires knowledge of who I am. The backstory is the tool for the job.

When backstory is a liability

And then there's the other half. Personas with jobs that don't require knowing me at all. Three more buckets:

Personas that schedule things. The Family scheduling persona finds time on the calendar, sends invites, books the table. It does not need to know my career history. It does not need my blog. It probably doesn't even need my last name beyond what's required to confirm a reservation. If a scheduling persona starts referencing "your work at OneFuse" inside a personal text thread, something has gone deeply wrong.

Personas that execute well-defined transactions. The persona that pays my bills doesn't need a personality. It needs accurate account numbers and a working bank integration. Giving it backstory creates surface area for failure modes that didn't have to exist.

Personas that act inside a regulated boundary. If a small business runs a "client billing" persona, that persona should know the client list and the rates. It should not know the owner's personal opinions about each client. The point of the persona is to keep that separation real.

In all three, the persona's job is bounded. Adding backstory doesn't help it do the job better. It just gives it more material to leak.

The three audiences, same rule

Want to go deeper on what a persona actually contains? Start with A persona is a container, not a costume, then come back here.

Let me walk through how the same principle lands for each kind of reader.

Personal. My Family persona doesn't know my work calendar, and it doesn't know my professional voice. That's the point. When the persona is helping coordinate something inside the household, I don't want the AI suggesting "Hey, you might want to invite your coworker since you mentioned them this week." I want it to do the thing in front of it. The lack of work backstory is what keeps the Family persona feeling like family.

Small Business. If you run a side business (say, a coaching practice) your business persona needs some backstory to draft replies in your voice and represent your service correctly. But it doesn't need your personal medical history, the household details, your reading list. Give it what the job requires, nothing more. When a client emails on a Sunday and the business persona replies, you want the reply to sound like the business, not like a friend who happens to be coaching.

Enterprise. At a real company, this is where the wheels come off most existing setups. The shared-everything assistant accidentally answers a customer support ticket with internal pricing detail, or a junior employee's "help me draft this" pulls from the CEO's strategy doc that the model technically had access to. A persona built for the customer support role doesn't know the strategy doc exists. Not "knows but is told not to mention", doesn't know. The audit trail later says: the support persona answered the ticket, with these tools, from this scoped knowledge. Not "the company AI accessed everything and chose well."

Same rule everywhere. Backstory is given on purpose, to personas whose job demands it.

How I think about loading the backstory

Here's how I think about it. When I create a persona, I ask one question: what does this persona need to know about me in order to do its job, and nothing more? Then I write that down. Not as a system prompt that says "you are Sid's helpful assistant." As an actual structured record of facts and preferences the persona owns.

The blogging persona owns: my voice substitution list. My era references. My published positions. Things I've said publicly that I want to stay consistent with. The names of my homelab nodes, because I use them as recurring touch-points. The scars, the time the agent deleted production, the AWS bill that taught me about cost guardrails, the bot-that-emailed-customers incident.

The Family persona owns whatever the household actually needs to function: the shared addresses, the shared calendar handle, the standing contacts (doctors, schools, services), the recurring household facts. It does not own my employer, my professional title, my writing, or anything about my work life. If it ever needs to coordinate with my work calendar (say, a medical appointment that lands during business hours) the symmetry rule kicks in, and the user and the AI both shift personas for that interaction (I wrote about that in the symmetry piece).

The dentist-booking persona owns: my name, my insurance details, the dentist's contact info. That's it. If it ever feels like it needs more. That's a signal to narrow the persona's job, not widen its backstory.

The part that will bite you

Backstory creep is real. The temptation, once you have a persona that "knows you," is to keep adding facts to it because it's convenient. The blogging persona could also schedule my podcast appearances, since it knows my brand. The Family persona could also book a household vacation, since it knows the household. The dentist persona could also coordinate with my doctor, since it already has my name.

Don't. Every fact you add is a fact that can leak. Every job you add to an existing persona is a job that didn't get the scope decision made on purpose. The right move is almost always to create a new persona (or better yet, a project nested inside an existing persona) with exactly the backstory the new job requires.

(More on projects nested inside personas in the next article in this series. The short version: scope narrows further when you go from persona to project. A specific event-planning project inside Family doesn't need the standing list of contacts; it needs the guest list for that one event. Same logic, one level down.)

What I'd ask if you're setting this up

If you're standing up personas for yourself, your business, or your company. Here's the question I'd start with: for each persona, write the smallest backstory that lets it do its job. Then read it back and ask, "what could go wrong if this leaked?" If the answer is "nothing important", you got the scope right.

If a persona's backstory contains anything you'd be unhappy reading in a stranger's email, the scope is too wide. Cut it back. Move the sensitive facts to a different persona, or behind an explicit access decision that gets logged.

Backstory is one of the most powerful tools in the persona toolkit. It's also one of the easiest to over-apply. Use it on the personas whose purpose demands it. Don't use it on the ones that don't need it. That's the whole rule.

And when this blog post lands and a reader says "this sounds like Sid", that's the persona doing exactly what it was built to do. Nothing more. Nothing the persona two desks over could also do.