Key Takeaways
- Your AI context layer is the governed context agents use; an AI context platform is the software that builds and delivers it.
- A context layer built from documentation alone misses what your experts know from chat threads, tickets, and experience.
- Captured expert answers should reach agents only after an editor approves them, with their source, the people involved, and the date attached.
- You can start with permissions-aware retrieval over documents you already govern; a knowledge graph sharpens results where you have one.
Every company has questions that its documentation answers badly and one colleague answers well. Why a contract clause was negotiated the way it was, for instance, or who to call before changing a setting that other systems depend on. You might find these answers by walking over to the colleague who always knows. That works for people. An AI agent has nobody to walk over to.
At Squirro, we wanted to see how many of those answers an agent would miss, so we ran tacit knowledge capture on our own internal conversations before talking to anyone else about it. It surfaced many answers that no documentation covered. Those answers belong in the context layer that agents draw on, and most organizations building one are not collecting them yet.
What Is an AI Context Layer, and How Is It Different From an AI Context Platform?
An AI context layer is the governed, machine-readable context that AI agents draw on while they work: what business terms mean, what is true right now, and where each piece of information came from. An AI context platform is the software that data and AI teams use to build, govern, and deliver that layer to agents.
In October 2026, Gartner named AI context platforms one of its Top Strategic Technology Trends for 2027, in research titled "AI Context Platforms" (G00855977, 16 October 2026). Squirro is among the vendors Gartner recognized in that research. Our reading of the report is that Gartner uses the two terms for different things. Keeping them apart helps when planning, because one is software you select and the other is a body of knowledge your organization builds up over years.
Gartner describes the context layer through three components:
- Semantics: explicit definitions, taxonomies, hierarchies, and relationships, expressed in ontologies and knowledge graphs, so that agents interpret intent, policies, and rules correctly.
- Operational state: right-time situational data, including the organizational knowledge an agent retrieves through retrieval augmented generation (RAG).
- Provenance: a record of data lineage, agent actions, decision paths, and user feedback.
The platform is the tooling around that layer. Gartner defines it as software that enables data and AI engineering teams to "construct, govern and deliver semantically organized knowledge to AI agents and other AI applications and services."
| AI context layer | AI context platform | |
|---|---|---|
| What it is | The governed context agents use at run time | The software that builds, governs, and delivers that context |
| What it holds or does | Semantics, operational state, and provenance, with permissions applied to every request | Ingestion, modeling, approval workflows, access control, and delivery to agents |
| Who works with it | Agents, assistants, and search applications | Data and AI engineers, taxonomists, knowledge managers, and editors |
| Where gaps show up | In wrong or incomplete agent answers | In what the platform can collect and govern |
In its report, Gartner attached a strategic planning assumption to the trend:
By 2027, organizations that prioritize semantics in AI-ready data will increase agentic AI accuracy by up to 80% and reduce costs by up to 60%.
While that's a projection rather than a measured result, it points in the direction that things are going.
The same report noted that 42% of enterprises plan to deploy AI agents by the end of 2026, while only 22% currently capture significant value from generative AI.
It also described running a context platform as an ongoing practice, with business units continuously curating and validating what goes in. The people doing that curating hold a lot of context that has never been written down.
Where Does the Context Agents Need Actually Live?
Some of it is written down as documentation. Some of it is written, but scattered across chat threads and tickets. And some of it has never been written down at all, because it lives in the heads of the people who do the work. Most context layers today are built from the first kind.
| Where it lives | Examples | How it reaches the context layer |
|---|---|---|
| Written documentation | Policies, runbooks, release notes, contracts | Ingested, indexed, and retrieved under each user's permissions |
| Written, but not yet knowledge | Chat threads, tickets, comments | Distilled into answers by topic, each linked to its source |
| In people's heads | Judgment, rules of thumb, "ask Toni about that" | Reached only by asking the person who knows |
Written documentation is where nearly every context layer project begins. Gartner's roadmap starts there too: "Centralize unstructured policies first, then systematically progress to rule-based automation and semantic consolidation." Documents already have owners and review cycles, which makes them the easiest knowledge to govern. An agent that answers from approved policy is also far safer than one that improvises.
Chat threads and tickets are recorded, but they are hard to use. A support thread might contain the precise fix for a recurring problem, buried somewhere between forty messages of back-and-forth and a discussion about where to have lunch. Search can find the thread. An agent working from the raw thread still has to guess which message was the answer, and whether it is still true.
The third place needs little introduction. Most teams can name the person for each topic, and that person's calendar tends to fill up the week before a major release.
Gartner's report does not overlook people. It recommends combining AI and human expertise to build and validate ontologies, and it asks business units to "define, validate and update the policies guiding digital workers." That expertise shapes the structure of the context layer: the vocabulary, the definitions, and the rules agents follow.
An experienced engineer or relationship manager carries a different kind of knowledge around. It's the workaround that never made it into the runbook, or the reason a client's setup looks the way it does. That knowledge rarely surfaces in a modeling workshop, and few experts will sit down to write it up unprompted. Getting it into the context layer means finding it in the conversations where it already appears, and asking about the rest.
What Happened When We Ran Tacit Knowledge Capture on Ourselves?
We pointed tacit knowledge capture at Squirro's own internal conversations before taking it to anyone else. It distilled chat threads, tickets, and documents into sourced answers, then turned the gaps it found into short questions for the people who knew. On our own conversations, it surfaced many answers no documentation covered.
The process ran in five steps:
- Distill. Chat threads, tickets, and documents were distilled into answers by topic. Each answer links back to the thread or document it came from.
- Find the gaps. Once the knowledge was organized by topic, thin coverage became visible: questions that had been asked and never resolved, and topics that depend on very few people.
- Ask the expert. The person who knew received a short, specific question and confirmed, corrected, or filled in the answer.
- Govern. Answers went to a review inbox, where people could approve, correct, or flag them, and contradictions were surfaced for someone to resolve. Where a taxonomy is connected, approved answers can be filed in it.
- Feed the context layer. Approved answers become context that agents can use, with people in control of the actions agents take.
Narrow questions are what make step 3 work. If you ask an engineer to "document the deployment process," the request will probably sit on their to-do list until a quiet week that never comes. If you ask instead whether the fix from that thread back in March (clearing the cache before re-running the job) is still the right order, you'll often have a reply the same morning. It takes the expert a few minutes rather than a day of writing, and the answer comes already tied to a topic and a source.
The method has a hard limit. It cannot extract what nobody says. If a decision was made in a hallway and never mentioned in a thread or a ticket, the distillation has nothing to work with. What it can do is notice the gap, find the person most likely to know, and ask. The approach also has a cost: a few minutes of expert time per question, and an editor's time to review answers before anyone relies on them. A deployment can also approve answers automatically above a confidence threshold, and that is how we run our own internal hub. For knowledge that agents will act on, we think a person should review it first.
In exchange, the expert's answer stays available after the expert moves on to other work or retires. Each answer carries its source, the people involved, and the date, so the next person, or the next agent, can check it before acting.
Why Does Approval Count for More When an Agent Is the Reader?
A person who reads an unsourced answer can weigh it against what they know, ask a colleague, or wait until Monday. An agent acts on what is in its context. So the approval step that decides what enters the context layer is a control on agent behavior as well as on content quality.
In an agent's context, an unapproved expert answer can be riskier than no answer at all. With no answer, an agent designed to escalate can hand the question to a person. With a plausible but outdated answer, it carries on.
Human Oversight at Two Gates
In our view, captured knowledge should pass two gates before it shapes what an agent does.
Before knowledge enters the context layer: an editor approves each expert answer, and the answer keeps its source, the people involved, and the date.
Before an agent acts on it: consequential actions wait for a person to approve them, and the agent's queries, sources, and actions are recorded in an audit log.
This fits what Gartner calls provenance, which tracks "data lineage, agent actions, decision paths, and user feedback." For captured knowledge, we think provenance should also record who approved an answer, and when. If an agent output turns out to be wrong, that record would show whether the problem lay in the source thread, in the expert's answer, or in what the agent did with it.
What Should a Context Platform Do to Close the Gap?
Capturing tacit knowledge for agents is still an early practice, and our own test was a first step. Based on what we learned, and on the building blocks Squirro already provides, we see four things a context platform should do.
Keep permissions-aware retrieval as the baseline. In Squirro, access controls from source systems are inherited and applied at query time, so people and agents see only what they are cleared to see. Gartner places a strict need-to-know principle at the center of context delivery, and we cover how this works in practice in AI Data Protection: Unpacking Fine-Grained Access Control. Any captured knowledge should sit inside the same controls.
Treat approved answers as organizational knowledge. Gartner's diagram of the context layer lists organizational knowledge retrieved through RAG under operational state. Approved expert answers belong there, next to documents, so that an agent asking about a workaround retrieves and cites the approved answer the same way it would a policy.
Keep a trail from answer to action. Squirro already records passage-level citations and an audit log of queries, sources, and agent actions, with approval gates configured for each workflow. For captured knowledge, the same trail should extend back to the expert who answered and the editor who approved.
Connect to the vocabulary teams already govern, where one exists. Squirro Graphite manages taxonomies and ontologies with built-in support for W3C standards such as SKOS and OWL, plus SPARQL endpoints, and business experts maintain the vocabulary without writing code. Where a taxonomy is connected, approved answers can be filed against the concepts your teams already use, which sharpens classification and retrieval. A knowledge graph can go further and let agents draw inferences across connected facts. None of this is required to begin. Grounded, permissions-aware retrieval over documents and approved answers delivers value on its own, and the semantic layer can follow where ambiguous terms cause the most wrong answers [LINK: GenAI semantic layer article, if live].
Where Should You Start?
Start with one domain where knowledge is concentrated in a few people, and work from conversations you already have before asking anyone for new input.
- List the forwarded questions. Ask one team for the five questions they always forward to the same colleague. The list is a first map of your gaps, and making it requires no software at all.
- Pick a domain where experts are scarce or close to retirement. That is where the cost of losing an answer is highest. We looked at the retirement side of this problem in Corporate Amnesia: Capturing Tacit Knowledge with Enterprise AI.
- Start with existing threads and tickets. Distill what is already recorded before asking experts for anything, so their time goes to the real gaps.
- Name an editor. Someone needs to approve answers before they reach people or agents, and the role works best with a named owner. Gartner makes a similar point about business ownership of context.
- Decide which agent uses approved answers first, and which of its actions keep a person in the loop.
The documentation you already have is a sound foundation for a context layer, and Gartner's roadmap starts in the same place. The next source is usually a colleague who has been answering the same question in chat for years.
See a context layer working on your own content. Book a demo and we will show grounded, permissioned, and cited answers on a domain you choose. The AI Context Platforms brief [LINK: context platform two-pager] covers the architecture in two pages, and the tacit knowledge brief [LINK: tacit knowledge two-pager] covers capture.
Read the Gartner research. Get a complimentary copy of Gartner's "Top Strategic Technology Trends for 2027: AI Context Platforms", courtesy of Squirro.
