12.6 Exit: Selling, Licensing, or Shutting Down

Every project ends. Three ways this one ends — selling the persona, licensing it, or winding it down — and the difference between a good exit and a messy one is decided months earlier, by how the asset was built.

This is the last chapter of the book, and it closes the loop on the earliest one: the choices in Part II about the character bible, and in Part IV about who owns the adapter, are exit decisions made in advance.

What the asset actually is

Six components, and a buyer or licensee is pricing all of them.

What is not on the list and never transfers: the platform account itself, in most cases. Platform terms commonly prohibit selling accounts, which is why the distinction between "selling the account" and "selling the persona" is not a nuance.

The practical consequence for what you built: if you trained your own adapter and kept your own library, you have something to sell. If the persona lives inside a vendor's character feature, you have outputs, and the identity is rented.

Scenario one: selling the persona

What is being sold. The identity artifacts, the library, the pipeline documentation, and the operating records — plus, usually, a transition period during which the seller helps the buyer stand up the persona's production.

What the buyer is buying. Not a face; a going concern with documentation. This is why chapter 12.5's audit file matters commercially: a buyer's diligence asks whether the business has been run deliberately, and four quarters of dated entries answers it.

Valuation, stated honestly. [UNVERIFIED] There is no established market with published multiples for synthetic personas. Comparable creator-account sales have historically been priced as a multiple of monthly profit, often in the range of six to twenty-four months, but that is a general creator-economy observation rather than a figure for this category, and it should not be treated as a benchmark. Offer it as a deal to be negotiated rather than a price to be quoted.

Factors that raise the price: consistent revenue over several quarters; documented composition (9.2); a trained adapter the buyer owns outright; a real audience outside the platform; clean rights documentation (11.4); an operating record (12.5).

Factors that lower it: revenue concentrated in one platform; a persona dependent on a vendor feature; undisclosed likeness or data-rights gaps; declining trend; no records; a niche whose audience does not follow the persona off-platform.

And the diligence questions to expect: where did the training images come from and what rights do you have (11.4)? Is the likeness derived from any real person? What are the disclosure obligations and are they documented (11.3)? What happens to the audience on transfer? Answer all four in writing before listing anything.

Scenario two: licensing

The structure. A written license granting defined rights: language, territory, platform, duration, and permitted content categories. You keep ownership; the licensee operates and produces; you receive a fee plus a revenue share, with approval rights over content and disclosure.

Why licensing is often better than selling. The price is lower per transaction and repeatable, the asset stays yours, and the approval rights keep the reputation risk bounded. Chapter 9.6 covers the commercial form; the exit-specific point is that licensing requires the same documentation as a sale, which again is built in advance.

The three clauses that matter most:

• Disclosure. The licensee is bound to your disclosure standard, not theirs (11.3). Without this clause, your persona's reputation is held by someone with a different risk tolerance.
• Approval rights. Content review before publication, at least in the categories most likely to cause a reputation event (12.4).
• Termination and reversion. What happens to the licensee's audience and assets when the license ends, and how quickly the persona's name is withdrawn from their channels.

And one its own compliance question. A licensee publishing as the persona is a deployer under the transparency duties (11.1, 11.3). The contract should say who carries that obligation, because the answer is not automatic.

Scenario three: winding down

The procedure, in order.

1. Announce or fade. A short, honest post, or a quiet stop. Either is defensible; a public disappearance with no note is what generates the "what happened to them" threads.
2. Wind down the monetization. Cancel or pause subscriptions, and handle outstanding obligations including refunds under EU consumer rules (11.8). Do not stop answering without notice.
3. Preserve the assets. Adapter, references, library, bible, and records go to archive (7.4). One order, dated, with a note on what it contains.
4. Delete personal data. Chat logs and any other personal data held about subscribers have a retention limit and a deletion duty (11.7). Deleting is a requirement, not a courtesy.
5. Close the accounts where required, or leave them static with a note. Static accounts with an active monetization link are the worst of both.
6. Write the lessons. One page: what worked, what did not, what you would do differently. This is the input to the next project, and it takes twenty minutes.

What must still be turned off, specifically. Payment processing, subscription renewals, automated chat sequences, scheduled posts, and any paid tooling on a subscription. An abandoned pipeline with a live payment method is a slow leak that runs for years.

The lessons file

One page per closed persona, four sections, and it is the most valuable document the project produces.

What worked — the specific things, with the numbers. Not "video performs better" but "video at eleven seconds produced four times the shares of stills over the July sample."

What did not — and why, if the why is known, which it often is not. Naming the uncertainty is more useful than inventing a reason.

What you would do differently — in the order you would change it.

What you would keep — the parts of the pipeline and the operating model that survive into the next project. For most operators this section is longer than the first three combined, because the process is more reusable than the persona.

Where this goes wrong

Selling something you cannot transfer. A vendor-feature persona has no identity artifact to hand over.

Selling the account, not the persona. Commonly prohibited by platform terms.

No records. Diligence fails and the price reflects it.

Quoting a price with no market. Present it as a negotiated deal.

A license with no disclosure clause. Your reputation, their risk tolerance.

Winding down without cancelling payments or renewals. A leak that runs for years.

Keeping subscriber personal data. A retention violation with a deadline attached.

Not writing the lessons. The next project repeats the same three mistakes.

The gate

1. Do you own a trained adapter for the persona, or is the identity rented?
2. Do you have four quarters of audit records and a rights documentation trail?
3. Could you answer a buyer's four diligence questions in writing today?
4. If licensing, does your draft license bind the licensee to your disclosure standard and give you approval rights?
5. If winding down, can you list every payment method, renewal, and scheduled job that must be stopped?
6. Do you know your retention limit for chat data, and the deletion path?
7. Do you have a lessons file for every persona you have closed?

What you leave with

The six components of the asset with what transfers and what does not, and why the adapter choice in Part IV is an exit decision; a sale scenario with the price-factors lists, the four diligence questions, and an honest statement that no published multiple exists for this category; a licensing scenario with the three clauses that matter and the deployer question; a six-step wind-down procedure with the specific list of things that must be switched off and the data-deletion duty; and a one-page lessons file that is the only part of a closed persona that reliably improves the next one.