Enterprise AI Search, Explained

Public web search works because the web is one corpus, heavily linked, and mostly written for strangers. None of that holds inside a company. The average mid-size organisation runs separate search boxes in Slack, Google Drive, Confluence, Jira, GitHub, Salesforce, and a helpdesk, and each one only knows about itself. Answering a real question means visiting four of them and already knowing which four.

Vocabulary is the second failure. Internal documents are written by people for colleagues who share the jargon, so the renewal process might be documented under a project codename nobody outside the team recognises. A keyword index cannot connect “how do we handle contract renewals” to a page titled “Nightjar runbook”. Semantic retrieval can.

Then permissions. Every one of those systems has its own access model, and any search layer that spans them inherits the union of all of them. This is what makes internal search genuinely harder than web search rather than just messier: getting the ranking wrong is embarrassing, and getting the permissions wrong surfaces a compensation spreadsheet to the whole company.

Four stages, in order. Everything vendors argue about is a variation on this sequence.

That fourth stage is where enterprise search and agentic RAG converge. Simple deployments retrieve once. Harder questions, particularly ones that span a ticket system and a document store, need the model to search again after seeing the first results.

The answer depends on where enforcement happens. There are three designs in the market and only one of them is safe.

Post-filtering retrieves the best passages, then removes the ones the user cannot see. It leaks through the model: an answer synthesised before filtering can restate a protected fact without citing it. Avoid.

Index-time ACL inheritance with query-time enforcement is the correct design. The connector reads the source system’s permissions during ingestion and stores them on the chunk. Every query carries the asking user’s identity and group memberships, and the retrieval filter is applied before ranking, so protected content never enters the model context. This is what Glean does, and it is the baseline any competitor has to match.

Shared-index-per-team is the shortcut some smaller tools take: one index per group, no per-document granularity. It works until someone shares a single document across teams, which is immediately.

Two operational details separate a working implementation from a demo. Permissions change constantly, so the sync interval for ACLs matters more than the sync interval for content; a revoked share that takes twelve hours to propagate is a twelve-hour exposure. And every answer needs an audit record of which documents were retrieved for which user, or you cannot investigate an incident after the fact.

Buying a hosted product gets you connectors that already work, a permission model somebody else has hardened, and an interface non-technical staff will actually use. You accept the vendor’s model choices, the vendor’s ranking behaviour, and an annual contract sized for a company larger than yours if you are mid-market.

Building on a composable stack means assembling connectors, an index, a retrieval layer, and a model gateway yourself. You keep model choice, you can run the whole thing inside your own network, and you pay for usage rather than seats. The cost is integration work and the ongoing job of keeping connectors current as source APIs change.

Swfte sits on the composable side. You pick the connectors you need from Slack, Google Drive, Notion, Confluence, GitHub, Linear, Jira, Salesforce, HubSpot and 50+ others; permissions are enforced from the source ACL; and retrieval runs on the same Connect gateway that runs your agents, so the model behind search is a configuration choice rather than a vendor decision. Swfte holds SOC 2 Type II, supports HIPAA-ready deployment, and runs on-prem for air-gapped environments. That last point is often the deciding one for defence, healthcare, and regulated finance.

Glean is the reference implementation and deserves the position: 100+ connectors with genuinely best-in-class ACL-aware ingestion. The reason an alternatives market exists at all is the contract floor, not the product. Microsoft 365 Copilot wins on distribution when your content already lives in SharePoint and Teams, and struggles exactly where content does not. The DIY route on Elastic or OpenSearch is the honest choice for teams with a search engineer and an unusual corpus, and a slow, expensive mistake for teams without one.

Enterprise search has two cost curves that behave differently, and conflating them is how budgets get set wrong.

Indexing cost scales with your corpus and its churn. Every document is chunked and embedded once, then re-embedded whenever it changes. Embedding is cheap per token and unavoidable in volume: a million-document corpus is a real one-time bill, and a corpus where ten percent of documents change monthly keeps paying it. Storage for vectors plus the original text is the other standing cost.

Query cost scales with usage, not corpus size. A grounded answer sends retrieved passages plus the question to a model, so the input is dominated by how many chunks you retrieve and how large they are. Retrieving twenty 800-token chunks instead of eight is a 2.5x increase in per-answer cost with, usually, no improvement in answer quality.

Seat pricing and usage pricing invert at different points. Seats are predictable and punish you for rolling search out to everyone, which is the entire goal. Usage pricing rewards broad access with light per-user volume and needs a cap when someone wires search into an automation. Work through the arithmetic for your own corpus in the cost of RAG.