Glean hits $300M ARR by selling enterprise AI teams a smaller token bill

Glean says it has crossed $300 million in annual recurring revenue, up from $100 million 15 months ago. That’s a steep climb for a seven-year-old enterprise search company, especially when nearly every large AI vendor is now chasing the same budget.

The company is still often described as “Google for the enterprise.” The shorthand works, but it misses the current sales pitch. Glean is selling a layer that can find and organize company context across Slack, Google Drive, Jira, Confluence, Salesforce, GitHub, ServiceNow, and the usual sprawl of SaaS tools, then feed that context to AI systems without wasting as many tokens.

That pitch lands because AI budgets are getting uncomfortable.

CEO Arvind Jain told TechCrunch that customers use Glean to cut AI bills by giving models the right internal information up front, instead of letting AI systems search company data directly and burn tokens along the way.

“If you connect your AI to Glean, it gives you all the information that you need to do your work, and that results in AI consuming far fewer tokens compared to if you unleash AI onto your systems directly,” Jain said.

It’s a plausible claim. It also needs proof.

The growth is hard to ignore

Glean reached $300 million in top-line annualized revenue after hitting $100 million just 15 months earlier. The company was valued at $7.2 billion when it raised a $150 million Series F last June. Its customers include Databricks, Reddit, Pinterest, and Samsung.

Those are serious logos, and the growth rate is strong even by AI startup standards.

The timing matters because Glean’s early advantage is under pressure. Jain said the company had little competition for its first four or five years. That’s over. Google, Microsoft, OpenAI, Anthropic, Salesforce, and Atlassian are all building or bundling products that overlap with Glean’s core idea: use enterprise data to make AI assistants useful at work.

Microsoft has Copilot inside Office, Teams, SharePoint, and the Microsoft Graph. Google has Gemini across Workspace. Salesforce has Agentforce tied into CRM data. Atlassian has Rovo for Jira and Confluence. OpenAI and Anthropic are pushing further into enterprise workflows through connectors, agents, and custom knowledge integrations.

Glean has to prove that a neutral, cross-platform layer beats whatever AI search and assistant features customers already get from their largest software vendors.

That’s a hard sell, but not a hopeless one.

Most large companies don’t live inside one clean vendor stack. Their knowledge is spread across cloud drives, ticketing systems, source repositories, CRM records, chat logs, wikis, HR systems, data catalogs, and security tools. A Microsoft-first assistant may handle Microsoft-native content well, but plenty of important enterprise information sits outside that boundary.

Glean’s bet is that enterprise AI needs a reliable view across the messy whole, not a single vendor’s slice.

The context graph pitch

Glean and others now call this a context graph. The technical idea is straightforward: build an indexed, permission-aware map of an organization’s people, documents, projects, tickets, code, conversations, and business objects.

That map gives AI systems better grounding.

A conventional retrieval-augmented generation setup, or RAG, typically takes a user query, searches a vector index or keyword index, retrieves relevant chunks, and puts them into a model prompt. That can work. Enterprise data makes it harder fast:

• Permissions differ by user, group, department, geography, and document type.
• Business meaning often lives across systems, not inside one document.
• Freshness matters, especially for tickets, incidents, sales records, and policies.
• Search relevance depends on organizational context, not just semantic similarity.
• Duplicate and stale content can poison results.
• Auditability matters because employees will ask AI systems for sensitive information.

A context graph tries to represent those relationships explicitly. Who owns this doc? Which project is it tied to? Which customer account does this support ticket affect? Which Slack thread explains why the design changed? Which GitHub repo implements the feature described in the product spec?

For developers and data teams, this is the gap between “find similar text” and “find the right operational context.” The first can return plausible junk. The second has a better shot at finding the artifact that matters.

Glean’s claim is that its product has spent years learning those enterprise relationships across many integrations. That first-mover advantage has technical weight if the system has mature connectors, strong permission modeling, useful ranking signals, and indexing pipelines that can survive real enterprise data.

Connectors are dull. They’re also where many enterprise AI projects stall.

Token savings are now part of the product pitch

The most interesting part of Glean’s current pitch is cost reduction.

Large language models charge by tokens, and enterprise agents can chew through them quickly. A naive assistant may retrieve too much context, summarize long documents repeatedly, call tools in loops, or scan broad data sources when a narrower query would do. Multiply that by thousands of employees and daily workflows, and the bill gets ugly.

Glean argues that its context graph reduces waste by giving models a smaller, better set of inputs. In practice, that can mean:

• fewer retrieval calls
• shorter prompts
• less irrelevant context packed into model windows
• fewer tool invocations
• fewer retries caused by bad grounding
• lower latency from reduced model and retrieval work

This is where enterprise AI economics become concrete. A model with a huge context window sounds attractive until teams start paying to fill it. Throwing 100,000 tokens at every ambiguous internal query is lazy architecture. It may work in a demo. It won’t survive procurement review for long.

A well-ranked, permission-aware retrieval layer can reduce token burn by narrowing the model’s working set before generation. That’s useful whether the model comes from OpenAI, Anthropic, Google, or an open-weight deployment running inside a company’s own environment.

Still, “we reduce your AI bill significantly” needs numbers. Savings will depend on query volume, model choice, prompt design, cache strategy, connector coverage, and Glean’s own pricing. If Glean sits in the path of every AI interaction, customers also need to count its subscription or usage fees against the model savings.

Cost reduction is a strong claim, but it comes down to architecture and pricing math.

ARR gets fuzzier with consumption pricing

Glean offers multiple pricing structures. Jain said customers can use a consumption-based model where they pay per use, or a hybrid model with a fixed monthly fee for active users plus separate usage fees for model consumption.

That detail matters because Glean’s $300 million figure can’t be read exactly like old-school SaaS ARR.

Traditional ARR implies recurring subscription revenue with reasonably predictable renewals. Consumption revenue behaves differently. It depends on usage, which can rise quickly and also fluctuate. If a company annualizes a recent usage run rate, the number may describe momentum rather than guaranteed repeatable revenue.

This issue isn’t specific to Glean. AI infrastructure and application companies increasingly report “ARR” that includes usage-based revenue. Investors like the growth optics. Buyers should read the metric carefully.

For technical leaders, pricing also shapes architecture decisions. Consumption pricing creates incentives on both sides. Vendors benefit when usage grows. Customers benefit when workflows become efficient enough to justify frequent use. If the same vendor claims to reduce token costs while also charging based on usage, teams should model the full path:

• Glean platform cost
• model inference cost
• connector and indexing cost
• storage and retention cost
• integration engineering
• security review and governance overhead
• support and admin time

The useful question is whether the total cost per successful workflow drops.

Why developers should care

Enterprise AI search can look like a CIO problem until developers are asked to wire agents into production systems.

The hard parts usually aren’t the chat UI or the model API call. They’re the boring parts that break trust:

• respecting document-level permissions
• keeping indexes fresh
• handling deleted or revoked content
• preventing cross-tenant data leakage
• tracing why an answer cited a source
• ranking internal knowledge better than generic semantic search
• integrating with identity providers and audit logs
• managing data residency and retention policies

A product like Glean can remove a lot of plumbing if it already supports the systems a company uses. That’s valuable. Teams don’t need every internal AI project to rebuild connectors for Google Drive, SharePoint, Slack, Jira, GitHub, Salesforce, and ServiceNow.

But centralizing enterprise context creates a serious dependency. If Glean becomes the retrieval and context layer for multiple AI agents, it becomes part of the critical path for productivity tools, support automation, sales workflows, engineering assistants, and internal knowledge systems.

That raises architectural questions:

• What happens when the context layer is down or stale?
• Can teams inspect and tune retrieval behavior?
• How are permissions enforced at query time versus index time?
• Can sensitive repositories be excluded or scoped?
• Does the system support customer-managed keys or private deployment options?
• How does it handle regulated data?
• Can developers call it through stable APIs, or are they boxed into a specific product interface?

For AI engineers, the main technical issue is control. A packaged context graph can save months of work, but teams still need observability. If an agent gives the wrong answer because retrieval pulled stale policy text or missed a recent incident ticket, engineers need logs, citations, ranking signals, and failure modes they can debug.

Black-box enterprise search becomes risky when it serves as the memory layer for agents.

The competitive squeeze

Glean’s early lead gives it credibility, but the large platforms have distribution that no startup can ignore.

Microsoft can put Copilot in front of hundreds of millions of Office users. Google can push Gemini through Workspace. Salesforce owns the CRM workflow for many enterprises. Atlassian has deep context in software planning and incident work. OpenAI and Anthropic are becoming default model providers for many internal AI teams.

Glean’s strongest argument is neutrality. It can sit across vendor boundaries and provide a consistent context layer for multiple assistants and models. That matters for companies that don’t want one platform vendor controlling the full enterprise AI stack.

The downside is procurement friction. Buying a separate enterprise AI search layer takes budget, integration work, security approval, and a clear case that bundled tools aren’t enough. Glean’s cost-cutting story is likely aimed straight at that objection.

If the company can show that better retrieval reduces model spend, improves answer quality, and cuts duplicated integration work, it has a strong case. If customers see it as another expensive AI layer on top of Microsoft, Google, Salesforce, and OpenAI, the pitch gets much harder.

The practical read

Glean’s revenue growth shows that enterprise search has become part of the AI budget conversation. The company is no longer selling only better internal search. It’s selling retrieval, context, permissions, and cost control as infrastructure for workplace AI.

That’s a good market to be in, but it’s getting crowded fast.

The technical case for Glean is strongest in companies with fragmented systems, strict permissions, and enough AI usage for token waste to matter. The business case depends on whether its context layer lowers the total cost and improves the reliability of real workflows, not demos.

Enterprise AI teams should treat the token-savings claim as testable. Run pilots against actual workflows. Measure prompt size, retrieval quality, latency, answer accuracy, failure rates, admin burden, and total cost. If the numbers work, Glean can be valuable infrastructure. If they don’t, it’s another layer in an already expensive stack.