A lot of people already feel covered. Their context is in ChatGPT memory, Claude project files, a chat history, or a model workspace, and that feels organized enough.
Here is the cost. The day you want to leave that model, the memory may not come with you in a usable form. The day a client questions a decision, you are scrolling a chat log instead of querying a record. The day a model summarizes, forgets, or buries the thread, you may lose the reasoning without knowing the moment it happened.
A vendor memory can be useful. It should not become the only place your working memory lives.
The obvious answer is already becoming a product category: connect all your tools, pull everything into one surface, and let the model or agent reach for whatever it needs. That can be useful. It can also hide the real failure. If every tool gets broad access in case it might need context later, you have not solved fragmentation. You have made fragmentation easier to query.
The new sprawl is context sprawl
Organizations already understand file sprawl: too many shared drives, too many Slack channels, too many project boards, too many versions of the same deck. They know the pain of finding the document and still not knowing why the decision was made.
AI creates a different kind of sprawl. The documents may still be scattered, but now pieces of the thinking move through systems that were never designed to hold the record.
A model sees a prompt. A copilot sees a ticket. An agent sees a task. A meeting assistant sees a transcript. A sales tool sees account history. A document tool sees drafts and comments.
Each system sees enough to be useful. None of them owns the whole story.
The immediate problem is that every AI system knows a fragment, acts on the fragment, and leaves another fragment behind. The organization gets more AI activity and less human understanding of the record underneath it.
The question is no longer only where the file lives. It is where the source, decision, approval, draft, correction, and useful answer land after AI has touched the work.
One giant memory is the wrong shape
For consultants and agencies, owning the record is not one giant memory. It is separate records, designed so Client B work starts from Client B's selected record by default, not from Client A's notes.
For a person, the same pattern appears in a private record. A journal, financial note, or health timeline may be useful to ask across, but it should not become permanent memory inside a model workspace. The record should remain organized around the person, with selected context used for the task at hand.
That context should not have to persist in the destination after the task.
Picture asking across three years of private notes before a doctor's appointment: what changed, what did I try, what did I decide, and what am I forgetting? The useful answer may need a few selected notes, dates, and prior decisions. It should not require turning the whole journal or health timeline into permanent memory inside the model you happened to ask.
Agents make the record question unavoidable
Agents make context sprawl harder to ignore.
A chatbot can be treated as a destination: paste something in, get something out, move on. An agent is different. An agent needs permissions, tools, context, and rules for what it can carry between systems.
The industry is already moving in that direction. Anthropic introduced the Model Context Protocol in late 2024 so assistants could connect to data sources and tools through a common interface. OpenAI launched agent-building tools in 2025 around the Responses API, tools, tracing, and retrieval. Google introduced Agent2Agent in 2025 to let agents communicate across systems.
That direction is useful, and it makes custody unavoidable. A workflow that runs through AI changes where information travels, where decisions are recorded, and who can explain the trail later.
The question is simple:
Where does the working record live?
If the answer is wherever the agent happened to run, the organization has a problem. If the answer is inside each model provider's memory, the organization has a problem. If the answer is every connected SaaS tool, partially and inconsistently, the organization has a problem.
The record needs a home before agents become routine.
Bring-your-own-AI was the warning light
The first stage of AI adoption did not wait for procurement. Microsoft's 2024 Work Trend Index found that many knowledge workers were already bringing their own AI tools into work rather than waiting for an official company system.
That was the warning light. The first layer of adoption was being assembled by people trying to get through the day.
This pattern is familiar. Email, messaging, cloud documents, consumer file sharing, task managers, and collaboration apps all spread through a mix of official procurement and unofficial use. AI is different because the unit of value is context.
When an employee brings a chat model into work, they create a new path for organizational knowledge to move. Maybe it is harmless. Maybe it is useful. Maybe it is against policy. Maybe it is the only reason the work gets done.
The risky version is quieter: client material, research notes, donor context, roadmap details, sales history, or personnel notes can end up inside a personal account the organization cannot search, govern, export, or remove.
A lot of AI privacy conversations stop at "we don't train on your data." That matters, but it is a small slice of the question. Depending on the tool, account type, and settings, a provider may still process prompts and outputs to run the service, retain logs, review abuse or safety signals, store workspace memory, or leave useful context inside an account the organization cannot govern. Training is one path, and I will write more about training and data use soon. Custody is the broader problem here. I wrote before about why privacy is control, not hiding, and about why model choice should change by task. The missing piece is where the record lives while those choices happen. This is not a request to hand us everything in the clear.
The Wheel is designed to keep the record encrypted under your key. For a task, only the slice you approve is decrypted, only for the task you approve, and only while that grant is active. Outside an active grant, we cannot read it.
If every team creates its own AI paths without a shared record, the organization forgets how it got there. The work happened. The insight happened. The prompt happened. The draft happened. The route happened. But the durable record of the thinking is nowhere.
Or it lives in the wrong place: inside a vendor account, a chat history, an automation log, a tool-specific memory, a model provider interface, or a workflow nobody else can inspect.
That is how an organization loses custody without a dramatic breach. It happens one useful shortcut at a time.
What owning the record looks like
Owning the record is operational. It means knowing where the source, note, question, decision, draft, objection, correction, meeting, and client constraint live. It means deciding what becomes durable. It means letting approved tools use selected context without making those tools the permanent archive.
This is the distinction I have been building The Wheel around: the record should have a home before a model or tool uses it.
The Wheel is not a model. It is my attempt to keep the durable record separate from the destinations that use selected context from it. That distinction matters. A destination may receive the slice needed for a task, but the destination should not become the archive.
There is an important boundary here. When selected context leaves for an approved model, The Wheel can keep the durable record, the source trail, and the task record. What the destination retains or uses is governed by that destination and the account terms attached to it. That is exactly why the archive should live with you, not inside whichever model workspace happened to be useful first.
Other tools are moving toward scoped access too, and I think that is good. The question is what the scope controls in practice. The destination should receive the minimal context it needs to do the job you asked it to do well, not the whole record. That permission should be visible, limited, and revocable for future requests. Revoking permission cannot pull back context already sent to a destination, but it should stop that destination from continuing to reach into the record.
The hard part is not saying "selected context." The hard part is deciding what gets selected, who approved it, where it went, and what came back. That is the product work.
Picture a new hire asking, "Why did we choose Postgres for the customer workspace?" The useful answer includes the decision, the source conversation, the constraint that mattered, and the person or team that approved the path. If a model drafts a follow-up from that context, the model receives the selected record slice for the task. The model does not become the archive.
For an agency, the same pattern might mean an account lead drafts a Client B deliverable from Client B's selected record, with Client A's notes outside the task scope and a task record showing which slice went to which destination. For an individual, it might mean asking across a private journal, financial note, or health timeline without turning the model into the permanent home for that memory.
If you change model providers later, the goal is that the working record stays with you in exportable records, rather than being stranded in the model workspace you left.
The record belongs with the person or team doing the thinking. Other systems can use it when invited.
Build the record before the sprawl hardens
The easiest time to build custody is before the sprawl hardens. The next best time is before the next workflow gets added to the pile.
An organization using AI can let context scatter across prompts, tools, automations, agents, chats, transcripts, and provider accounts. Or it can decide that its memory needs a home.
A growing organization adding AI quickly has the same choice, only with more urgency. The workflows are multiplying. The shortcuts are spreading. The unofficial tools are already in use.
For teams and people who already have years of chat logs, starting now still matters. You do not have to migrate every old thread in a weekend. The useful move is to make new decisions, sources, approvals, and reusable context land in a record you can query later.
Most AI adoption conversations focus on capability. Which model is best? Which agent can do the task? Which tool saves the most time? Which team can automate the most work?
Those questions matter, but they sit on top of a custody question:
When all of those systems start working, who owns the record?
My bet is simple: keep the private record first, let approved models, agents, and tools use selected context when the work calls for it, and bring useful work back with available sources and decisions attached.
Every new AI workflow can add to the sprawl or strengthen the record.
The cost is lower before the record scatters. Starting now still matters.