The Product Strategy and Product-led Blog

AI knowledge management is the most overlooked operational layer in enterprise AI adoption today. Every AI tool your team uses keeps its memory to itself: your Claude project, your colleague’s Claude project, your ChatGPT session, your Claude Code instance. None of them share context. What one person builds with their AI stays in their account, in their session, invisible to everyone else working on the same problem. The result is that teams using AI daily are not accumulating institutional knowledge. They are re-establishing context from scratch, session after session, person after person.

The problem has two causes. The tooling to support shared AI context does not yet exist in mature form. And most organizations have not made a deliberate structural decision about AI knowledge management even with the tools they have. Both are true, and solving one without the other is not enough.

Why this matters more than most leaders think

Sergei and Vadim Revzin documented the organizational pattern well in an April 2026 Forbes piece: a company buys licences for one or more LLMs, runs a few lunch-and-learn sessions, and ends up with a handful of super users pushing the limits and a majority of employees asking “how is this actually useful for me?” Board pressure drives spend on licences. The adoption infrastructure never arrives.

The result shows up in the numbers. MIT’s GenAI Divide report, published in July 2025 by the NANDA initiative at MIT Media Lab, found that 95% of enterprise AI pilots delivered no measurable P&L impact, despite $30–40 billion in global enterprise spending on generative AI. The research was based on 150 interviews with business leaders, 350 employee surveys, and analysis of 300 public AI deployments. The core failure the report identified was not model quality, not regulation: it was what the authors called a “learning gap” — systems that do not retain feedback, adapt to context, or improve over time.

The Revzin piece identifies three structural barriers to real adoption: technical setup gaps, role-specific use-case education, and governance clarity around what data can go into which tool. All three are real. But there is a fourth barrier neither report names directly, and it may be the most persistent one: AI knowledge management does not happen by default. The work does not travel.

What this looks like in practice

At Akamas, like most organizations actively pushing AI adoption, the expectation was clear: everyone should use AI to move faster. And most people did. The problem showed up at the seams.

A colleague would work through a problem with their AI, arrive at a position, and share the output. Another colleague would then validate or challenge that position by running it through their own AI session. But their session had no memory of the original reasoning. It would surface the same concerns the first person had already worked through. The same objections, the same iterations, the same time spent: because the context never traveled with the output. What looked like a peer review was often just cycling through the same concerns twice. This is what poor AI knowledge management looks like in practice — not a tooling failure, a structural one.

That is one version of the problem. Another is the gap between tools. Working across Claude Chat, Claude Code, and other tools depending on the task, sharing context between them is manual. A context file that is current in one tool may be stale in another. When a colleague joins a project, they start from zero regardless of how much has already been established. Shared repositories and shared documents help. They are not the same as shared AI memory.

A third version: AI sessions that answer from memory rather than from the current state of files. A deployment happens. A document is updated. The AI session does not know unless you tell it explicitly. By the time you realize the output was based on an older version, you are already three iterations in.

The mechanism — renting intelligence by the hour

Here is the right frame for this problem. If your team’s AI knowledge resets with every session and every account, you are renting intelligence by the hour. Every prompt that re-establishes context is a tax. It compounds nothing. The team that treats AI knowledge management as an operational capability — where what one person establishes with their AI is accessible to the next session and the next person — accumulates an advantage. Their AI gets more useful over time. Teams that do not solve this stay flat.

The closest most teams have today: a shared Notion page, an Obsidian vault, a GitHub repo of context files, a custom system prompt. These are workarounds. They require manual discipline every session and break when someone forgets to update before closing. They do not propagate automatically when something changes.

The gap is well-documented at scale. Nutanix’s 2026 Enterprise Cloud Index, based on surveys of 1,600 IT and engineering executives, found that 82% of organizations say silos between business units and IT make it difficult to execute technology initiatives. The same report found that 79% of organizations encounter AI being deployed by employees outside of IT oversight. Shadow AI at the team level — each person building their own AI knowledge in isolation — is the individual-level version of the same problem.

What is emerging to address it

Kong CEO Augusto Marietti wrote on LinkedIn this month: “Prediction: in two years every software company will become a Palantir Technologies: 20% product and 80% FDEs.”

A new category of tooling is also forming around persistent AI memory. Supermemory, Mem0, and MemOS are building memory layers that can persist context across sessions and, in some configurations, across users and accounts. Anthropic’s Model Context Protocol (MCP), introduced in 2024 and now governed as an open standard under the Linux Foundation, is becoming the infrastructure layer for connecting AI systems to external data sources and memory stores. This matters beyond memory: as I wrote in Does Product-Led Growth Still Matter in 2026?, AI integrations are now the signals that decide whether a product gets surfaced in an AI-driven shortlist at all. Forrester predicts 30% of enterprise app vendors will launch their own MCP servers in 2026.

None of these are plug-and-play for most teams today without engineering work. But the direction is clear: the organizations that start building AI knowledge management infrastructure now — even in manual, disciplined form — will be compounding knowledge while others reset every morning.

The governance question nobody is asking yet

Assuming your team does build shared AI context, a harder question immediately follows: what gets shared with whom, and at what boundary?

A project context file shared across one team is straightforward. But consider a project that spans two departments. Does everyone in both departments get access to the same shared AI memory? Probably not: there are decisions, assumptions, and sensitivities that are relevant to one team and potentially disruptive or premature for the other. Now extend that to a customer-facing project where part of the context involves internal pricing rationale, or a cross-functional initiative where legal constraints apply to some contributors but not others.

This is not a new problem. Companies have navigated knowledge sharing boundaries for decades through document classification policies, access controls, and organizational culture. What is new is that AI amplifies the consequences of getting it wrong. Bad shared context does not just lead to a misinformed colleague. It leads to an AI session that generates confidently wrong outputs at scale, across every session that reads that context.

The cultural dimension is real and consequential. Organizations will need to make a deliberate choice about what kind of knowledge-sharing company they want to be when it comes to AI context. A “share by default to unlock innovation” culture maximizes the compounding effect but increases the risk of context leaking across boundaries where it should not. A “share on a per-need basis” culture minimizes that risk but slows down the compounding and creates more friction for teams to maintain their own siloed context. Neither answer is universally correct. The right answer depends on the organization’s risk profile, regulatory environment, and the nature of the work.

The tools to support these decisions do not exist yet in any mature form. Today, AI knowledge management is largely unstructured: a file anyone on the project can read, with no granular controls over what gets surfaced to which session or which user. The governance infrastructure that would allow organizations to define knowledge boundaries for AI, enforce access policies, and audit what context was used in which session is still being built. It is likely to become one of the more active areas of enterprise AI tooling over the next two to three years, for the same reasons that data governance and identity management became critical infrastructure in the cloud era.

What operators can do today

The tooling will catch up. The discipline needs to start now.

Three practical steps for any VP Product or operator running a team that uses AI:

Designate one shared context file and treat it as a living document. Not a wiki. Not a Notion space with forty subpages. One file that captures the current state of a project: key decisions and the reasoning behind them, conventions your team has agreed on, open questions, and what has changed recently. Keep it as tight as the project allows. The goal is something a colleague can read in two minutes and hand directly to their AI session as useful context. Every AI session that depends on current state reads this file before responding.

Update it at the end of sessions, not the start of the next one. By the time the next session opens, the context is already needed. Updates made before closing are the only ones that reliably help the next person. Updates deferred to the next session open are updates that never happen.

Treat memory and file access as separate systems, because they are. Your AI tool’s memory persists across your own sessions but does not automatically reflect changes a colleague made to a shared file. When current state matters, fetch the file explicitly. One instruction at the start of the session: “Read [filename] before responding.” This is friction, but it is knowable friction you chose to incur. Stale memory is invisible friction you discover three iterations later.

These are not permanent solutions. They are the honest state of the art for AI knowledge management in teams using AI in mid-2026, before shared memory infrastructure matures.

The leadership question

According to Writer’s 2025 Generative AI Adoption in the Enterprise survey, 41% of C-suite executives say adopting generative AI is tearing their company apart and creating internal power struggles. Nearly half acknowledge that employees have been left to figure out AI on their own. The internal chaos has an external counterpart: as I wrote in You’re No Longer Selling to Humans First, AI now also runs inside enterprise buying committees on the other side of the deal — making the absence of structured AI knowledge management both an internal and a market-facing problem.

Sergei and Vadim Revzin put the organizational dynamic plainly in their Forbes analysis: the mandate comes from the top, the tools get bought, the lunch-and-learns happen, and the result is a small group of super users and a majority of employees more confused than before. Their prescription — capability-informed adoption with role-based direction, governance clarity, and domain expertise per team — is necessary. But it is not sufficient on its own.

Even a well-structured AI adoption programme leaves teams with siloed, session-bound knowledge if it does not also address the context layer. You can train every team member on prompt engineering and still find them re-establishing the same context every morning because nothing they built yesterday is visible to anyone else today.

The gap between AI adoption and AI value has two causes, not one, and collapsing them into a single diagnosis leads to the wrong prescription.

The first is organizational. Companies need to make deliberate choices about how AI knowledge is structured, maintained, and shared: who owns the context file, what gets included, where the boundaries sit between teams and projects, and what kind of knowledge-sharing culture they want to build. These are judgment calls, not technical ones. The tooling cannot make them for you.

The second is a tooling gap, and it is real. The infrastructure to support organizational AI knowledge management, with granular access controls, automatic context propagation, and governance audit trails, does not exist in mature form today. Calling this purely an organizational design problem would let the tools off the hook. The tools are catching up, and the gap between what organizations need and what is available will remain significant for some time.

What is likely: the next two to three years will see significant tooling development in this space. Persistent AI memory layers, shared context infrastructure, and knowledge governance for AI will follow a similar trajectory to data governance and identity management in the cloud era: first the problem becomes undeniable, then a wave of tooling emerges, then a smaller number of credible solutions consolidates. We are at the “problem becoming undeniable” stage.

The organizations that start making deliberate structural choices now, even with imperfect tools, will be better positioned to adopt the mature tooling when it arrives. The ones that wait for the tools before thinking about the structure will spend the consolidation phase trying to retrofit governance onto a mess of ad hoc AI context that accumulated without any design behind it.

Shared AI context is an operational capability. It needs an owner, a structure, and an update cadence. It also needs a cultural decision about what kind of knowledge-sharing organization you want to be. The teams that treat AI knowledge management as deliberately as they treat any other knowledge system will compound. The rest will reset every morning, and eventually discover they have a governance problem on top of a productivity problem.

FAQs