Your AI Session Is Becoming a Provider Owned Runtime: TPMs Need Portability Acceptance Tests

A transcript is not automatically a portable AI session. In some provider workflows, the export is only a partial view of the runtime that produced the work: reasoning, hidden tool context, server identifiers, caches, subagent traces, and workflow state may remain on the provider side. That shift matters less as a philosophical warning than as an operating constraint: if you cannot inspect, export, replay, audit, and delete the session, you do not own the workflow.

The number that matters

The number is five. If a session cannot be inspected, exported, replayed, audited, and deleted, the team should treat it as provider owned runtime state, not a portable work artifact.

Treat each test as a release gate. Pass inspection only when the provider returns the full decision trail, including tool calls and delegated work. Pass export only when the returned package contains timestamps, approvals, inputs, outputs, and stable identifiers. Pass replay only when a second runtime can continue from the package without a private provider lookup. Pass audit only when an independent reviewer can reconstruct the action and its permissions. Pass deletion only when the provider returns evidence that the session, attachments, delegated state, and retained references are gone or are covered by a documented legal hold.

That sounds abstract until you put it in front of a procurement review, an incident review, or a legal hold request. The same session that looked like a neat chat log in the pilot becomes the only record of why an agent took a step, which tool it used, what hidden context it saw, and whether the vendor can later remove every retained object tied to that work.

The framework

"If the answer is no, the organization does not own the session. It leases a provider specific runtime with a convenient transcript attached."

1. Inspect the session surface. Can you see the complete decision trail, or only the polished user facing transcript? A real enterprise session may include tool calls, tool outputs, hidden instructions, compacted context, search results, and subagent messages. If the provider hides part of that path, the team cannot explain a result later or distinguish model behavior from platform behavior. TPMs should ask for a concrete export sample, not a promise that "everything important" is captured somewhere.
2. Export the evidence, not just the chat. A transcript download is not the same thing as a session export. You want the artifacts that let a reviewer reconstruct the work: prompts, tool inputs, tool outputs, timestamps, approvals, fork history, attachments, and server side IDs that tie the work together. If those objects come back as screenshots, partial JSON, or provider specific pointers, the export is useful for convenience but weak for governance. This is where pilots often overstate readiness because the visible conversation looked complete.
3. Replay the work in a different place. A session is only portable if another operator or another runtime can continue from the exported state without asking the original provider to rebuild the world. Replay does not mean identical next token output. It means enough of the work history survives that a second system can continue the task, validate the same evidence, and reach a defensible result. If the replay path depends on private provider data, the organization has a migration problem, not a portability feature.
4. Audit the action after the fact. The hard question in enterprise programs is rarely "did the model answer?" It is "why did the model do that action, with which inputs, under which permissions, and who approved it?" Auditability becomes more important when agents touch files, branches, emails, tickets, or external APIs, because the business impact is no longer confined to text. If the provider cannot reconstruct the action trail, TPMs cannot separate user intent, model behavior, and platform failure.
5. Delete the state you no longer need. A portability story needs an exit test. It also needs retention and legal hold behavior. If response IDs, caches, vector stores, conversation archives, or hidden context survive after the customer believes the session is gone, then deletion is partial and ownership is incomplete. TPMs should test deletion with the same seriousness they use for recovery. Use one session with delegated work and attachments. Then send a verified request to remove every retained object tied to it.

Sources

The signal set behind this brief is worth reading as a cluster, not as isolated news items. The portability argument is strongest in the Earendil essay on session portability, which frames ownership as a set of five practical tests. The product direction is visible in the OpenAI Codex v0.146.0 release notes, the GitHub Copilot stacked sessions article, and the GitHub stacked pull requests public preview announcement. A related community signal sits in this X discussion about who proposes, executes, and checks agent workflows.

A real TPM scenario

Picture an enterprise team that pilots a coding agent across three product squads. The vendor demo looks clean: sessions can be named, forked, and resumed, and the UI shows a tidy history. During review, the export contains an opaque session ID but no trace for one delegated tool call. But when a TPM asks for a redacted export that includes every tool call, approval, hidden instruction, and delegated action, the vendor returns a partial transcript and a few opaque IDs. The team can keep working, but they cannot prove what the agent saw, cannot compare the work to another runtime, and cannot satisfy the security reviewer who wants to know whether a sensitive workflow can be torn down cleanly.

That is the portability trap. The pilot succeeds because the interface is pleasant, then the organization discovers the real unit of work was never the text box. It was the provider managed state behind it.

What this does not solve

It does not make every provider equivalent. A portable session does not guarantee the same quality, latency, tool behavior, or cost on another platform. TPMs still need vendor comparison, model benchmarking, and workflow testing.

It does not remove privacy and redaction tradeoffs. Full inspection and export can conflict with secrets handling, user privacy, and retention policy. The right answer is not "export everything" by default. It is to define what must be visible, what may be redacted, and what must remain deletable.

It does not replace exit planning. Even if the session format is better, migration still needs mapping tables, governance controls, and a handoff path for the human operators. Portability is an acceptance test, not a substitute for a migration plan.

The signal that matters most

The strongest signal is that session lifecycle is being productized as workflow infrastructure. The Codex and GitHub examples in this article show named, forked, stacked, imported, or resumed work objects. They do not by themselves prove cross provider portability.

That is the moment TPMs should stop asking whether an agent is impressive and start asking whether the work survives outside the vendor. If the session cannot leave the platform with enough evidence to explain, continue, and delete the work, the organization is not buying a tool. It is leasing a runtime.

Send me three examples of session state you cannot export today : one sentence each. DM me on LinkedIn (Doron Katz). I am collecting working patterns into a public agent portability playbook; three examples would let me ship it next month.

Related

• 10 Projects/10 Personal Projects/PoolAccess
• Hermes Agent
• Kanban