6
AI Stack & Context Friction
The Problem Isn't Too Many AI Tools. It's What Gets Lost Between Them.
The tools may all be useful. The friction begins when context, decisions, and memory stop traveling with the work.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
The tools may be working. The system can still feel scattered
Tool abundance and context abundance are different things
Somebody is already carrying the integration
Before you clean up the stack, decide what must stay true
Your AI stack needs intelligence hygiene
Sometimes you really do have too many tools
The business has to know what intelligence belongs to the business
INTRODUCTION
A few years into AI adoption, a strange thing starts happening inside otherwise competent businesses: nobody can quite say how many AI tools the company is actually using. There is the official platform. Then there are the tools individual teams adopted because they solved a specific problem faster. Someone is using ChatGPT for drafting, someone else prefers Claude for long documents, another team has Gemini sitting next to Google Workspace, there is an automation layer nobody wants to touch because the person who built it left, and somewhere a very enthusiastic colleague has created an agent that does something useful enough that everyone has agreed not to ask too many questions.
None of those tools has to be bad for the environment to feel increasingly difficult to manage. In fact, that is often the problem. They are useful. People have learned them. Work is getting done. The frustration comes from somewhere less visible: the organization is spending more time remembering what belongs where, rebuilding context, translating between systems, checking which version is authoritative, and finding the person who knows why a particular decision was made.
The instinct is reasonable: clean up the stack. Cancel some subscriptions. Pick a preferred model. Standardize the tools. Connect the systems that remain. Sometimes that is exactly the right move. But there is a question I would want answered before anybody starts deleting accounts or announcing the new approved platform.
What, exactly, does the business need to keep continuous while all of this work moves?
That is a different problem from tool count.
The tools may be working. The system can still feel scattered
A business can have several excellent AI tools and still have a poor AI operating environment. Each tool may perform beautifully inside its own boundary. The writing tool writes. The research tool researches. The automation runs. The agent completes its task. The database stores what it was given. Locally, capability is increasing. Globally, the business can become harder to understand.
This is the part that gets lost when tool consolidation is treated like ordinary software housekeeping. AI tools do not only contain functions. Over time they accumulate working context: instructions, examples, corrections, source material, decisions, preferences, exceptions, project history, conversational residue and little pieces of human judgment that may never have been documented anywhere else. Two tools that appear redundant from a procurement spreadsheet may be carrying very different parts of the company’s working intelligence.
That does not mean every tool deserves to stay. It means deleting a tool does not automatically delete the problem the tool was helping the humans compensate for. You can move everything into one platform and still have the same fragmentation, now inside a larger container.
I think of this as the difference between local capability and system coherence. A stack can become more capable every month while the people inside it become less certain about where truth lives, which instructions still apply, what the AI is expected to remember, and who is responsible for keeping any of it current. At that point, “we have too many tools” is a perfectly reasonable way to describe the experience. It is just not yet a diagnosis.
Tool abundance and context abundance are different things
Context is one of those words that becomes useless if it is allowed to mean everything. In a business, context is not simply the collection of documents you can upload to a model. It includes the reason a decision was made, which source should win when two sources disagree, the exception everyone on the team knows about, what good work looks like here, what the customer has already been told, which assumption changed last Tuesday, what the founder refuses to compromise on, and which rule should no longer be trusted even though it is still sitting in the handbook.
The tools may have access to information without having access to enough of that context to behave coherently. And copying the same pile of information into every environment does not necessarily fix it. Duplicated context is not the same thing as shared context. If five tools each hold their own version of the company’s instructions, you may have increased availability while quietly creating five future opportunities for drift.
This is where AI changes the ordinary software-management problem. Traditional software often asks whether the data is available and whether the process works. AI systems also depend heavily on the interpretive layer around that information. What does this mean? Which part matters now? What should be ignored? What has changed? What should persist into the next interaction? Who gets to correct the model when its understanding no longer represents the business?
A mature AI environment therefore needs more than access. It needs continuity. Some things should travel across tools. Some things should remain local. Some context should be durable. Some should expire quickly. Some decisions should be available to every relevant system. Some information should absolutely not be synchronized everywhere simply because the integration can be built.
Tool abundance and context abundance are different things. One is a question of how many places can do work. The other is a question of whether the intelligence required to do that work survives when the work changes places.
Somebody is already carrying the integration
I know this problem from the inside because I have built my own Human-AI System far enough to encounter the ugly version of it. My work can move through different AI environments, archives, publishing systems, research surfaces and operating rooms, each of which is useful for a different reason. For a long time, I was also the person carrying the continuity between them.
I knew that a decision made in one room changed the meaning of a document sitting somewhere else. I remembered that the thing we were discussing under one name had already appeared months earlier in a different form. I knew which source was current, which version was only a witness, which rule had been superseded and which strange little sentence from an earlier conversation mattered more than the polished summary everyone could see. When one environment needed something another environment knew, I moved it. When a later piece of work depended on an older one, I reconstructed the bridge.
The tools were not failing. I was functioning as part of the architecture.
That distinction matters inside companies because the hidden integration layer is often a person. It may be the operations lead who knows where the real process differs from the documented one. It may be the founder who remembers why the brand rule exists. It may be the project manager who keeps translating the same decision into three different systems. It may be the person everyone messages when the AI produces something technically correct but obviously wrong for the business.
If one person is constantly reminding, translating, reconnecting, correcting or carrying decisions between tools, that person is not standing outside the AI stack. They are one of its integration layers, whether anyone designed it that way or not.
This is not automatically a problem. Humans are supposed to be inside human-AI systems. Judgment, interpretation, accountability and contextual awareness do not become defects merely because software cannot absorb them. The problem is when the system depends on a human function nobody has recognized. Then the business cannot tell the difference between valuable human judgment and avoidable human reconstruction. It cannot decide what should remain human, what should become shared memory, what should be automated, and what should simply be made visible to everybody else.
That is why I pay attention to recurring human rescue. Not because the goal is to remove the human from the loop, but because repeated rescue tells you something about what the system does not yet know how to carry.
Before you clean up the stack, decide what must stay true
The simplest consolidation exercise is to compare tools by features, cost, security, adoption and overlap. Those are all legitimate criteria. But before I make the software decision, I want a continuity map.
What must remain true if the work moves from one environment to another?
For one business, that may be customer history and the promises already made. For another, it may be the reasoning behind a technical decision. A creative company may need tone, taste, source lineage and a reliable record of what has already been rejected. A regulated environment may care most about provenance, permissions, auditability and who is allowed to authorize a change. A leadership team may need strategic decisions to persist even as the documents around them evolve.
Once those invariants are visible, the stack becomes much easier to evaluate. A tool earns its place because it serves a distinct role well, because it can participate in the continuity the business actually needs, or because the value it creates justifies the boundary around it. Another tool may be technically impressive and still be unnecessary. A third may look redundant until you realize it is carrying a kind of work the preferred platform handles badly.
This is also where “one platform for everything” can become seductive. Fewer interfaces feel cleaner. Centralization can reduce training load and simplify security. But if the company has not decided what its shared context actually is, consolidation can merely move the confusion. The team still does not know which sources are authoritative. Decisions still disappear into conversations. Instructions still become stale. People still recreate the same background every time they start a new task. The software estate is smaller, but the continuity problem survived the migration.
Consolidation should therefore begin with what must survive the handoff, who maintains it, and which tools genuinely need to participate. The winning app comes later.
Your AI stack needs intelligence hygiene
We already understand the idea of data hygiene. We clean records, remove duplicates, correct errors, manage access and try not to let the database become a haunted attic full of three versions of the same customer.
AI systems need another layer of maintenance that I think of as intelligence hygiene.
Intelligence hygiene is the recurring work of keeping the relationship between information, context, judgment, decisions and action usable as the system changes. It is less glamorous than launching an agent and much more important than people expect. A tool gets updated. A team changes its process. A new source becomes authoritative. A customer policy changes. Somebody discovers a better way to use the model. A prompt that worked six months ago quietly becomes unnecessary because the system around it has matured. If nobody reconciles those changes, the stack keeps accumulating old assumptions.
This does not require a giant AI governance council with seventeen people and a quarterly ceremonial PDF. For many teams, twenty focused minutes once a week would expose a surprising amount. What changed? Which tools are people actually using? What correction keeps being made manually? Which instruction is now outdated? Did a decision happen that the systems need to know about? Has one person become the only person who understands a particular agent? Is the same context being recreated in several places? What is authoritative now?
The purpose is not to document every breath the organization takes. The purpose is to notice when the system’s working intelligence has changed and make a conscious decision about what should happen to that change.
Someone also has to steward this. Not necessarily one grand “AI owner,” and not necessarily the technical team. Stewardship can be distributed. But the questions need names attached to them. Who can update shared context? Who can retire an old instruction? Who decides a correction deserves to become memory rather than remain a one-off fix? Who notices that the machine is following a rule the business stopped believing three months ago?
The more people and tools that participate in the environment, the less safe it is to assume everybody is still carrying the same invisible map.
Sometimes you really do have too many tools
There is a danger in any diagnostic argument that it becomes so delighted with the deeper mechanism that it refuses to admit the obvious answer. Sometimes the stack is simply bloated.
Two tools do substantially the same job. A team is paying for subscriptions nobody uses. People are switching interfaces for no meaningful reason. Shadow AI has created security or privacy exposure. Nobody owns the automation that is still running in the background. The cognitive cost of remembering where to work is larger than the benefit of the specialist tool. Training has become fragmented because every team has chosen its own favorite environment. In those situations, consolidation is not an intellectual puzzle. Clean it up.
The difference is that you now know what to preserve while you do it.
- You can retire a tool without accidentally retiring the only durable copy of a decision history.
- You can move a workflow without losing the corrections that made it reliable.
- You can choose a preferred model without pretending every model needs to know exactly the same things.
- You can distinguish a useful specialist from an expensive duplicate.
- You can standardize where standardization reduces friction and preserve difference where the difference is doing real work.
The goal is not maximal complexity in the name of nuance. It is not to defend every tool because it contains a precious little pocket of context. If a piece of intelligence matters to the business, it should not remain trapped inside a tool nobody wants merely because nobody extracted it before canceling the account.
That is what good consolidation should reveal: not only what the business can remove, but what it was accidentally depending on.
The business has to know what intelligence belongs to the business
This is the basement of the problem for me.
Before a company can build a coherent AI stack, it has to know what intelligence belongs to the company itself. Not the model. Not the platform. Not the consultant. Not the employee who happens to remember everything. The business.
What would you still need to know if every AI subscription disappeared tomorrow? What decisions would have to survive? What makes your work recognizably yours? What does your team know about customers, risk, quality, judgment, language, exceptions and priorities that a generic model does not? Where is that knowledge currently living? Which parts are explicit enough to travel and which parts only appear when the right human is in the room?
Those questions sit underneath tool consolidation because tools should serve that intelligence, not define it. The company does not need to recreate itself in the image of whichever AI platform currently has the most attractive feature list. It needs an operating environment that allows its own intelligence to remain coherent while technology changes around it.
That is the work I would do in a Human-AI Orientation when someone arrives saying, “We have too many AI tools.” I am happy to talk about the stack. We may end up canceling half of it. We may decide two environments should be connected, one should remain deliberately separate, the team needs a shared memory layer, or an undocumented human role needs to be made visible before anything else changes.
But I would start one floor lower.
I would map what needs to remain true as work moves between people and tools, where that continuity currently depends on a human carrying it, what deserves to become shared context, who should steward it, and only then which technology should stay.
The goal is not fewer tools for the sake of fewer tools.
The goal is a system that still knows what it is doing when the work moves.
HUMAN-AI ORIENTATION
Before you add another tool, map what has to travel.
Bring the stack you already use. We trace where context, memory, decisions, and ownership break between tools, then decide what should be shared, what should stay local, and whether anything actually needs to be consolidated.
€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