Every AI tool now reads the same company knowledge

First we had to name the problem precisely. This was not a team that wrote bad prompts. They had meeting notes and guide documents. But when the person in charge of a report changed, the documents pasted into the AI changed, the sentences explaining the background changed, and in the end the company knowledge the AI understood changed. The same model giving slightly different answers to the same question is simply how generative AI behaves. What we could touch was the step before that: the starting point, which differed from person to person.

We also knew this team was far from alone. Every time we built an internal agent, the starting point was context, and we had been building that up under the name RAG, trying one approach after another. The industry is looking at the same spot. Microsoft calls the layer where multiple agents share one knowledge base and return sourced answers a knowledge layer. Gartner calls it a context layer, Forrester a system of context. There are still more than ten names, but in 2026 they all point to one place: the knowledge layer between tools and data. The only part with a settled standard is how you connect to it, and that is MCP.

There was nothing to install. Connect the internal wikis and messengers, such as Notion, Slack, and Discord, and OTOntology reads the content and builds the wiki. Every entry links back to its original, and changes are re-synced at most every 5 minutes. Then you register the MCP address once. In Claude Code that is a single command; Codex and other tools use the same address. Authentication is per company, and the scope covers the public channels and wiki of the connected workspaces. After that one connection, any tool you ask from reads the same wiki and returns the original links along with its answer.

The first thing to change was the report that started it all. Before, the owner would paste this month's VoC meeting notes into Claude Code, paste the guide document again, and start by explaining the background. That prep differed by person, and so did the result. Now they simply ask for a report from the meeting notes. The agent reads the CI and BI guides, past reports, and the notes on why earlier conclusions were reached, all straight from the wiki. Whoever owns it starts from the same evidence, so the direction no longer swings widely. The wording still varies by person, but the evidence and the direction are one.

The CS-handling logic we had built with this team earlier came back to life here. The handling criteria by inquiry type and the response principles existed as documents, but the owner was explaining them to the AI every single time. Now they call the bot in Slack and ask for a draft reply to an inquiry. The bot writes the draft from the handling criteria document and attaches the original link. All the owner has to check is whether the draft follows the criteria, by clicking the link. Response tone drifting from person to person also eased once everyone read the same criteria document.

The change on the engineering side was quiet but big. Before touching a feature, you need to know why it was designed that way and what issues came up before, and that answer lived somewhere in meeting notes and Notion specs. Before, you asked whoever knew. Now you ask right inside Claude Code. The agent finds the decision records and the original spec in the wiki and lays them out with links, so developers read the whole background before they touch the code. Two things shrank at once: implementation direction diverging by person, and old issues repeated because nobody knew about them.

New hires end up using a senior colleague as a search box. Where is this procedure? Who do I ask about this? Several times a day. Now they ask the Slack bot first. The bot finds the procedure document in the wiki, answers, and attaches the original link, so the new hire gets the answer and learns where the original lives at the same time. The senior colleague is no longer the person who answers everything, only the person who gets the questions the bot could not find evidence for. And because the bot does not answer without evidence, wrong guidance no longer flows straight to the newest person on the team.

What the team liked most in this case was not speed but sources. Every answer carries the original link. If a search finds no evidence, the model is not called and the bot says it does not know. That changed review. Before, someone had to read AI-written text from start to finish and check whether it was true. Now they click the link and confirm the original, and they are done. Wherever they hand work to an AI, they no longer explain the background and the task. Hunting for documents and asking the next desk dropped just as much.

The team's last question was whether the same knowledge could go into agents that integrate with external systems. Because the wiki was already open over MCP, the answer was simple: register the same address. This is also where we learned the clearest lesson of the project. In a team that already uses AI tools well, the place to optimize is not the prompt but the knowledge layer beneath it. OTOntology is what we got by taking the attempts we had stacked up under the name RAG while building internal agents, and trimming them into something light and general that works with a connection instead of an install. This team was its first deployment.