I have been seeing more and more companies publish how they are building internal knowledge systems for AI. The stories did not look like the document chatbots that defined the first wave of retrieval-augmented generation. They included search indexes, curated context, source-system access, domain ownership, authorization, evaluation, and delivery through several applications at once.
I did some searching looking for company engineering posts, project releases, specifications, and X publications within the last three months to see whether those examples added up to a broader pattern.
The examples I reviewed suggest that the enterprise AI knowledge base is becoming less like a single database and more like a shared knowledge plane. Three forms of knowledge appear together: material people and agents curate, large collections of content prepared for search, and live access to operational systems. Between those sources and the applications using them, companies are adding identity, policy, provenance, freshness, citation, and evaluation.
That is a synthesis of the examples, not a reference architecture. The implementations are early, their boundaries differ, and most reported results come from the companies that built them. The pattern recurs across the sample.
Beyond a single vector index
The clearest departure from the earlier RAG pattern is retrieval itself. Recent systems do not assume that semantic similarity is enough.
Cerebras described its internal knowledge base as a collection of source-specific pipelines behind a common retrieval layer. Slack threads are re-fetched and distilled into normalized records. Code embeddings are maintained incrementally with CocoIndex. PostgreSQL and pgvector hold content, embeddings, and metadata. Queries combine exact-term, semantic, rarity, freshness, and reranking signals. Cerebras reported more than 15,000 daily questions three months after launch, although that adoption figure is a first-party result, not independently verified.
OpenSearch’s Atlas experiment shows a related pattern in engineering work. Atlas turns code, wikis, runbooks, and resolved tickets into service references, an engineering book, and operating procedures. It stores full text with nested chunk vectors and combines BM25 lexical search with dense retrieval. That mix matters when a query contains both a paraphrased problem and an exact identifier. Resolved tickets can become new procedures, but only after a deduplication and promotion loop.
Mistral’s Search Toolkit makes the same split explicit in an open-source public preview: BM25, dense, and hybrid retrieval for indexed content, plus MCP connections when an agent needs current data from a CRM, code repository, or productivity system. This is a vendor release, not independent proof of a universal design. It is useful evidence that indexed search and live retrieval are being treated as different paths.
Across these examples, indexed retrieval is one subsystem rather than the full knowledge system.
Three forms of knowledge are appearing together
A recurring pattern was the coexistence of curated knowledge, indexed content, and live access.
Curated or derived knowledge holds meaning that benefits from review: definitions, decisions, people, runbooks, known relationships, and stable explanations. Salesforce’s Derived Knowledge Base keeps ingested source files immutable while an agent maintains cross-linked Concept and People notes in Markdown. Useful synthesis persists in a form humans can inspect, while the source material remains intact.
Google’s early Open Knowledge Format v0.1 formalizes a similar idea as Markdown files with YAML frontmatter and ordinary links. The format is intentionally small and portable. OKF v0.2 adds optional fields for who generated and verified a concept, its source material, lifecycle status, and a date after which it is stale. Google presents OKF as an open format rather than a service. It is also young. A June announcement from Atomic Strata reported early OKF support in an LLM-wiki compiler, which is an ecosystem signal, not adoption evidence.
Indexed content serves a different need. It prepares large collections of documents, code, conversations, and tickets for fast search. Cerebras, OpenSearch, and Mistral all combine lexical and semantic techniques rather than reducing this layer to embeddings alone. Metadata, source type, recency, and optional graph relationships become ranking or filtering inputs.
Live access covers information that is volatile, transactional, or governed most accurately in its source system. Mistral’s distinction is unusually direct: an agent searches a large collection of indexed content, then uses MCP integrations when it needs the latest state from an operational system. The MCP Enterprise-Managed Authorization extension adds a related enterprise control, allowing an identity provider to provision server access by group and role. MCP is a connection boundary in this pattern. It is not the knowledge store.
The shared layer sits between sources and many surfaces
The word plane is useful because these systems are being built for more than one assistant.
Spotify exposes the same context through Slack, a web interface, and an MCP server for IDEs and AI tools. Its data assistant uses 177 owned context clusters, each combining datasets, vetted question-and-SQL pairs, and business documentation. Spotify reported more than 2,100 users across more than 13,000 conversations. Those figures are first-party. More revealing than the usage count is the operating model: named domain teams own the clusters, and health scores track schema change, example validity, coverage, and reproducibility.
Stripe’s Knowledge AI Platform, described by Emily Sands in a July 30 first-party X Article, extends the shared-layer idea beyond retrieval. The article describes surface-neutral APIs, an AgentStudio control plane for domain owners, and secure execution environments. Stripe reports connections to more than 1,000 internal skills and tools, 83 percent weekly active usage, and 25,000 hours per year shifted from administrative work. Those are Stripe’s measurements, not independently reproduced results. The architecture is still informative because governance, reusable expertise, sandboxed execution, and multiple user surfaces are treated as parts of one platform.
The shared layer in these stories is not synonymous with a graph, vector database, or model gateway. It is the online path that resolves who is asking, which sources are available, how retrieval is routed, how results are ranked, and what evidence travels with the answer. Different systems implement different portions of that path. The common move is to stop rebuilding it separately for every bot, agent, and internal application.
Controls are moving into the retrieval path
Identity, authorization, provenance, freshness, citation, and evaluation used to appear as qualifications around RAG designs. In the newer examples, they are closer to the center.
Spotify’s domain ownership and health scores make curation state visible. OKF v0.2 carries generation, verification, source, status, and staleness signals alongside the knowledge itself. MCP’s enterprise authorization work places the corporate identity provider in the access path. OpenSearch attaches status, age, and provenance filters to retrieval and keeps its ticket-to-procedure flow inside a verification loop.
These controls are not equivalent, and none proves the whole system is secure or current. Their recurrence does suggest that relevance alone is no longer an adequate definition of retrieval quality. A result can be semantically close and still be unauthorized, stale, weakly sourced, or unsuitable for the task.
The same shift appears in evaluation. Mistral separates retriever metrics from answer generation so teams can compare search configurations against their own relevance judgments. Spotify uses cluster health and curator decisions. OpenSearch validates different agent outputs with different loops. The evaluation surface is becoming wider than “did the expected chunk appear near the top?”
Human correction is becoming platform input
The most concrete evidence for a curation loop comes from Spotify. The company generated candidate question-and-SQL pairs from historical query activity, then asked domain curators which examples belonged in the context layer. They accepted 12.5 percent. The rejected material included debugging work, one-off analysis, wrong tables, and queries that were technically valid but taught the wrong pattern.
That number is a useful warning against treating accumulated activity as curated knowledge. Usage creates candidates. It does not label truth.
Spotify returns conversation data, generated SQL, answers, and feedback to cluster owners. OpenSearch turns resolved tickets into candidate procedures and deduplicates them before addition. Salesforce separates immutable sources from derived notes that can be refined. Directionally, these implementations appear to be moving from retrieve, answer, and forget toward ingest, derive, review, reuse, and correct.
The loop is controlled because correction can introduce errors as easily as it removes them. The evidence I reviewed does not show a fully autonomous knowledge base reliably promoting its own conclusions without owners, source links, or verification state.
Openness is showing up at the seams
The open-source material in the report does not add up to a shopping list, and I do not read it that way. The pattern is attention to replaceable components and portable boundaries.
OKF uses files that humans and different tools can read. Mistral describes swappable indexer, retriever, and evaluator modules. OpenSearch’s Atlas keeps its vector-store interface modular even while using OpenSearch as the primary store. MCP standardizes a route to live tools and data while leaving the source systems authoritative.
Licensing is part of the portability story. FalkorDB’s server uses the Server Side Public License, so it is source-available rather than OSI-approved open source. The example is a useful reminder that open formats, open protocols, open-source software, and source-available software describe different kinds of portability.
Open formats and protocols do not remove managed platforms from the picture. Stripe’s platform is internal and company-specific. Mistral’s open-source framework is also a vendor project. MCP servers still depend on source-specific authorization and operations. Portability in these examples appears to come from explicit seams, not from avoiding every managed service.
What the evidence appears to show
The working thesis held up with one qualification: the emerging object is a shared, policy-aware path across several kinds of knowledge.
Curated knowledge gives stable meaning a reviewable form. Indexed content makes large collections of material searchable. Live connections preserve the current state and native permissions of operational systems. A common online layer routes among them and serves several applications, while corrections and usage create inputs for further curation.
The evidence is still early. Most examples are first-party build stories, internal experiments, vendor releases, or young specifications. Company-reported adoption and productivity figures have not been independently reproduced. It is not settled how much knowledge belongs in derived files, how permission changes propagate across indexes, when graph retrieval earns its operating cost, or which trust signals will travel across tools in practice.
What will be worth watching is whether these patterns survive beyond their originating teams: whether OKF gains independent producers and consumers, whether MCP authorization holds across heterogeneous enterprise systems, whether correction loops improve quality without becoming new poisoning paths, and whether companies publish comparable evidence for freshness, access control, retrieval quality, and operating cost.
For now, the strongest conclusion is narrower than a universal architecture. Recent company build stories are converging on a knowledge layer that combines curation, retrieval, and live access, then places policy and evidence in the path between enterprise sources and the many AI systems that use them.
Method and source note
I kept the review deliberately narrow: material published or updated between May 1 and August 1, 2026. I focused on company engineering posts, official specifications, project releases, and maintained repositories. I also checked X for first-party implementation notes, then followed those claims back to primary sources when possible. I treated posts as statements or leads, not independent proof, and ignored engagement metrics. This is a recent snapshot of the examples I found, not a complete market survey.