Why you don’t really own your AI agent sessions

AI agents are quickly becoming the way many of us work with large language models. They run on your machine, call tools, write and read files, and feel like they’re truly “yours.” But under the hood, a lot of what makes an agent smart and useful actually lives on remote servers—and that has big implications for ownership, transparency, and long-term control of your work.

How AI agent sessions actually work

When you use an AI agent, you’re not just sending one-off prompts. You’re building up a session: a growing history of messages, tool calls, and results that the agent uses as context to solve complex tasks over time.

On your machine, this often looks like a log file (for example, JSONL) that contains:

• Your messages to the agent

• The model’s replies

• Tool calls the model requested (like “read this file”)

• The results of those tool calls (like the file contents)

The agent harness running locally stitches all of this together into a context window and sends it to the large language model (LLM) via an API. The LLM itself doesn’t remember anything between calls; it only knows what you send each time. The illusion of a continuous conversation comes from the agent constantly resending this session context with every new request.

Reasoning models and hidden “thinking”

Frontier models today are marketed as reasoning models. Instead of jumping straight to an answer, they can generate intermediate “thoughts” that help them decide what to do next—like whether to call a tool, which plan to follow, or which code path to try.

In theory, that reasoning could be visible to you: a detailed chain of thought that shows how the model arrived at its answer. In practice, many providers now hide most of that reasoning behind encryption.

What you typically see in your session logs is:

• A short, human-readable summary of what the model was thinking

• A block of encrypted content that you cannot decrypt

Only the provider (e.g., OpenAI or Anthropic) can decrypt that block. When you send the next request, they can recover the full internal reasoning from their side—but you, the person running the agent, only ever see the summary.

Why hidden reasoning is a problem

At first glance, this might seem harmless. The model still works, and you still get answers. But there are three big issues: transparency, billing, and ownership.

1. You lose transparency into what the model is doing

If most of the model’s reasoning is encrypted, you can’t see what it actually considered. You don’t know which options it weighed, which paths it rejected, or whether it flirted with obviously wrong or dangerous ideas before landing on the final answer.

That makes it harder to:

• Debug weird behavior

• Spot early when it’s going in the wrong direction

• Understand why it made a particular decision

2. You pay for tokens you can’t see

Those hidden reasoning tokens aren’t free. You’re billed for them, just like for any other tokens the model generates. But because you can’t see the full content, you have no way to audit or verify what you’re paying for.

You don’t have to assume bad intent from providers to feel uneasy here. Being told “trust us, the bill is correct” while you’re locked out of most of the content is not a great position to be in—especially if you’re running agents that rack up large usage.

3. You no longer truly own your session

This is the most serious consequence. Your local session log no longer fully represents what actually happened. A big chunk of the model’s true state is effectively stored in an opaque, provider-controlled format.

That breaks one of the core promises of agent harnesses: that your session is a portable, self-contained record you can reuse, migrate, or resume later, on your own terms.

Portability: why encrypted sessions lock you in

When part of your session is encrypted and only the original provider can decrypt it, your ability to move that session around is severely limited. Several common scenarios become fragile or impossible:

• Switching models mid-session. Maybe you planned a feature with one model but want to implement it with another that’s faster or cheaper. If the new model can’t understand the encrypted reasoning, it’s flying half-blind.

• Switching providers. If you want to move from, say, OpenAI to another provider, those encrypted chunks are dead weight. No other model can interpret them.

• Resuming old work with new models. You might return to a months-old session to fix a bug or extend a feature. If the provider has changed how encryption works—or dropped support for that format—your old session may no longer fully function, even with the same vendor.

Each of these cases chips away at your control. The more your agent depends on provider-specific, opaque state, the harder it becomes to treat your sessions as durable assets you own and can move freely. This is exactly the kind of lock-in many people are trying to avoid by building their own agents in the first place, as explored in why you should own your AI agent before Big Tech does.

Why providers encrypt reasoning in the first place

Model providers usually justify encrypted reasoning as a way to prevent distillation: competitors (or entire countries) training their own models by copying the outputs of frontier systems.

The argument goes like this: if you can see the full chain-of-thought, it’s easier to train a smaller model to imitate it. By encrypting that reasoning, providers hope to make it harder to clone their capabilities.

Whether you find that convincing or hypocritical—given that these models are often trained on massive amounts of public content—is a separate debate. The important point for users is that this anti-distillation strategy directly impacts your visibility and control over your own sessions.

Server-side tools: when tool calls leave your machine

Agents rely on tools to do anything beyond pure text: reading and writing files, running code, calling APIs, or searching the web. Typically, the pattern looks like this:

• The model decides it needs a tool (e.g., “search the web”).

• It sends a tool call request as text.

• Your local agent harness executes that tool (on your machine or via an API).

• The tool result is added to the session and sent back to the model.

For many tools, this local execution is essential. If the model wants to read a file, that file lives on your system, not on the provider’s servers.

But some tools—especially web search—don’t have to run locally. Many providers now offer built-in web search tools that run entirely on their servers. When you enable these, the whole loop (searching, fetching pages, analyzing content) happens remotely.

What you get back is usually:

• A summary of what was found

• A list of source URLs

What you don’t get is the detailed, step-by-step trace of:

• Which queries were run

• Which pages were fetched

• What content was extracted and how it was evaluated

That means your session now contains only a compressed view of what actually happened. If you later move that session to another agent or model, it will only see the summary, not the rich raw data that informed it.

Server-side compaction: smarter context, less ownership

Every model has a maximum context window. For long or complex tasks, your session will eventually hit that limit. To cope, agents use a process called compaction.

In a simple, client-side setup, compaction looks like this:

• The agent takes the existing conversation history.

• It asks a model to summarize or compress it.

• It starts a new, shorter context that contains that summary plus the most recent details.

This is imperfect—you lose some detail—but it’s transparent and fully under your control. The summary lives in your logs as plain text.

Some providers now offer server-side compaction. Instead of you managing context, they store richer, more complex internal representations on their servers and give you back a reference or key. Future requests can point to that key, and the provider reconstructs the context behind the scenes.

The upside: potentially better, more efficient use of context. The downside: you no longer have the full, self-contained session. You just have a pointer to something that lives entirely in the provider’s infrastructure. If that feature changes or disappears, a chunk of your session’s “memory” goes with it.

Hosted conversation state: convenience by default

Another growing pattern is hosted conversation state. Instead of you sending the full context with each request, the provider stores the conversation on their side and lets you refer to it with an ID.

In many SDKs, this is controlled by a flag like store:

• store: true (often the default): The provider keeps track of the conversation state. You send just the new message plus a reference to the last response ID.

• store: false: The provider is stateless. You must manage and send the full context yourself.

Using store: true is convenient: less data over the wire, simpler code, and automatic session handling. But it comes with a big trade-off: you are no longer the primary owner of your session state. You don’t have a complete local record of what the model is seeing and using as context.

If you later want to:

• Move that session to another provider

• Replay or inspect the full conversation state

• Audit what was actually stored and used

you’ll find that you’re missing key pieces. The real source of truth lives on the provider’s servers, not in your own logs or database.

Why this trend should worry power users

None of these features—encrypted reasoning, server-side tools, hosted context—are evil on their own. They solve real problems: protecting model IP, improving performance, simplifying integration, and making agents feel more capable.

The problem is the direction of travel. Step by step, more of your agent’s real state and intelligence is being pulled away from your machine and into opaque systems you don’t control. Over time, this means:

• Less transparency into what’s happening

• Less ability to audit costs and behavior

• Less portability across models and providers

• Less confidence that you can resume or reuse old work in the future

If you care about owning your workflows, your data, and your AI-assisted code or documents, this should be on your radar—especially as you build more complex, long-lived agent setups or even your own personal agentic operating system.

Practical steps to keep more control

You don’t have to reject all provider-side features to regain some ownership. But you should make conscious choices instead of accepting defaults. Here are some practical steps:

• Disable hosted conversation state where possible. If your provider has a store flag or similar, set it to false and manage your own session logs. Keep a complete, plain-text record of prompts, responses, and tool calls.

• Prefer local or transparent tools. For web search and other external tools, consider running them in your own harness or via APIs you control, so you can log the full inputs and outputs.

• Be cautious with server-side compaction. If you use it, understand that some of your context will live only as an opaque reference. For critical work, you may prefer simpler, client-side summarization that you can fully inspect.

• Design for portability. Treat your session logs as assets you might want to replay with different models or providers later. Avoid features that bake in provider-specific, non-portable state unless you’re comfortable with that lock-in.

Owning your sessions in an agent-first world

AI agents promise a future where you have a powerful, programmable assistant that truly works for you. But that promise only holds if you retain real ownership over the sessions that define your work: the plans, decisions, tool calls, and reasoning that accumulate over time.

As providers push more logic and state to their servers, it’s on users and developers to push back where it matters: insisting on transparency, managing our own context where we can, and being clear-eyed about the trade-offs of convenience versus control.

If you’re building serious workflows on top of AI agents, now is the time to think not just about what your agent can do today, but about who will really own its memory tomorrow.