Suspending, retiring, and delegating personas

This is the last article in the personas series, and I want to use it to land the plane on the thing I've been circling for three months. The whole pitch is that a persona is a first-class identity, a named, scoped, accountable container for what an AI sees, remembers, and acts as. Once you accept that, the lifecycle questions get easy. They get easy because the answers are already familiar. You already know how to do this, because you already do it for the humans in your life.

Personas get hired. They get suspended when their reason for existing changes. They get delegated to other humans (and other AIs) for a defined window. And eventually they get retired with audit retention. Every motion is something you've seen before, applied to a new kind of entity. The point of this article is to walk through the four motions in order and show you that there's nothing exotic about any of them, and that, conversely, if your AI platform doesn't support these four motions. It's not yet doing the job.

Hired (created with a job description)

A persona isn't a checkbox you tick. It's a thing you stand up on purpose, for a reason, with a scope. The act of creating a persona is the act of writing its job.

What does that look like, concretely? When I spin up a new persona (the blogging persona, or a side-project persona for something I'm prototyping) I'm answering five or six questions before any code runs. What does this persona exist to do, and whose authority is it acting under? What tools does it get, and what data scope does it get? Who else is allowed to act as it, and when should it be reviewed? Those answers become the persona, and they aren't comments in a config file. They are the persona's charter, the thing the audit log will reference later if anyone asks why this persona did the things it did.

I want to make this very concrete at each scale, because I think a lot of people only do this step at the enterprise tier and skip it at the personal one, which is a mistake.

Personal. When I create a blogging persona, I write down: this persona exists to help me draft and publish on the EOTM blog. Its scope is the blog repo, the Ghost API, and the comment store. It does not have access to my personal calendar or my work email. It can be acted-as by me and only by me. Three sentences. Pinned to the persona forever. When future-me looks back and wonders why the blogging persona had a key to that tool, future-me can read the charter and remember.

Small business. When you create a Sales persona for your consulting shop, you write down: this persona exists to manage the client pipeline and the sales tooling. Scope: CRM, prospect notes, proposal templates. Acted-as by you and your co-founder, reviewed quarterly. Same shape as a personal one: three sentences plus a review cadence. That review cadence matters. It's the thing that prevents personas from accumulating tool grants for five years without anybody asking whether the persona still needs them.

Enterprise. When a security team approves the creation of, say, a Treasury-ops persona, the charter probably runs to a few paragraphs and gets signed by a couple of people. But it's the same shape: job description, scope, acted-as-by list, review cadence. The fact that it has more signatures on it doesn't change what it is.

The reason I lean on "job description" is that it forces a particular kind of clarity at creation time. You can't write a job description for a persona whose job is "do useful AI stuff." You have to say what useful, for what, with what data, on whose authority. If you can't write it, you don't have a persona yet, you have a vague intent, and you should not be issuing it credentials.

Suspended (paused, not deleted)

A persona being suspended is different from a persona being deleted. This is important and I want to be careful.

Suspension means: this persona is no longer authorized to act. Its credentials no longer authenticate. Its agents stop. Its scheduled jobs don't fire. Anything queued up under its name does not run. But the persona still exists. Its memory, its audit log, and its data are all still there. We've just turned its ability to do anything off.

The motion I keep going back to: when an employee leaves a job, you don't shred their laptop and erase every record of them. You revoke their credentials, freeze their accounts, set their email to forward-and-eventually-delete, and lock down their workspace. Their history is still there because the history is what you reference when somebody asks what happened on a particular date. The history is the audit story, and the history is non-negotiable. The ability to act is what you withdraw. Same shape for a persona.

The most concrete personal example: I leave a job. The Work persona that was scoped to that job suspends. Its email starts auto-forwarding to a successor address. Its memory store seals, read-only, no new writes, no new reads from outside the audit context. Its tools disconnect and its agents stop. The persona is still there; it can be inspected, it can be referenced, it just can't do anything anymore. After some agreed retention period, more of it can be retired (see the next section). But suspension is the immediate move.

For a household, the same shape applies when a project ends. The Q4-kitchen-renovation persona that you stood up to manage the contractor and the invoices and the deliveries, when the renovation is done, that persona suspends. Its agents stop drafting things. Its tool grants release. Its memory seals. If a warranty issue comes up two years later, the persona's records are still there to look at. But it's not still spinning up agents.

At the small-business and enterprise scale, the suspension motion is what saves you when somebody leaves the company. A salesperson departs, every persona they were granted to act as, you can pull their grant in one motion. The personas themselves keep going (the Sales persona is shared, other people still act as it). The leaving person's ability to act as those personas is what suspends. Clean, fast, audited.

The thing I want to flag: suspension has to be reversible. A suspended persona that gets reactivated should pick up where it left off, same memory, same scope, same audit thread continuing from where suspension paused it. If your platform deletes the persona on suspend, your platform is doing the wrong motion. That's not suspension. That's retirement. They aren't the same thing.

Delegated (acting on behalf, for a window)

This is the one I think is most underused, and also the one I think is most important for autonomous-agent design (which I just wrote about last week, see Autonomous agents inherit the persona).

Delegation means: persona A grants persona B the authority to act on its behalf, for a defined window, with an explicit scope. Maybe the easiest example: I'm going to be off-grid for a weekend, and I want my assistant persona to be able to do certain things in my Personal scope that it normally can't. I delegate. I write the grant: this persona can read these calendars, send to these recipients, draft (but not publish) blog comments, for this window. When the window closes, the grant evaporates. Anything the assistant did during the window is in the audit log, attached to both the assistant persona that did it and the persona on whose behalf it was acting.

This is meaningfully different from "let the AI do whatever." A delegation has a defined start, a defined end, an explicit scope, and a clear provenance trail. If something goes sideways, you can pull the delegation early, and the persona reverts to its base scope.

Personal scale: I delegate my assistant persona to handle inbox triage for a four-day trip. Scope: read my personal inbox, draft replies to anything from a specific allow-list, file the rest. End: when I get back, the delegation closes automatically. Anything drafted is sitting for me to send.

Small business: a partner is on parental leave. They delegate their Sales-persona authority to a teammate for the leave window. Teammate can act as Sales for that span, with the same scope the partner had, audited as a delegation. When the partner returns, the delegation closes. No emergency credential-passing, no shared password.

Enterprise: this is honestly where the formal version of delegation already lives, under names like "out-of-office delegation" or "act-as authority." The persona model isn't doing anything new here. It's just making the motion uniform across humans and AIs. The Treasury-ops persona's authority can be delegated for a window. So can my Personal-blogging persona's authority. The shape is the same.

The discipline I'd ask of any system handling this: every delegation has to carry the chain. When a delegated agent acts, the log entry says "agent X, acting as persona A, on delegated authority from persona B, granted on date D, expiring on date E." That's the audit truth. If your platform records just "agent X did the thing," you've lost most of what makes delegation safe.

Retired (closed, with audit retention)

Eventually a persona's reason to exist ends. Not paused, over. The job is done, the project shipped, the business shut down, or the household configuration changed. Whatever the reason, the persona is now done.

Retirement is the formal close. Tools disconnect. Memory archives (not deletes, archives, with a retention policy attached). The audit log is finalized and sealed against further writes. The persona is now historical. It can be referenced, somebody asking "what did the kitchen-renovation persona do back in 2026" can still get an answer, but it can't act, can't be delegated to, can't be reactivated as itself. If you want to do that work again, you stand up a new persona with a new charter. You don't resurrect the old one.

The reason retirement and suspension are different: suspension keeps the option open. The persona could come back. Retirement closes it. The persona is finished. The audit history is the only thing that survives, and it survives forever (or for the retention window you agreed to at hire time, which you set in the charter, which is part of why writing a charter at creation matters).

This is where the audit story has to be airtight. If you're running anything where a regulator might ask about an action a persona took, the persona's full lifecycle (hire date, suspension events, delegations granted, retirement date) has to be queryable years later. That's the entire reason persona-as-identity is the model (see Personas are first-class identities, not service accounts, back in week three). Without first-class identity, retirement is just deletion, and deletion is the wrong motion for anything that ever had authority to act.

Tying it back

I started this series with the simple claim that personas were the missing primitive, that most AI today is one big shared context, and that shared-context is what produces the wrong-calendar-in-the-wrong-place, the personal-secret-leaking-into-work-search, the production-data-in-the-dev-context failures that keep showing up everywhere I look.

The argument for personas isn't aesthetic. It's operational. A persona is the unit you can hire, suspend, delegate, and retire. Those four motions are how grown-up systems handle accountable entities. We do it for humans. We can do it for AIs. The reason we have to do it for AIs is that the AIs are now acting, they're sending emails, moving money, drafting documents, running unattended for hours at a time. Anything that can act has to be an entity you can pause and answer for. There's no version of this where you skip that part.

At household scale, this is comfort and trust. The personas in my house do the things they're supposed to do, in the scopes I gave them, and when their job is done, they retire cleanly. Nothing bleeds.

At small-business scale, this is hand-off-ability. When somebody leaves, you don't have a six-month archeology project to find out what their personal automation was doing. The personas are documented. The audit is in place. You suspend, you reassign, you carry on.

At enterprise scale, this is SOC 2, ISO, GDPR, every audit acronym you can name. It's also basic security hygiene, every actor on your network should be a named, scoped, suspendable entity. If "the AI" is acting on your behalf and the audit log just says "AI," you don't have hygiene. You have a problem waiting to find you.

The thesis of this whole series fits on one line: treat the AI like an employee, because that's what it is now. The persona is what makes that treatable. Hire it, suspend it when its job changes, delegate it for windows, and retire it when it's done. Same playbook. Deliberately.

That's the close. Thanks for reading the series. Next month I start a new arc, but the personas language will keep showing up, because it's the load-bearing primitive for everything else. You're going to see it again.