Most enterprise AI agents are well-equipped to answer "what" — and nearly useless when the question gets harder. They can retrieve a document. They struggle to know why a decision was made, how your team actually works, or who to loop in when something breaks.
Arvind Jain, CEO of Glean, recently put a framework to this problem on LinkedIn that sparked significant debate: enterprise AI context breaks into four distinct types — know-what, know-how, know-why, and know-who. Most deployments address one. Agents that operate across all four behave like informed colleagues rather than expensive search bars.
This post unpacks each type, explains why the gaps matter in practice, and shows what it takes to close them.
What "enterprise AI context" actually means
Enterprise AI context is the structured, permissioned body of company-specific knowledge — facts, processes, decisions, and relationships — that an AI agent draws on when reasoning about a real business task. Without it, an agent is applying general intelligence to a specific situation it knows nothing about. With it, the agent can answer questions that would otherwise require interrupting a colleague.
The distinction matters because context engineering is what separates production-grade enterprise AI from a well-prompted demo. Getting the model right is table stakes. Getting the context right is the actual work.
The four types, defined
Know-what: factual retrieval
Know-what is the type most teams build first. It covers facts, records, and documents: what a contract says, what a customer paid, what version shipped last quarter. This is the domain of traditional RAG pipelines and enterprise search — index a corpus, retrieve relevant chunks, pass them to the model.
It is necessary but not sufficient. An agent that only has know-what context can tell you what the SLA says. It cannot tell you whether your team has ever actually enforced it.
Know-how: process and procedure
Know-how is institutional knowledge about how things get done — not the org chart, but the actual workflow. How does your team handle an escalation? What's the real approval path for a contract over $50k? Which Slack channel carries the decision, even if Confluence says otherwise?
This context lives mostly in unstructured form: Slack threads, Notion pages, recorded calls, email chains. It is rarely written down as procedure. Agents without know-how context will follow the documented process, which is often not the real process, and produce outputs that experienced employees immediately recognize as wrong.
Know-why: decisions and their rationale
Know-why is the hardest type to capture and the most valuable when you have it. It answers why a decision was made: why the pricing model changed, why a feature was cut, why a particular vendor was chosen over a cheaper one.
Without know-why context, an agent optimizing a process has no way to distinguish a constraint that exists for a good reason from one that exists by accident. It will confidently recommend changes that violate commitments your team made months ago and never wrote down anywhere formal.
As one analysis of multi-agent deployments notes, when agents operate without shared organizational reality — including the rationale behind past decisions — they produce contradictory outputs that erode trust in the entire system.
Know-who: relationships and expertise
Know-who is context about people: who owns what, who has relevant expertise, who the actual decision-maker is for a given domain. This is not the org chart. It is the lived network of accountability and knowledge that determines whether an output gets acted on.
An agent with know-who context can route a question to the right person, flag that a proposed change affects a team that needs to sign off, or recognize that a customer relationship is owned by someone specific and should not be handled generically.
Why most agents only get one type
The gap is structural, not intentional. Most enterprise AI deployments start with the easiest data to index: documents in a shared drive, tickets in a help desk, records in a CRM. That data is predominantly know-what. It is also the data that fits cleanest into a vector database or a RAG pipeline.
Know-how, know-why, and know-who live in messier places: Slack conversations, email threads, meeting notes, the comments inside a Notion page, the context field someone filled in on a HubSpot deal three months ago. These sources require broader ingestion, smarter permissioning, and the ability to surface the right fragment from a much larger and noisier corpus.
According to a 2026 LinkedIn survey cited by multiple sources, 80% of organizations believe agentic deployments have already delivered economic returns — but scale depends on integration and data quality, not just model capability. The bottleneck is context breadth, not model intelligence.
Salesforce's 2026 agent trends report makes a similar point: the agents that are evolving fastest are those connected to richer, more current company data — not those running on better base models.
What each context type requires to work
| Context type | Where it lives | What it requires |
|---|---|---|
| Know-what | Docs, CRM, tickets, databases | Indexed retrieval, source citation |
| Know-how | Slack, Notion, email, calls | Broad ingestion, recency, thread awareness |
| Know-why | Decision logs, meeting notes, Slack | Temporal context, linked reasoning |
| Know-who | Org data, CRM ownership, Slack patterns | Identity mapping, permission-aware routing |
The table makes the engineering challenge visible. Know-what needs good retrieval. The other three need the agent to understand relationships between pieces of information, not just find the closest chunk.
Permissioning compounds the difficulty. Know-who context, in particular, is sensitive. An agent that can freely query who owns what relationship, or who made a decision that turned out badly, is a liability if that information crosses the wrong boundary. Every context type needs to be surfaced at the right scope — private, team, or company-wide — not just retrieved.
How a company brain closes all four gaps
The framing Gyld uses — a business context layer for AI — is a direct answer to this four-part problem. The premise is that enterprise AI context cannot be solved by indexing one data source or building one integration. It requires ingesting the apps a company already uses (Slack, Gmail, Notion, Google Drive, HubSpot, Salesforce, QuickBooks, and others), treating the combined output as a permissioned knowledge base, and exposing that knowledge to AI agents through MCP servers.
MCP (Model Context Protocol) matters here because it is the mechanism that lets agents — Claude, ChatGPT, Cursor, Codex — query company context at inference time, without fine-tuning and without a hand-built RAG pipeline to maintain. The agent asks a question; the MCP server returns the relevant context, with the source attached.
That architecture handles know-what through standard document retrieval. It handles know-how by ingesting Slack threads and Notion pages where process actually lives. It handles know-why by preserving the temporal context of decisions — the comment, the thread, the email that explains the reasoning. And it handles know-who by mapping ownership and expertise from CRM records, Slack patterns, and shared drives, with permissions that respect who should see what.
This is also why comparing Gyld to other approaches matters: a vector database handles know-what reasonably well. A company brain is designed to handle all four.
Making it actionable: four questions to audit your agent's context
Before adding another agent or expanding a deployment, run your current setup against these questions:
- Know-what: Can the agent retrieve the current version of a key document and cite where it came from?
- Know-how: Can the agent describe how your team actually handles a common exception — not what the wiki says, but what the Slack thread from last month shows?
- Know-why: Can the agent explain why a pricing rule or product decision exists, not just what it is?
- Know-who: Can the agent identify who owns a customer relationship or a technical domain, and route accordingly?
If the answer to questions 2, 3, or 4 is no, the agent is operating on know-what alone. That is fine for narrow retrieval tasks. It is a real limitation for anything requiring judgment.
The fix is not a better model. It is broader, better-permissioned context ingested from the places where know-how, know-why, and know-who actually accumulate — which is almost always the communication and collaboration tools your team uses every day.
Key takeaways
- Enterprise AI context has four distinct types: know-what, know-how, know-why, and know-who. Most agents only get the first.
- The missing three types live in Slack, email, Notion, and meeting notes — not in the document repositories most teams index first.
- Closing all four gaps requires broad ingestion, permissioned access, and source citation — the architecture of a company brain, not a search index.
If your agents are hitting the limits of know-what context, start building your company brain with Gyld — connect the apps where your team's real knowledge lives and give every agent the full picture.
Frequently asked questions
What is enterprise AI context for agents?
Enterprise AI context for agents is the company-specific knowledge — facts, processes, decisions, and relationships — that an agent retrieves at inference time to reason accurately about a real business task. Without it, agents apply general intelligence to situations they know nothing about. With it, they can answer questions that would otherwise require a human colleague.
Why do most enterprise AI agents only use one type of context?
Because the easiest data to index is factual: documents, records, and tickets. Know-how, know-why, and know-who live in messier sources — Slack, email, meeting notes — that require broader ingestion pipelines, smarter permissioning, and the ability to surface meaning from unstructured conversation, not just documents.
What is the difference between know-how and know-what context?
Know-what is factual retrieval: what a document says, what a record shows. Know-how is procedural: how your team actually handles a situation, which may differ significantly from what any document describes. Agents with only know-what context follow the documented process; agents with know-how context follow the real one.
How does permissioning affect enterprise AI context?
Different context types carry different sensitivity. Know-who context — who owns a relationship, who made a contested decision — is particularly sensitive. A company brain needs to surface context at the right scope (private, team, or company-wide) rather than treating all indexed knowledge as equally accessible to all agents and users.
What is an MCP server and how does it relate to enterprise context?
MCP (Model Context Protocol) is the mechanism that lets AI agents query an external knowledge source at inference time. A company brain exposed as an MCP server means any compatible agent — Claude, ChatGPT, Cursor — can request company context without fine-tuning or a hand-built integration. The server returns the relevant context with the source cited, covering all four context types if the underlying knowledge base is broad enough.