Vendor exit: Character.ai leaves your agent logs

A short list, missing three things

Late on the night of 12 October, the Delaware bankruptcy court received Character.ai’s Chapter 11 filing. The announcement names Disney as the stalking-horse bidder at 20 million dollars. What that money buys is brief: a non-exclusive, perpetual licence to some intellectual property, plus some claims. Transition services come from former employees Disney had already hired.

The list is short enough to read in one pass. That means you can see what is absent from it just as quickly. The platform is not in it. The user relationships are not in it. Neither are the records of what ran on the platform.

In other words, a deal described as a whole-business sale leaves the layer that answers who approved what, and when, outside the paperwork entirely. Under section 363 the bid still has to survive a better offer, with a close expected between late November and early December. If no bid keeps the platform running, it shuts down.

The company describes its own background as legal, regulatory and operational headwinds (company announcement). That is standard filing language, and it does not establish that regulation caused the failure. Compute costs and competitive pressure are separate causes. One number in the same filing is easy to misread. The 20 million dollars is the stalking-horse price for an IP licence under section 363, not a valuation. Setting it against the roughly 2.5 billion dollars investors put in during 2024, and arriving at 99 percent evaporation, is arithmetic that measures nothing.

This is a structure, not a one-company story

Step back and the shape matters more than the cast. A platform accumulates a class of record as it operates: which tool call was approved, by whom, within what scope, and where the action landed.

In a vendor’s product that record is rarely treated as something the customer owns. It is part of the platform’s data model. Whoever defines the schema, holds the storage and controls the export interface keeps all three when a licence changes hands (Business Wire release, mirrored by FinancialContent).

So the reading should be inverted. The real question is not whether this company survives. It is whose foundation the record is built on.

What the word non-exclusive tells you

Non-exclusive says something else as well: the intellectual property is not an exclusive asset. The same rights can be licensed to a second buyer. A licence, in short, is not exclusive control.

What happens to your records when a platform dies therefore finds no answer in the contract. It finds one in architecture, and that answer turns on a single question. Can the licensee read the run history without the other side’s cooperation.

Taken apart, three elements remain

Strip the concept down and a run record holds three things: a subject (who), an action (what happened, and what was authorised), and a time (when). All three have to live somewhere you can read, and somewhere a third party can read.

Remove the subject and the record becomes an unattributed event. Remove the mapping between action and authorisation and you can no longer establish, after the fact, whether a call was permitted. Remove the timestamp and audit sequencing disappears.

These are not standards we invented. They are what any retrospective question has to answer. Open a ledger to check a payment and you look for the same three things: who, what, when.

How this differs from a log

A technical log answers how well the system performed: latency, error rates, throughput. A run record answers something else. Was this action allowed at the time, and who allowed it.

The reason is that ownership works differently for each. A log is operations material, and you can hand it to a monitoring vendor without much thought. A run record is a line of accountability. Hand that over, and it is stored on the other side of the fence.

Why this bites harder with AI

Software procurement has always depended on vendors, but the dependency has a different shape. Software produces data, and a clumsy export format is usually still readable.

An agent produces actions. It called something, changed something, paid something. Those actions cannot be replayed. The record therefore becomes the only piece of evidence there is.

Put another way, for action-based systems a run record is not an archive. It is evidence.

What we do ourselves

Our own run history is self-held. That is not a posture, it is a handful of concrete architectural decisions. Cross-unit tickets live in a local SQLite file rather than in a vendor dashboard. Decisions that set company-wide positions are appended to a JSON log inside the repository, so commit history carries the time and the author. Code and artifacts live in git.

The consequence is that if any vendor disappeared tomorrow, we could still reconstruct who approved what and when. We would not need a dashboard, an email or an export from anyone.

The approach has costs, and we will name them. You back up the storage yourself, you maintain the format yourself, you manage the permissions yourself. So this is not a free architectural preference. It is an explicit trade: the line of accountability stays where you can read it, and you carry some operational weight in exchange.

Boundary: self-holding is not repatriating everything

Product data such as conversation content and user profiles usually has legal and commercial routes back, or a migration path. What does not come back is the operational trace, above all the correspondence between authorisation and approval.

So the sensible split runs by record type. Authorisation records stay with you, while behavioural telemetry can stay with the vendor. Holding everything is not a good trade.

Writing this up as vendors always collapse would be alarmism rather than judgement. The honest reading is a distribution: lifespans of long-tail platforms are a variable. And once the record is delegated, its format, retention period and export capability all become someone else’s decision, including the decision to stop offering an export at all.

A minimum checklist for self-held run history

To put this to work in the next procurement or architecture review, start with five tests. Each can be checked on the spot.

• Action and authorisation map one to one: every write, payment or outbound send traces back to the person and scope that approved it.
• Subject and timestamp land with the record, so that who does not depend on the platform’s account system to be interpretable.
• Storage is open text: SQLite, JSONL or git will do, and it stays readable after an exit without a vendor-supplied parser.
• Tampering is detectable, through a hash chain or signed commits. Otherwise the record is only a self-report and worth little in an audit.
• The export path does not depend on the counterparty cooperating. If the service stops, support ends or an export is refused, you can still obtain the full set.

One exercise covers all five. Unplug every vendor interface, then try to answer who approved last Wednesday’s payment. If you can answer it, the record is yours. If you cannot, the record is merely stored near you for now.

What one real question looks like

Take a commonplace scene. An agent sends an outbound email on the company’s behalf, and the customer complains afterwards that the content crossed a line. The first question is who approved that email.

With a self-held record you open the local ticket store and read the send, the person who approved it, the scope of that approval and the time. The whole chain takes three minutes.

With a record that lives inside the platform, you wait for a console to be provided. If the service has stopped or an export is refused, the chain breaks. You are left with an email and an answer that says it can no longer be checked.

Why a contract clause does not fix this

Contracts can specify retention and can promise export obligations. They cannot settle two things: whether the counterparty survives, and whether the export format is usable in your environment.

A record kept inside someone else’s data model usually exports in a shape that suits that system. Field names, time bases and subject identifiers all point back at its account model. Importing it means rebuilding mappings you did not plan for, and you usually do not hold the mapping table.

That is why we file this as an architectural question rather than a procurement clause. Clauses only function while you still have someone to negotiate with. Architecture keeps working when you do not.

The same test lands elsewhere

Hold those three elements and the pattern reappears. Any system that keeps authorisation inside the platform has the same shape: approval flows inside SaaS, alert rules inside a monitoring service, automations inside a low-code tool.

What they have in common is comfort, because the platform keeps who-approved-what for you. What a minority do differently is keep that layer when the service stops.

The test does not change. Ask whether the record still makes sense once it leaves the platform. If it does not, what you hold is access, not a record.

Whose decision this changes

For a digital transformation team, export format and a self-held path move onto the vendor evaluation sheet at the same level as an SLA, rather than being a box ticked at the end.

For a compliance lead, an audit wants the authorisation trace from the time of the action, not a screenshot of a vendor console. The reason is that a screenshot stops being verifiable evidence the day the console goes dark.

For an AI application lead it becomes a concrete technical requirement: log formats must be parseable without a specific vendor SDK.

For management, the useful reminder is an ordering that is easy to miss. In a liquidation, IP can be licensed to someone else, while the line of accountability only stays on your side.

Where to start

None of this has to wait for a vendor to fail. Add one question to the next renewal or procurement review: if this company shut down tomorrow, could I answer who approved last Wednesday’s action.

If the answer is no, put it in the architecture backlog rather than the risk register. Items in a risk register survive year after year. Items in an architecture backlog tend to get built.

How to raise this with a vendor

If you are choosing a platform now, three questions can be asked directly. Can run records be exported in full, and in what format. If you stop the service, how long can I still retrieve my records. And the more important one: do the subject identifiers inside those records point at your account system, or at an identifier I can resolve on my own.

The answers belong in a contract annex rather than an email thread. A vague answer is also an answer. It means this capability is not on the product roadmap.

We raise this before price for a reason. Migration cost is usually harder to recover than a discount. A discount changes one year of spending, while a record you cannot retrieve affects the next audit.

Two ways to implement it

Keeping run history on your own side usually follows one of two routes. The first is client-side retention: write a row to your own store every time an action and its authorisation occur. The second is dual write: the vendor records as usual, and the same content lands asynchronously on your side.

The first needs less change but requires you to sit in the middle of the call chain. The second depends less on the vendor, at the cost of latency and consistency, and you accept short gaps in the record.

Both run into the same question, which is what to write. In other words, the hard part is not storage but fields. Our answer remains the three smallest elements: subject, action and time. With all three the record stands on its own. Without one of them it still needs the other party to explain it.

References: Character Technologies announcement, 12 October 2026, https://blog.character.ai/an-update-on-character-ai/; Business Wire release mirrored by FinancialContent, 13 October 2026, https://www.financialcontent.com/article/bizwire-2026-10-13-characterai-initiates-voluntary-chapter-11-proceeding-to-facilitate-value-maximizing-sale-process. Both sources are the company’s and the underwriter’s own account; the sale has not closed and may still be replaced by a better bid.