Enterprise Search Software: What It Does and What It Cannot Do

Enterprise Search Software: What It Does and What It Cannot Do

Enterprise search software indexes content across the separate systems a company uses and returns ranked results from all of them in one place. It solves the problem of not knowing where something lives. It does not solve the problem of not knowing the answer.

That distinction sounds pedantic until you watch someone use it. They type three words, get eleven documents, open four, close three. The fifth tab is the one they needed. Search worked perfectly and the person still spent six minutes reading.

Why enterprise search exists

Enterprise search was built for a specific failure: content scattered across systems that each had their own search box and no knowledge of each other. A contract lived in one repository, the amendment in an email thread, the negotiation history in a CRM note. Three searches, three sets of results that never met.
The first serious attempt was the corporate intranet: publish everything to one portal, search the portal.

Why intranet search failed

Intranet search assumed a publishing step. Someone had to decide a document mattered, move it, and tag it. That step competed with actual work and lost. The portal held what somebody was paid to file. Live material stayed in shared drives, inboxes and eventually chat. Search quality was fine; coverage was the problem.

Why federated search failed

Federated search tried the opposite. It copied nothing, broadcast the query to every system at query time, and merged the responses.

Two things broke. Latency: the slowest system set the speed of every search, and one timing-out connector degraded the whole result set. Ranking: each system returned its own scores, computed differently, on different scales. Merging them produced an ordering nobody could justify.

Modern enterprise search software is the synthesis of both failures. It copies content into one index, so ranking is consistent and fast. It pulls that content through connectors, so coverage tracks reality rather than tracking who filed what.

How enterprise search software works

Connectors

A connector authenticates to a source system, enumerates its content, pulls text and metadata, and detects changes afterwards. The last part is where connectors are won or lost.
Enumeration is straightforward once. Keeping up is not. A good connector receives change events; a poor one re-crawls on a schedule and runs infrequently.

Connectors also differ in what they read: attachments inside tickets, comments, text inside slide images, archived channels. Two products can claim the same system and index very different amounts of it.

The index

The index holds a processed copy of your content: documents split into passages, normalised, stored with metadata — owner, source, last-modified date, access control list.

Most systems keep two representations. A keyword index handles exact terms, product codes and names. A vector index holds embeddings, so a query about "notice period" matches a passage reading "termination requires 60 days' written notice". Hybrid retrieval queries both that is what ai enterprise search usually means, not anything generative.

The permission model

This part decides whether the system is deployable. Every indexed document carries the permissions of its source. The question is when they are checked.

Index-time enforcement resolves permissions during ingestion. The system expands the source ACL into a list of user identifiers and stores it alongside the document. At query time it filters on that stored list — one cheap comparison per candidate. It is fast.

Query-time enforcement checks the requesting user's current entitlements against the current ACL before a result is shown. That adds a resolution step to every query, sometimes against the source system itself. It is slower. It is also correct.

What drifts under index-time enforcement is access changes between syncs. Someone moves team on Monday and loses a folder. The index still holds Friday's expansion of that ACL. Until the next sync they can see titles, snippets and sometimes full passages they are no longer entitled to.

The gap widens with group membership. A removal is instant in the source; in an index-time system it lands when groups are re-expanded, often on a different schedule from document sync. This is the first thing to interrogate in an evaluation, and why permission-aware access control for enterprise AI is an architecture decision rather than a feature toggle.

Ranking

Ranking decides order. Keyword relevance and vector similarity set the base score. Signals then adjust it: recency, click behaviour on similar queries, the searcher's team and role, document authority, whether the source is a system of record or a chat channel.

The interface

Most enterprise search engines expose a web search page, a browser extension, a chat integration and an API. The API matters more than it looks: it lets retrieval feed an assistant, a workflow or an agent later, without rebuilding connectors and permissions.

What enterprise search does genuinely well

The category takes criticism it has not earned. Four things it does better than anything else:
Finding a known artefact. When you know the thing exists and only need to reach it, search is close to unbeatable. You remember a deck about Q3 pricing in APAC, from someone in finance, in spring. Three fragments is usually enough. No answer layer improves on this; you wanted the file, not a summary.

Discovery across silos. Search surfaces what you did not know to ask for. A query about a customer returns the contract, two tickets, a Slack thread and a post-mortem you had never seen. That post-mortem changes your afternoon. Synthesis would have compressed it out of existence.
Breadth of connectors. Mature vendors have spent years on unglamorous work: OAuth flows that survive token rotation, incremental sync against weak change APIs, rate-limit handling, tenancy quirks. Connector estates are the real moat here, and genuinely hard to replicate.

Auditability. A ranked list is honest about what it is. Ten results, each with a source, a date and an owner. You can see what the system considered. When a result is wrong, you can trace why.
Those properties are why enterprise search remains the right purchase for many organisations, and why newer categories build on top of it.

Both paths do the same retrieval. The difference is one hop: search hands the reader a ranked list and leaves the reconciling to them; an answer layer does the reconciling and cites what it used. That hop is the value and also the risk — it is the step that can be confidently wrong.

The three structural limits

These are not bugs awaiting a release. They follow from what a search system is: a ranked pointer to stored text.

It returns documents, not answers

Search ranks candidates by likelihood of relevance. It does not read them, compare them, or resolve their disagreements.

A new engineering manager asks how much notice a contractor needs. Search returns the master services agreement, a procurement PDF from 2023, a Confluence page written by ops, and a Slack thread where legal corrected someone. Four documents, three numbers, one correct answer in the thread.

Search behaved correctly at every step. It found all four, ranked them defensibly, and stopped. The reconciliation — noticing the conflict, deciding which source governs — falls to someone with no basis for deciding. That work is not in scope for the category.

It cannot tell you which result is current

Search knows metadata, not truth. It knows a document's last-modified timestamp, not whether the statement inside it still holds.

A pricing page edited last week to fix a typo carries a recent timestamp and 2024 discount tiers. The accurate tiers sit in a deck from four months ago that nobody has touched, because it was right when written. Ranked on recency, the wrong document wins.

No ranking signal fixes this. Freshness of the file and freshness of the claim are different properties, and only one is observable from outside. Which document governs a claim is an ownership fact, and it lives in your organisation, not your index.

It cannot act

Search ends at retrieval. If the task involves changing something, it has delivered the input and nothing more.

Someone finds the offboarding checklist and now has eleven steps across six systems: revoke SSO, reclaim the laptop, transfer file ownership, close the payroll record. Finding it took forty seconds. The remaining hour is execution, outside the product.

The distinctions between enterprise search, RAG, AI agents and a company brain come down mostly to where each one stops.

What an answer layer adds, and what it costs

An answer layer synthesises the retrieved passages into one response with citations. For the contractor question it reads all four sources, states 60 days, and links the two that agree. Six minutes of reconciliation become fifteen seconds of reading.

That is a real gain, and for high-frequency questions a large one. It is the only hop added: retrieval, connectors and permissions are unchanged underneath.
The cost is usually understated. An answer layer synthesising from stale content produces stale answers faster and more confidently than search does.

Search hands you four documents with visible dates and visible disagreement. The friction is a warning. An answer layer resolves the disagreement and returns one confident paragraph. If it resolved wrongly, the 2023 policy over the corrected thread — the output looks exactly like a correct answer. The citations make it look more trustworthy, not less.

Adding the synthesis hop raises the cost of bad content. It does not lower it. Organisations with stale, duplicated, unowned documentation often buy an answer layer to escape that problem and instead industrialise it. Ownership comes first: named owners, review dates, deprecation of superseded pages. That is what turns a document pile into something worth synthesising.

The enterprise search software landscape

Deployment and pricing transparency vary more across this market than capability descriptions suggest. The table below uses only publicly stated facts as of 17 September 2026.

Published per-seat pricing correlates with self-serve products; demo-only motions correlate with cloud-only deployment. If the index must run inside your own boundary, that eliminates vendors before any feature comparison begins, the practical starting point for a Glean comparison rather than the end of one.

How to evaluate enterprise search software

Which systems do you connect to, and how completely? A real answer names systems and limits: "Confluence including comments and attachments; Jira including comments but not attachment contents; Slack public channels, private on admin grant, DMs never." A logo wall is not an answer.

Is permission enforced at index time or query time? A real answer is one of those two phrases plus a number. "Query time, against cached group membership refreshed every 15 minutes." Or: "Index time, ACLs re-expanded hourly." Both are workable if disclosed; neither is, if the vendor cannot say which it is.

How fresh is the index, per connector? A real answer is a table, not a sentence. "Slack via events, under 60 seconds. SharePoint via change API, 5 minutes. Legacy file share via full crawl, nightly." Ask about deletions, which lag more often than edits.

Can you explain why a given result ranked first? A real answer shows the contributing signals for a live query in your tenant: match score, recency weight, click history, source authority. "Our model learns from usage" describes a black box.

Where does the index run? A real answer is a topology: vendor cloud, your cloud account, or your own infrastructure. If your own environment is offered, ask what runs there and what still calls out — the difference between genuine BYOC enterprise AI deployment and a control plane holding your metadata.

Which region holds the index, the embeddings and the logs? A real answer distinguishes the three. Content, vectors and query logs often sit in different places, and logs are what quietly leaves the region.

What happens on a failed query? A real answer describes the empty state honestly. Does the system say it found nothing, or return weak results that look like answers? Does it log the miss? That log is the most useful artefact in the product, and many vendors never surface it.

Choosing between search, an answer layer, and an agent platform

Most organisations need the first row and buy for the second. If your people know where things live and are simply slow to reach them, search alone produces the larger improvement.

The out-of-date row gets ignored most often. No retrieval architecture repairs documentation that nobody owns. Both faithfully surface what you have; one does it with more confidence than your content deserves.

Agent platforms carry a different risk profile. Retrieval errors return the wrong reading; action errors change the wrong record. They belong where the task is execution.

Libra WorkBase sits in this space with one deliberate difference: it deploys to Libra's cloud, into your own VPC, or fully self-hosted on your infrastructure. Where the index cannot live in a vendor's tenancy ,regulated sectors, data-residency commitments, security teams that will not approve a copy of the corpus leaving the boundary — that constraint decides the shortlist before features do.