7
AI Stack & Context Friction
ChatGPT Knows One Version of You. Claude Knows Another. Now What?
Using several models is easy. Preserving the right version of the human and the work across them is the harder problem.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
Every AI environment learns a different version of the work
Your business already has an identity architecture, even if you never named it
Portability is not copying every memory into every model
The better question is what deserves to travel
The same model can behave differently for every operator on the team
Your models do not need equal jobs
Sometimes fragmentation is the correct design
Cross-model continuity begins by deciding what deserves to travel
INTRODUCTION
If you use more than one AI model seriously, you eventually meet a strange version of yourself. ChatGPT knows the project you have been building for six months. Claude knows the document you gave it yesterday. Gemini knows the files sitting closest to your Google Workspace. One environment remembers why you rejected a certain direction. Another sees the same idea and recommends it enthusiastically as though nobody has ever thought of it before. The models are not necessarily contradicting one another. They are working from different representations of you, your company and the work.
That distinction matters because multi-model use is usually framed as a comparison exercise. Which model is best for writing? Which one is better for research? Which one has the longest context window? Which one gives the smartest answer today? Those questions can be useful, but they stop being the most important questions once several AI environments become part of real work. At that point, the deeper question is what each environment needs to know about you, the business and the work in order to do its job well, and what should remain deliberately different. That is not really a model-comparison problem. It is an identity and continuity problem.
Every AI environment learns a different version of the work
An AI model does not meet your company in the abstract. It meets the version of the company that has been made available inside that particular environment. That version is shaped by far more than a single prompt. It is shaped by the files you uploaded, the examples you corrected, the conversations that came before, the instructions someone wrote months ago, the assumptions nobody remembered to update, the decisions that never made it into a shared source, and the way the humans using the system learned to ask for things. Two people can use the same model and slowly teach it two different companies. The same person can use two models and slowly teach them two different versions of themselves.
This is why the question, “Which AI is better?” can become surprisingly unhelpful. The model is one variable. The environment around the model is another. A very capable model with thin, stale or badly framed context can feel less useful than a supposedly weaker model that has been given the right history, source material, constraints and operating cues. I have been testing some version of this problem since I first started working intensively with AI in 2023. One of my earliest questions was essentially: can I make this sterile code carry enough of me that I do not have to begin as a stranger every time? That question eventually became much larger than tone of voice. It became a question of what an AI system needs to know in order to recognize the work at all.
Your business already has an identity architecture, even if you never named it
Most businesses think about identity as branding: logo, voice, values, positioning, visual rules, maybe a tone-of-voice guide. AI makes that definition feel very small. For an AI environment to work coherently with a business, it may need to understand which sources are authoritative, how the company makes decisions, what quality looks like, which exceptions matter, which terms have precise internal meanings, what the team has already tried, what it refuses to do, what customers have been promised and which parts of the work still require human judgment. That is identity too, because it is part of what makes this company this company rather than a generic company-shaped prompt.
In my deeper Human-AI Systems work, I use the term Identity Portal for a structured representation of a person or organization that both humans and machines can traverse. The underlying idea is simple enough to use without adopting any of our house language: the business needs a maintained way to define itself that is richer than a brand deck and more portable than the memory of one employee. That can become sophisticated. It can also begin as a very good internal packet. The point is not the format. The point is that the company should know what intelligence belongs to the company before it asks several AI systems to represent it. Otherwise each environment starts assembling a version from whatever it happens to receive, and the team spends the next year wondering why ChatGPT sounds like one company, Claude sounds like another and the custom GPT somebody built in February seems to have developed its own private interpretation of the brand.
This matters outside the company too. A business is already being reconstructed by clients, service providers, search engines, social platforms and AI systems that encounter fragments of it. The more machine-mediated the internet becomes, the more important it is to know what you want those systems to recognize, what you want them to retrieve, and which source should win when several versions of you are available. Generative search optimization is one visible edge of that problem, but the operating problem is bigger. Before you optimize how machines find you, you need enough structural clarity that the version they find is actually yours.
Portability is not copying every memory into every model
The obvious response to fragmentation is to synchronize everything. If ChatGPT knows something useful, copy it into Claude. If Claude learned a preference, add it to Gemini. Upload the same archive everywhere. Keep the prompts identical. Make every environment carry the same memory. That sounds like continuity, but it can just as easily create three stale copies of the same context. Some information should travel. Some should remain local. Some should be available only through retrieval when it becomes relevant. Some should never be copied into another environment because of privacy, security, licensing, role boundaries or simple usefulness. A model being capable of holding information does not mean it should hold it.
There is another practical reason not to flatten every environment into one giant synthetic brain: different environments can be valuable precisely because they are different. For several months I deliberately used Claude as an outside operator on my own system. I gave it enough structural knowledge to understand the machinery, but I intentionally removed much of the emotional and recursive context that existed inside my primary working environment. Then I pushed the experiment further and created a journalist-style observer whose job was to encounter the system from the outside. That distance was useful. It could audit things I had become too accustomed to seeing from inside. It could notice where a stranger would get lost. It could question assumptions without inheriting every internal association that made those assumptions feel obvious to me. If I had synchronized everything blindly, I would have destroyed the reason that environment existed.
Continuity does not require sameness. Sometimes a clean room should remain clean. What matters is knowing why it is clean, what it is allowed to know, and how it reconnects to the larger system when necessary. That is the difference between a deliberately bounded environment and an environment that simply drifted away from the rest of the company without anyone noticing.
The better question is what deserves to travel
When I think about cross-model continuity, I do not begin with a master prompt. I begin with custody. What is the stable identity of the business? Which source represents it now? Which decisions must survive a change of model? Which instructions are global, and which are specific to one workflow? Which examples teach something important enough to become shared? Which history is useful only in the room where it happened? Who is responsible for updating the portable layer when the business changes? Those decisions create a much more durable system than trying to make every model remember everything.
I think of the shared layer as the passport, not the entire house. A passport establishes enough identity to move across borders. It does not contain every photograph, argument, grocery receipt, private room and half-finished thought inside the life it represents. Your AI environments need something similar: enough identity to recognize the person or business they are working with, enough context to understand the current task, enough source authority to know what should win when information conflicts, and enough custody to know what should not travel. Then the environment can accumulate the local knowledge that makes it good at its particular job. That is much closer to continuity than cloning the same context everywhere.
The same model can behave differently for every operator on the team
This becomes more complicated inside organizations because the model is not the only thing shaping the environment. The humans are shaping it too. I once saw a company using a shared business AI account and custom GPTs that had been built carefully by one person. The builder had put a lot of thought into the system and even gave the team guidance on how to prompt it. The problem was not that the custom GPT was poorly built. The problem was the assumption that giving several operators the same tool would automatically give them the same experience.
It did not. Each person brought different questions, habits, assumptions, levels of background knowledge and ways of interpreting the instructions. The AI responded to those differences. The shared tool existed, but the working environments still diverged. This is easy to miss because software encourages us to think in terms of access. Everyone has the same login. Everyone has the same GPT. Everyone has the same template. Therefore everyone has the same system. They do not. A Human-AI System includes the human, which means team continuity requires more than distributing a prompt library. The team has to understand what the environment is for, what context it depends on, what decisions should become shared and when an output reflects a local interaction rather than company-wide truth.
The moment AI becomes multi-user, identity stops being only a branding concern and becomes an operating concern. Who is allowed to teach the system something about the company? Who can correct it? Whose correction becomes shared context? Who can decide that an old representation is no longer valid? If three people train three slightly different versions of the same custom environment, which one is the business? Those are not philosophical questions once the outputs start reaching customers.
Your models do not need equal jobs
There is another habit I would retire: forcing every AI environment to justify itself by being generally excellent. That is not how we use most tools. An office does not ask whether the conference room is better than the copy room. They exist for different reasons. AI environments can work the same way. You may want one environment where the company does deep, continuity-heavy work with a large amount of historical context. Another may be deliberately sparse and used for independent critique. Another may sit close to a specific document system. Another may be the safest place for a certain team workflow. Another may simply fit the cognitive rhythm of one operator better.
Preferences matter too. I have never naturally preferred Claude as my primary thinking environment, even though I respect the model and have used it heavily for specific work. I do not need to turn that preference into a vendor thesis. I know what I go there for. That is a healthier question for a business as well. Instead of asking which model wins, ask what role this environment plays, what it should know to perform that role, and what it should not inherit because that would weaken the role. Once those answers become clear, multi-model work becomes much less chaotic. The models stop competing for the title of “the AI” and start becoming rooms with different functions inside a larger operating environment.
This is also where portability becomes more realistic. You are not trying to drag an entire company brain from room to room. You are carrying the parts that establish identity, authority and continuity, then allowing each room to remain useful for what it does best. In one room you may need deep historical context. In another, you may need a cleaner perspective. In another, you may need only the current operating packet and a narrow task. The architecture becomes intentional instead of accidental.
Sometimes fragmentation is the correct design
A good continuity argument needs a boundary condition because not every separation is a problem. There are legitimate reasons for two AI environments to know different things. Security boundaries may require it. Client confidentiality may require it. A legal or compliance workflow may need strict isolation. An independent audit is less independent if the auditor inherits the same assumptions as the system being audited. A research environment may need experimental freedom that should never leak into production. A team may intentionally keep strategic context away from a task-specific agent that does not need it.
The mistake is not difference. The mistake is ungoverned difference. If two environments carry different representations because the business chose those boundaries, documented them and knows how to re-establish the shared core when necessary, that is architecture. If they carry different representations because nobody noticed the drift, that is fragmentation. The difference is custody. Someone has to know which version is authoritative for which purpose, what travels, what stays, and when an environment has become stale enough that it is no longer representing the business it is supposed to serve.
That is the work beneath the workflow diagram. It is also why this problem rarely disappears just because a company buys a platform that promises to unify everything. A unified interface can make access simpler. It cannot decide what should count as shared identity, who has authority to update it, what needs to remain local, or which human judgments should never be flattened into a common memory layer.
Cross-model continuity begins by deciding what deserves to travel
If someone came into a Human-AI Orientation saying, “We use ChatGPT, Claude and Gemini and I cannot get them to work consistently,” I would not start by writing a universal prompt. I would first map the environments: what each one knows now, what role each has quietly acquired, where the business is repeatedly rebuilding itself, what information has become trapped in one model, which corrections exist only in somebody’s conversation history, which sources are authoritative, which representations are stale, which differences are useful, which differences are dangerous, and who currently carries the continuity when the work moves.
Then I would identify the portable layer. For one company, that might be a concise operating packet containing positioning, source hierarchy, decision rules, terminology, quality standards, current priorities and a few carefully chosen examples. For another, it may need structured memory and retrieval. For a larger team, it may require clearer ownership and governance before any technical synchronization is attempted. The answer may eventually be a shared knowledge layer, a custom environment, a retrieval system, a better team practice, fewer models or a more deliberate reason for using several. But the diagnosis comes first, because the goal is not to make every AI know the same version of you. The goal is to make sure the right version of you can arrive in the right room without the business having to rebuild itself at the door.
HUMAN-AI ORIENTATION
What should travel between your AI environments?
Bring the models, prompts, memory, and work that currently live in separate places. We identify the identity layer that needs continuity, what should remain local, and who should control what crosses between environments.
€950 · 2.5 hours · nothing is sold in the room
FIELD CONNECTION • hUMAN-ai sYSTEMS
Go deeper only when the thought needs another room.
Authentic AI Marketing opens the commercial door. Human-AI Systems holds the deeper architecture, artifacts, and system thinking behind the work.
DEEPER SYSTEMS. RICHER CONTEXT.
Watch / Listen
Read / LLM Ingestion