Households and businesses are just bigger persona graphs

A household, a small business, and an enterprise are the same shape. Personas plus projects plus shared overlaps. Only the fan-out changes.

Households and businesses are just bigger persona graphs

I've been writing this series at the scale of one person and their AI for thirteen weeks, and the whole time I've been quietly avoiding the thing that I think actually matters most. Which is: this doesn't stop at one person. The shape that works for me-and-my-laptop is the same shape that works for a household with kids and dogs and a joint bank account, and it's the same shape that works for a five-person consulting shop, and it's the same shape that works for a five-thousand-person company with an HR department and a security team and the whole catastrophe.

The thing I keep landing on is that there is exactly one primitive (persona) and you can stack and connect them differently to get any of those scales. There isn't a "household model" and a "small business model" and an "enterprise model." There's a graph. The graph has more nodes in some shops than in others. That's basically the only difference.

Same shape, three scales Household Adult A Adult B Family Finances 4 nodes Small business Person 1 Person 2 Person 3 Sales Ops Finance Client X 7 nodes Enterprise many nodes, same shape Same primitive. Different fan-out.
Same primitive. Different fan-out.

I want to walk you through how I think about that, because once you see it, the design choices stop being scale-specific and start being shape-specific. The questions become the same.

Start from the household

Take a household, any household with more than one person in it. There are some adults. Maybe kids, maybe not. Maybe a roommate, a long-term caregiver, an aging parent. The cast is whatever it is. The shape is the same.

If you were to draw the graph honestly, you'd start with personas-per-person. Each adult in the household has their own Personal persona and Work persona, and maybe a couple of project personas nested inside those (which I wrote about in Projects, the second axis of persona scope). Different person, different graph, no overlap between one adult's Work and another's. That part is straightforward.

The interesting bit is the shared stuff: the joint calendar, the household finances, the standing logistics (appointments, services, recurring errands), the grocery list, a renovation, a planned trip. None of that lives inside any one adult's personal graph alone, because it doesn't belong only to one of them. Multiple people touch it. Multiple AIs should be able to see it. None of the individual personas is the right home for it.

The naive instinct is to make it a shared piece of two personas, like a folder that both personals have a pointer to. I think that's wrong. The right move is to make the shared thing its own persona. The Family persona. It has its own calendar, its own finances, its own memory, its own RBAC, its own audit story. Each adult in the household can act as the Family persona, with their own credentials, and so can their respective AIs when they ask them to. The Family persona is a real first-class container, not a shared folder dangling off two other containers.

This sounds fussy until you try to run a household calendar without it. The "shared folder" model means every change has to figure out which person owns the change. The Family-persona model means changes belong to the Family. One adult adds a standing appointment, the Family persona adds it. Someone moves a recurring event, the Family persona reflects it. When an AI looks at the Family calendar to schedule something, it's reading the Family persona's data, not reading "across" the individual Personals.

The shared things are themselves first-class. That's the rule I keep coming back to. Joint finances aren't a slice of two personals. They're the Joint Finances persona, with its own accounts attached, its own AI-assistant context, its own log of who-did-what.

The small business is the same shape with more nodes

Now scale up by about three commas of complexity. A small business, let's say a consultancy with five people, a few clients, an ops function, a books-and-finance function, is the same graph with more nodes hanging off it.

You still have individual personas (each consultant has a Work persona, and probably a Personal one they keep firmly separate). You still have shared containers, except now they're things like the Sales persona, the Ops persona, the Finance persona. Each of those is a first-class identity, just like Family was at the household scale. Each has its own email address. Each has its own tools. Each has its own data scope.

If you run a side business. Here's the shape that actually plays well: the business is a Workspace with its own personas. Client Work, Ops, Finance, Marketing. Each of those personas is acted as by you (and maybe a couple of collaborators). Your Personal persona is not the same as the business's Client Work persona, even though you're the human behind both. When the AI is acting as the Client Work persona, it doesn't get to see your personal medical records. When it's acting as Ops, it doesn't get to see the half-finished blog post you have open.

The reason this matters at small-business scale specifically is that small businesses are usually the place where the lines get sloppiest. You're three people in a Slack. Somebody uses their personal Gmail for a client thing because it was faster. The "company" Notion has a personal recipe in it because somebody pasted it there once and nobody noticed. Five years later you sell the business, and now the new owner has access to a Notion that contains a recipe. That's the soft version of the problem. The hard version is that the new owner now has access to a personal conversation that should never have been in the company Notion in the first place.

The persona-graph discipline at this scale is the difference between something you can hand off cleanly and something that gets uncomfortable.

The enterprise is the same shape with org structure

Run the dial all the way up. A real company, five thousand people, departments and reporting lines, customer accounts and compliance regimes.

I want to be careful here because the moment I say "enterprise" people start expecting a different architecture. There isn't one. The shape is the same. There are more personas. The persona graph has more nodes and the edges follow the org chart. That's the whole change.

A salesperson has a Work persona scoped to their territory. An engineer has a Work persona scoped to the systems they own. A finance person has a Work persona scoped to the books they touch. There are shared personas above the individuals: the Account: $bigCustomer persona, the Project: Q3 launch persona, the Function: SecOps persona. Each of those is acted as by some set of humans (and their AIs) who've been granted the right to act as it. The audit story is the same: when an action happens, the persona is the named party, not "the AI" and not the generic department.

The pattern I'd point at: at enterprise scale, the shared persona for a customer account is what saves you. Every salesperson, CSM, support engineer, and finance person who touches that account is acting as the Account persona for that customer when they do account-related work. The Account persona owns the customer's data scope. The Account persona owns the relationship's audit trail. The Account persona is what gets handed off cleanly when the salesperson leaves. The Account persona is what gets paused if the customer fires you. You don't have to chase down which individual humans had which data. The Account persona had the data. Pull its grants and the access goes away.

This is the difference between SOC 2 scope and not, the callout I always make for the enterprise audience when I describe persona-as-identity. At household scale, persona-graph is a tidiness move; at enterprise scale, it's an audit move. The shape is the same.

Shared overlap = first-class persona Family persona first-class identity email RBAC audit Adult A Adult B acts as → AI for A AI for B ← acts as ledger: one identity, multiple grants It's not a folder dangling off two personas, it's its own persona.
The shared thing isn't a folder, it's its own persona.

What the overlaps actually are

Let me name the thing more precisely, because I keep gesturing at it.

In any persona graph at any scale, you have individual personas (one human acts as it, usually) and you have shared personas (multiple humans and their AIs act as it, usually). The shared personas are the overlaps. They're where the graph stops being a forest of independent trees and starts being something connected. The Family persona is an overlap among the adults in a household. The Sales persona is an overlap among the people on a sales team. The $bigCustomer Account persona is an overlap among everybody who works that account.

The thing I want to drive home: the overlaps are themselves first-class personas. They're not a shared region between two personas. They are their own persona. They have their own identity. They have their own RBAC. They have their own audit trail. They get acted as, by humans and AIs alike, with appropriate authority.

That's why the graph metaphor is the right one. The nodes are personas. The edges aren't "this human is connected to this human." The edges are "this human is granted to act as this persona." Same with the AIs. An AI acting in the Family room is the AI acting as the Family persona, granted by one of the adults in the household, with whatever scope that grant carries. When another adult enters the Family room, their AI is acting as the Family persona too, granted by them, with whatever scope they gave it. Same persona. Multiple grants. Multiple audit threads converging on the same identity.

The lifecycle side of all this, how shared personas get created, who's allowed to grant access, how they get retired when their reason for existing goes away, is the closer of this series. I'm writing it next week. See Suspending, retiring, and delegating personas.

The shape is the shape

This is the article in this series I've been most nervous to write, because the honest version of it is anticlimactic. There isn't a separate model for households and a separate model for enterprises. There's the same primitive, used at different fan-out. Personas, projects nested inside, shared personas where things overlap. That's the whole picture.

If you're reading this as somebody trying to organize the AIs in your household, you can start with maybe three or four personas, a Personal per adult, a shared Family, maybe a shared Finances. You don't need more than that to start. The graph grows as the household grows.

If you're reading this as somebody running a small business, you can start with maybe six or seven, each person's Work, plus Sales/Ops/Finance, plus one Customer Work overlap. Same shape. More nodes.

If you're reading this as somebody who actually has to run an enterprise rollout of an AI platform, then please, please, don't invent a new model. Map your org chart to a persona graph. Make the shared personas first-class. Use the same lifecycle motions you already use for employees. The platform should already do this. If it doesn't, ask harder.

The shape is the shape. It works at three personas and it works at three thousand. The reason it works at both is that the rules don't change, they just get applied more times.