Picking enterprise search software used to mean choosing which vendor indexed the most connectors. In 2026, with AI tools reading that index and answering questions directly, the choice matters more and carries more risk: a wrong answer synthesised confidently from the wrong document is worse than a slow search that returns nothing.
This guide is a practical checklist, not a vendor comparison. It covers what to check, what most buying guides skip, and where the market has actually moved.
Why the buying decision changed
For a decade, enterprise search meant a search box: type a query, get a ranked list of documents, open the one that looks right. The job was retrieval. A person still did the reading and the judging.
That changed once large language models could sit on top of the same index and write an answer instead of returning a list. Retrieval augmented generation, or RAG, is now treated as production infrastructure in enterprise settings rather than an experimental pattern, according to a peer-reviewed systematic review of the field. The retrieval step still matters just as much as it always did. What changed is what happens after it: a model now writes a sentence based on whatever the retrieval step handed over, and a person reads that sentence instead of the underlying documents.
That single shift is why entitlement and freshness became buying criteria, not nice-to-haves. If the retrieval step surfaces the wrong document, the model will still write a fluent, confident answer from it. Nothing about the interface signals that anything went wrong.
The market Glean built, and the gap it leaves
Glean is the name most buyers reach for first, and for good reason. It built federated search across dozens of connectors and layered a knowledge graph on top, so results are ranked by relevance to a person's role rather than pure keyword match. The market rewarded it: Glean's annual recurring revenue reportedly passed $300 million by May 2026, having doubled to $200 million only months before, on a $7.2 billion valuation.
That growth reflects a real product built for a real buyer: large enterprises with dedicated IT teams and a security review process that can absorb months of onboarding. It does not reflect the needs of a 20-person operations team or a 150-person agency, who have the same scattered-systems problem but neither the budget nor the review cycle Glean assumes.
What actually matters at 20 to 500 employees
A smaller company rarely needs 80 connectors. It needs an accurate, current, access-controlled answer from the handful of systems that actually run the business: the CRM, the ticketing tool, a shared drive, and Slack. Four things decide whether a tool delivers that.
- Where entitlement is checked. Ask directly whether an unentitled record is filtered before an answer is drafted, or redacted from an answer that has already been written. The first is a guarantee. The second depends on the model behaving, every time, with no exceptions.
- How staleness is handled. Some tools index once and never look back. A contract that gets renegotiated, a headcount number that changes, or a pricing tier that gets discontinued will sit in the index as fact long after it stops being true.
- Whether other software can call it. A growing share of real demand comes from a support bot, an internal automation, or another AI agent, not a human typing into a search box. If the only interface is a chat window, that rules out most of that demand.
- What self-hosting actually costs. A Docker image you have to patch yourself is a genuine ongoing commitment, not a one-time setup. Ask about the update cadence before assuming "self-hosted" means "set and forget."
"Granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust."
OWASP Top 10 for Large Language Model Applications, on excessive agency
The quote above is about autonomous action, not search, but the underlying point transfers directly: a system that has not had its access boundaries checked will behave exactly as confidently whether it is right or wrong.
How does permission-aware retrieval actually work?
Most access control in enterprise software works the way NIST's role-based access control model describes: a role grants a set of permissions, and a system checks the role before letting an action through. Search products have historically applied that check at the display layer: fetch results, then hide the ones the requester should not see.
Permission-aware retrieval moves that same check earlier, into the scoring function that ranks candidate documents before anything is written. An unentitled record scores zero and never reaches the answer, rather than being fetched and then hidden. The practical difference shows up the moment a model is generating a synthesised answer rather than displaying a list: a display-layer filter can hide a document from a results page, but it cannot un-write a sentence that already drew on that document's contents.
A worked example
Picture a 60-person consultancy. Their CRM lives in Postgres, contracts sit in a shared drive, and most decisions get made in Slack threads. A junior analyst asks an AI assistant for a client's renewal terms. Without entitlement enforced at retrieval, the assistant can just as easily surface payroll notes from the same client's onboarding thread, because nothing in the retrieval layer knew the analyst was not supposed to see them. With entitlement scored before synthesis, that payroll record scores zero for this asker and never reaches the ranked set the model draws from. The analyst gets the renewal terms and nothing else, not because a filter caught a mistake afterwards, but because the mistake was never possible in the first place.
Comparing what buyers actually get
| Dimension | Legacy enterprise search | Cloud AI search platform (Glean-class) | Self-hosted, entitlement-first tool |
|---|---|---|---|
| Primary user | Person typing a query | Person and AI assistant | AI agent and person |
| Entitlement point | Display layer, after fetch | Mostly at retrieval, mature | At retrieval, inside the scoring function |
| Freshness | Scheduled re-index | Scheduled re-index | Re-fetches from source on staleness (TTL) |
| Company size fit | Any size | 500+ employees, dedicated IT | 20-500 employees, no dedicated IT required |
| Data location | Vendor-hosted, typically | Vendor cloud with enterprise controls | Your own infrastructure |
Table 1: how three categories of enterprise search software differ on the checks that matter most, not on connector count.
Common pitfalls when choosing enterprise search software
- Judging by connector count alone. A tool with 90 connectors and weak entitlement is riskier than one with ten connectors that checks access properly on every one.
- Assuming a demo reflects reality. A sales demo runs against clean, curated data. Ask to pilot it against your own messiest folder instead.
- Treating "self-hosted" as a security guarantee. Self-hosting answers where data lives. It says nothing about whether entitlement is enforced correctly once it is there.
- Skipping the AI agent question entirely. If your roadmap includes agents calling tools directly, check for an MCP server or a documented API now, not once the need becomes urgent.
- Comparing list price only. Several vendors put fine-grained entitlement behind their highest paid tier, which quietly defeats the point for a smaller buyer.
What is the honest way to run a pilot?
Pick one real, unglamorous question your team actually asks: not "summarise our roadmap" but "what did we agree with this specific client last quarter, and who is allowed to see it." Give two people with different access levels the same question and compare answers. If the tool cannot tell them apart, or if it takes a support ticket to find out how, that tells you more than a week of vendor calls.
Run the same pilot against the freshness angle. Change a fact in the source system (a renewal date, a headcount figure) and ask again a day later. A tool worth paying for either reflects the change or tells you plainly that its answer might be stale. One that repeats the old fact with full confidence has failed the test that matters most.
Where this leaves you
If your company has the budget and the review cycle for a large enterprise platform, that category exists and earns its price for that buyer. If you are in the 20 to 500 person range, the checklist above matters more than any brand name: where entitlement is enforced, how staleness is handled, and whether your own software can call the tool directly.
Contextely was built specifically for that gap: retrieval-time entitlement enforced inside the scoring function, memory objects that carry a TTL and re-fetch over MCP when stale, and a self-hosted deployment with Docker and no feature gating. Read the security model directly, compare it honestly against Glean if that is the decision in front of you, or see how the underlying retrieval and permissions actually work in our deep dive on AI enterprise search. If you want the shortlist approach instead, our roundup of AI knowledge management software covers where several tools land on this same checklist. The pricing page has no hidden entitlement tier.