Why Glean, Notion AI, and Copilot miss the real work

Ask a CAIO what their AI stack looks like today and you will hear a familiar list. Glean for enterprise search. Notion AI on top of the wiki. Microsoft Copilot inside the Office suite. Maybe a Google Gemini pilot somewhere in the back.

Then ask the same CAIO what the business impact has been. The answer, if it is honest, is quieter. People search a little faster. Meeting notes come out cleaner. Draft emails start with a paragraph already written.

None of that is the real work.

MIT NANDA found that 95% of enterprise AI investments show no measurable business impact. McKinsey's State of AI keeps reporting the same pattern year over year: pilots stall, production is rare, ROI is thin. The tooling is not the problem. The layer everyone bought is doing exactly what it was built to do. The problem is that the layer everyone bought was never designed to do the real work.

This post is about what Glean, Notion AI, and Copilot actually are, what they cannot reach, and what has to sit on top of them for enterprise AI to move a real number.

What Glean, Notion AI, and Copilot actually do

Strip the branding away and these three products do the same thing at their core. They index a company's written surface, documents, wikis, tickets, emails, chats, and put a language model between the employee and that index. Ask a question, get an answer grounded in company content. Draft a document, get a version pre-populated with company context.

Glean is enterprise search with a chat interface on top. Notion AI is a wiki with a chat interface on top. Copilot is Office and Windows with a chat interface on top. Gemini for Workspace is the same shape inside Google.

That is a real and useful capability. Panopto found that 42% of workplace expertise is known only to the person doing the job. McKinsey has put the time knowledge workers spend searching for information at around 19% of the week. If you can compress "find me the last version of that policy" from ten minutes to ten seconds, you save time.

But saving search time is not running the operation. Answering a question about a policy is not deciding a case. Drafting a memo is not underwriting a risk. The operation runs on decisions, exceptions, and actions inside the systems of record, not on Q&A over the wiki.

That distinction is where every large deployment eventually hits a wall.

The two things they cannot reach

There are two layers that sit above indexed content. Both are missing from the search-and-summarize category, and both are where operational value actually lives.

1. The knowledge that was never written

Search and knowledge assistants read what was already written. That is their entire substrate.

The most valuable knowledge in an operation was never written down. The senior underwriter who knows why one submission looks like a bad risk and a nearly identical one does not. The planner who knows which supplier to trust when the system shows both as green. The claims adjuster who knows which field is stale and which report to open first. None of that lives in a document. It lives in a person.

Roughly 80% of operational processes are undocumented, according to Tallyfy. In our own two years of shipping agentic systems inside real enterprises, this was the wall we hit in every project. The company could show us documents. The company could not show us how the work actually gets done.

A search tool cannot retrieve what nobody typed. We covered the technical version of this failure mode in RAG Is Not Enough, Why Retrieved Knowledge Fails on Real Work, and dug deeper into why expertise mining is a different tool than RAG in a companion piece. The short version: better embeddings do not fix an empty substrate.

Closing that gap is not a retrieval problem. It is an extraction problem. That is what expertise mining does. It sits with an expert in a normal conversation and pulls out the decisions, the reasons, the exceptions, the trusted sources, the escalation moments, and turns all of it into a machine-readable expert profile that an AI can use directly. Not a nicer wiki page. A different substrate.

2. The action inside real systems

The second missing layer is action.

Ask Glean, Notion AI, or Copilot to do the work, not describe it, not summarize it, but actually run a renewal, close a ticket, book a shipment, price a quote, post a journal entry, and the answer is either "I can't do that from here" or "here is a draft you can paste in."

That is not a bug. It is the category. Search and summarization tools were built to serve a human sitting at a keyboard. They were never wired into the underwriting workbench, the ERP, the WMS, the TMS, the CRM as an operator. They do not hold the operating knowledge for how a case should be judged, they do not have a governed permission model for which fields they may read and which they may write, and they do not run a team of specialists that ask a human before anything that matters.

That is a different category. We call it governed agent operations, real specialists, each with a narrow job, running on top of captured expertise, with human-in-the-loop control on any action that writes into a system of record.

Every working enterprise agent stands on two legs: a knowledge leg and an action leg. Search-and-summarize tools are half of the knowledge leg. They are none of the action leg. Gartner expects a growing share of enterprise applications to include agentic capabilities, precisely because search alone stops short of the work.

Complementary at the substrate, but not the whole stack

None of this is an argument to rip Glean, Notion AI, or Copilot out. They are useful at the substrate level. They make the written layer of the company faster to move through. Keep them.

The mistake is treating them as the finish line.

If you are the CAIO, the fair question is not "Glean or Verti?" It is "what sits on top of Glean?" If you are the COO, it is not "Copilot or Verti?" It is "what actually runs the renewal, the claim, the plan, the quote, end to end, inside our systems, with governance?" If you are the CTO, it is not "Notion AI or Verti?" It is "which layer holds the operating knowledge that our agents will read from?"

We laid out the deeper version of this argument in What Is Operating Knowledge, and Why Your Documents Do Not Have It. The one-line version: chat over your documents answers questions about what was already written. An expertise-driven agent captures what was never written, plugs it into the systems, and runs the work.

The two coexist. One does not replace the other. But the ROI number does not move on the search layer alone.

What "moving the real number" looks like

The gap is easier to see in production numbers than in feature grids.

At a large multi-brand insurance group we work with, the insurance renewal workflow used to take six minutes per case. After we mined the underwriting expertise, wired the platform into the systems of record, and ran a governed agent on top with human approval on anything that matters, the same workflow now takes one minute. That is an 83% cut in handling time. The risk team went from eight people to three on that process. Around 833 labor hours a month are freed per 10,000 renewals.

At a supplements manufacturer, screening 100 job candidates used to take one recruiter eight hours. It now takes 30 minutes. That team is expanding the same pattern into field sales and production planning next.

None of that came from a better search box or a smarter wiki. It came from mining a real expert, encoding the operating knowledge, connecting to the systems where the work lives, and running a governed agent on top with a human always in control. The knowledge layer plus the action layer, with the search layer sitting quietly underneath.

That is the layer people are missing.

What to do instead

If you already run Glean, Notion AI, or Copilot, three practical moves.

Stop measuring them on the wrong thing. They are not going to move the operations number. They are going to move the search-time number and the drafting-time number. Measure them there and move on.

Pick one expert-dependent process. Not the whole company. One process that runs on a small number of senior people, where a departure would hurt, where the real work does not match the SOP, and where the ROI is legible. Insurance renewal. Underwriting triage. Claims first-pass. Production planning under exceptions. Vendor risk review. Anywhere the expert everyone calls is the single point of failure.

Mine that expertise, wire the systems, run a governed agent on top. Keep your search layer. Put an expertise-and-action layer above it. That is the stack that actually runs the work.

Glean, Notion AI, and Copilot answer the question. The layer above them does the job. If your AI investment has not moved a real operational number yet, the missing layer is not another search tool. Mine the expertise. Then operate differently.