7 min read · Written on September 5, 2026

In the 2000s and early 2010s, most applications managed authentication and authorization independently. Every application had its own username and password system, its own user database, and its own way of deciding what a user was allowed to access.
This worked, but it created a fragmented internet. Users had to create accounts everywhere, remember credentials, and repeatedly provide the same information to different applications.
Then identity providers changed the model.
Protocols such as OAuth changed how applications could interact with user identity and permissions. Instead of every application owning the entire authentication process, applications could rely on established identity providers.
This led to the rise of social sign-ins.

Today, when a website offers "Continue with Google", the website does not need to manage your Google credentials. Google authenticates you and provides the application with information that you have authorized it to receive.
The important architectural change was that identity became portable.
An application could request specific information and permissions from an identity provider without needing to own the user's entire identity. Users got a simpler experience, applications avoided managing another authentication system, and users gained more control over what information they shared.
OAuth established a standardized mechanism for controlled information and permission sharing between systems.
AI is now creating a similar problem, but with something more personal than identity.
When you use an AI assistant over a long period of time, it can learn things about you.
It can learn your preferred writing style, the technologies you use, the projects you work on, how detailed you like your answers, and the kinds of recommendations you prefer.
In other words, AI systems are building something more useful than a traditional user profile.
They are building contextual knowledge about the user.
The problem is that this knowledge is largely trapped inside individual AI ecosystems.
Your conversations with one AI provider help that provider understand you. Your conversations with another provider help that provider understand you separately.
You might spend months teaching one AI assistant how you work, only to start using another and effectively begin from zero.
That is another form of fragmentation.
Imagine that your AI memory was not permanently tied to a particular AI provider.
Instead, you had a personal memory layer that you controlled. Your interactions with AI systems could contribute information to this layer, while different AI agents could request access to specific parts of it, with your explicit permission.
Conceptually, the architecture could look like this:
User → Personal Memory Provider → AI Application
When you start using a new AI agent, instead of explaining your preferences from scratch, the agent could request access to relevant memories.
For example:
"Can I access the user's software development preferences?"
You approve, and the memory provider returns only the relevant information.
The AI does not need access to your entire history. It receives the minimum context required to provide a better experience.
This follows the same principle that makes modern authorization systems useful:
Give applications access to what they need, not everything you have.
The next evolution could be a standardized protocol for AI memory sharing.
Conceptually, it could provide AI applications with APIs for requesting user-controlled contextual information, with permissions defined through scopes such as:
profile.preferences
coding.preferences
writing.style
professional.context
project.context
shopping.preferences
communication.preferences
The user could approve, reject, or later revoke these permissions.
A coding agent could receive your programming preferences without receiving your personal conversations. A travel application could receive your travel preferences without accessing your professional information.
The key architectural principle is separating where memory is stored from which AI is consuming it.
This becomes more interesting when the memory layer is independent of the AI model itself.
Today, companies such as OpenAI, Google, Anthropic, and others have their own AI ecosystems. Each can develop sophisticated memory capabilities, but users may ultimately use several AI systems for different purposes.
You might use one model for research, another for programming, another for productivity, and specialized agents for other tasks.
Instead of teaching each system your preferences independently, they could all consume the same user-controlled memory layer.
The AI models remain competitors.
Your memory does not have to be locked into any one of them.
The memory layer could potentially be managed by an AI provider, a dedicated memory provider, your own infrastructure, a personal cloud account, or an enterprise system.
The biggest benefit is context continuity.
AI agents are already highly capable, but they often lack knowledge about the person using them. As a result, users repeatedly provide the same context:
"Use Java."
"I prefer concise answers."
"This is the architecture of my system."
"I work with Kubernetes."
"Do not suggest solutions that require changing our infrastructure."
A shared memory layer could eliminate much of this repetition.
More importantly, it could change the way we interact with AI. Instead of every conversation starting with a blank or partially informed assistant, agents could begin with relevant context already available.
The AI would move from being a powerful general-purpose tool to something closer to a persistent personal intelligence layer.
There is, however, an important distinction between identity and AI memory.
Identity information tells an application who you are.
Memory can tell an application how you think, what you do, what you prefer, and potentially what you care about.
That makes shared AI memory significantly more sensitive than traditional OAuth data.
A robust system would therefore need strong controls around:
Explicit user consent
Fine-grained permission scopes
Encryption
Data minimization
Memory expiration
Revocation
Audit logs
Memory provenance
Ability to inspect and delete individual memories
Separation between facts and AI-generated assumptions
There is also a technical challenge: not every AI-generated memory should automatically become a trusted fact about the user.
A model could incorrectly infer a preference from a single conversation. A future memory protocol may therefore need to store metadata alongside each memory, such as its source, confidence, creation date, and whether the user has verified it.
Memory management could become an infrastructure layer in its own right.
OAuth did not eliminate individual applications. It gave them a standardized way to interact with identity and permissions.
A similar approach could work for AI memory.
The goal would not necessarily be to create one enormous database containing everyone's memories. It would be to create a standard protocol through which users can control and selectively share contextual knowledge with AI systems.
This matters because the future of AI may not consist of one assistant doing everything.
We may instead have hundreds of specialized agents. One writes code. Another researches. Another manages finances. Another plans travel. Another interacts with enterprise systems.
If every agent requires us to start from scratch, the AI experience will remain fragmented.
If these agents can securely access the context we choose to share, they can become significantly more useful without requiring us to repeatedly teach them who we are.
OAuth made identity portable.
The next major opportunity may be making AI memory portable.
And if that happens, one of the most important pieces of AI infrastructure may not be another model.
It may be the layer that allows every model to understand the same person, with that person's permission.