Arvind Jain

The through-line

Everything Arvind Jain says traces back to one observation he made while watching a company he helped build come apart at the seams. Rubrik tripled its team in a year and got less done, and when he asked people why, the answer was blunt: "we cannot find anything in this company" [1]. Employees could not locate the information they needed and could not find the people who knew, and the company's knowledge sat fragmented across roughly 300 internal systems [1][6]. He has been working on the same problem ever since, and his framing of it has stayed remarkably stable while the technology under it changed three times: from a search index, to a conversational assistant grounded in company knowledge, to a platform for building agents [5][6]. The constant is his claim that a third of all working time is spent looking for information [1][6], and that the fix is a system that genuinely understands how a specific business works, its people, projects, customers and jargon, rather than a better keyword box [1][9].

The second through-line is temperamental. He is an engineer who keeps discovering that the hard parts of the job are not engineering. Selling was harder than building [2]. Working with marketing, sales, HR and finance was harder than working with R&D [2]. And, contrary to his own long-held instinct, building a good product turned out to be harder than selling one: "building products is actually incredibly hard. And in fact, if you actually build a good product, uh, everything else you can, you know, you can sort of make them fall in place the right way" [6].

On why enterprise search stayed broken for decades

He is dismissive of the idea that this was ever a solved problem. At Google, the running joke was that a company in the business of helping the whole world find information "never really helped ourselves inside Google", where finding a design document was incredibly hard [1][10]. The appliance-era attempts failed for a structural reason: "It never worked because it was so hard to actually even put stuff inside of that box" [1]. He is equally aware of the generation of enterprise search companies that came and went in the 2000s [3], and he does not claim to have had a prophetic reading of the market. What made 2019 different was two things arriving at once: SaaS systems had become interoperable enough to connect to, and transformers and language models had arrived [1]. Google had put BERT into the open domain, and Glean pre-trained on each customer's corpus so the system could understand information semantically rather than by exact word match, shipping what he calls the industry's first vector search solution combined with traditional search techniques, before the vocabulary of vector search even existed [1]. He is candid that the origin was not strategic foresight so much as irritation at a problem he had lived through [3].

On relevance as a knowledge graph problem

His argument is that finding the right answer inside a company is mostly not about the document. Real enterprise data environments are complex in ways the internet is complex: fifty or a hundred years of accumulated writing, much of it obsolete and none of it labelled as such, plus material somebody wrote for personal use that was never meant to be authoritative [1]. Maps taught him how messy real-world data is, and he applies the Google mindset directly: "you have to deal with varying levels of quality of information and you have to extract the gems from from the noise" [1]. Recency is one signal; whether the author is a subject matter authority is another [1].

The larger point is that quality is not enough, because the right answer depends on who is asking. Search for an onboarding guide and the correct result depends on your role: "don't show me um the guide which is meant for the marketing team if I'm an engineer" [1]. So Glean builds a knowledge graph of the enterprise, modelling people, customers, partners, products, projects and teams, then draws connections to the knowledge itself by observing interactions, who reads what, who spends time on which material, which departments they sit in [1]. That coverage has to be comprehensive: structured and unstructured data, email and chat, Confluence documents, Jira tickets, customer interactions, increasingly meeting recordings, because so much of how a business actually works is people talking to each other [1][5].

On pre-computed context and the token bill

The sharpest competitive argument he makes is about how context gets assembled. Connecting ChatGPT or Claude live to Drive or a calendar means the model has to hunt: "these AI tools are very brute force in nature" [1]. Because the individual systems never had good search APIs, the first retrieval pass comes back imprecise, the model is unsatisfied, and it loops through repeated retrieval passes before it can begin the actual work [1]. That is slow and it burns tokens. Glean does the aggregation and organisation ahead of time, so "we can deliver the right context in one shot to AI so that it can work faster and be more accurate" [1].

He treats this as newly urgent rather than theoretical. Nobody was discussing token costs seriously two months earlier, and now it is the centre of every customer conversation, with companies reporting that an annual AI budget was exhausted before the first month was out because the tools are so hungry [1]. He has taken the same argument about cost, trust and relevance into other venues, including the case that Glean can halve token consumption [10][12].

On what agents actually are and how far to trust them

He deflates the word deliberately. An agent "is nothing more than like an application", a unit of work formerly done by a human, now done with AI reasoning over data pulled from the web or internal systems, sometimes self-reflecting, and writing its output back into enterprise systems [3]. The lineage is explicit: "you can think of AI agents as just a much more advanced version of RPA" [3]. What creates the excitement is direct ROI visibility, the prospect of doubling the efficiency of every person in the company [3].

On maturity he is deliberately unromantic. Agents today are quite basic and need significant supervision, and he barely sees any customer running agents fully unattended: they are "better run in a supervised you know in a supervised manner where a human is in charge and and looking at the work of the agent" [3]. He tells enterprise customers not to build all kinds of agents and leave them unmonitored [5]. But supervision does not destroy the value: "even if human supervision is required that doesn't make the agent worthless" [3]. His worked example is legal redlining of a third-party contract, a two-week human activity that an agent does in a minute; the human then spends two hours reviewing instead of a week, which is more than ninety percent saved [3]. He gives the same treatment to customer support ticket resolution [3] and to genuinely autonomous background flows, such as an agent triggered when a candidate submits a resume that researches the person, checks the resume against their LinkedIn profile and loads the findings into the recruiting system before a recruiter ever looks [5]. The agent-building platform exists because customers asked for direct access to the retrieval and permissions plumbing underneath the first two products, and it is aimed at business users in legal or finance who have never written software but know their own domain [6].

On models: closed first, open at scale

He expects a very large number of models, closed ones from OpenAI, Anthropic and Google alongside open-domain models and their derivatives, and he thinks keeping up will get hard enough that model choice becomes a deep infrastructure decision made by application developers, with the goal that for customers the LLM becomes "a technology that they don't really think about" [3]. Today most enterprise use cases run on closed models, and he thinks that is correct: early in building an application nobody is using yet, cost optimisation is pointless, so start with state of the art [3]. Open models earn their place at scale, when an application has millions of users and hundreds of millions of daily interactions, and a distilled smaller model becomes faster, more accurate for the narrow task, less prone to hallucination because its range of errors narrows, and far cheaper [3]. Two other drivers matter: regulation, where air-gapped operation leaves no choice, and control, meaning not wanting core business processes dependent on another company and wanting the ability to customise over time [3]. He welcomes new foundation model entrants without reservation, partly because specialisation is useful, with Claude favoured for coding work and other models for reasoning, and partly because competition delivers the advances more cost-effectively to application companies like his [3]. He has also engaged the broader industry questions of whether OpenAI and Anthropic will win the application layer, whether AI erases the bundling advantage incumbents have enjoyed, and how the United States and China compare in the AI race [11].

On trust, permissions and hallucination

He treats three things as non-negotiable before a business can rely on an assistant: the system must respect every user permission, it must not fabricate, and the model must be chosen and customised for the job [4]. Permissions are a first-class engineering problem rather than a feature, because unlike the internet, an employee inside a company gets to see some information and not most, so every integration required understanding each system's security model [6]. On fabrication, his position is that grounding every answer in verifiable company documents is the only route, with citations linking back to sources so a user can check the claim rather than trust a black box [4]. Fine-tuning on a company's own data, jargon and acronyms is what makes the system fluent in that company's language [4].

On the future of work

The image he uses most is a colleague who cannot exist: imagine an employee who has been there since day one, has read every document ever written inside the company, sat in every meeting and conversation, forgets nothing, sits next to you around the clock, and can reason over all of it [5]. Extended forward, that becomes plural: "every person who works is going to have this amazing team of assistants, co-workers, and coaches around them that is going to actually make them a lot more effective" [3]. He describes the current products in familiar terms on purpose, Glean as the Google for your work life and Glean Assistant as a more powerful ChatGPT that happens to know your company, capable of drafting a company-wide memo or writing code [5][6]. He also sees the assistant becoming proactive rather than waiting to be asked, monitoring related code, data and conversations so that stale technical documentation gets flagged and an update suggested, keeping the knowledge base from going out of date [4].

He frames the enterprise journey as two steps and insists on the order. First train and educate the workforce until every employee is comfortable with AI and knows what it can do, which a general-purpose assistant connected to enterprise context does naturally; only then can those people look at business processes and work out where agents belong [5]. Part of that education is accepting that AI is a machine unlike any before it: ask the same question four times and it answers in different words, sometimes with a different gist, and people have to get used to that non-determinism [5]. His stated purpose for all of it is augmentation rather than replacement, automating the tedious work of finding information so people can do creative and strategic work [4], and he has argued elsewhere that teams will get bigger rather than smaller in a world of AI, and that we are only using a small fraction of what the technology can do [8][11].

On who uses it and where the value shows up

Adoption started with engineers, who needed to learn the technology and find the right people during onboarding, followed closely by customer support agents mining internal knowledge bases to answer tickets [6]. Sales is now one of the largest user groups, because a seller in a live call needs a feature answer immediately, and because their work spans both internal context and public information about prospects, which requires a search experience covering both [6]. Legal work such as contract redlining is another [3][6]. His argument for universality is that every knowledge worker in every industry needs information to do their job [6], and he points to a specific and expensive failure mode in engineering: "one of the highest areas of inefficiencies is when people actually build things that were already there" simply because nobody could find them [6].

On becoming a first-time CEO

He describes throwing out the Rubrik playbook entirely, and the reason is as much about business model as title. Rubrik's product was used by a select few people inside a customer, whom the team knew well and who helped build the product; Glean's is a consumer-like product used by everyone in the company, most of whom Glean has no relationship with, which sets a much higher bar on product quality before you can scale go-to-market [2]. The skill he names first is selling. As an engineer you build products you use yourself and someone else sells them; "Engineers rule the world. You get to be creative. You get to build stuff", and learning to get attention, request people's time and pitch was the hardest transition, one he thinks he eventually made by learning to match customer problems to the technology [2].

The second skill he says he is still learning is working with people unlike him. After twenty years surrounded by R&D people he thought of himself as easy to work with, and discovered otherwise: "people sometimes find it hard to work with me especially like if they're not in R&D" [2]. His advice to engineer founders is an awareness point first, that other people's ways of thinking are different rather than worse, and that assuming otherwise guarantees struggle [2]. He also recommends that every engineer turned CEO get a coach with a different background, and says he takes coaching informally from several people [2]. A detail-oriented person by nature, he has had to learn to go to the bottom of fewer things: "count three things that matter the most" and work those with the executive team, trusting the team on everything else [2]. Trust, in his account, is not intuition but accumulated observation of whether someone shows attention to detail and thinks analytically, after which your mind simply stops worrying about their area [2]. He is wry about founder mode, noting how many founders felt relieved by it because it lets them rationalise their weird behaviour, himself included [2]. Six years in, he counts a lot of mistakes and a lot of learning, and says the learning never finishes because the company at a thousand people and a multi-billion valuation is nothing like the Glean of two or four years earlier [2][5].

On hiring and mission alignment

He says the criteria have not changed with stage, partly because "we still believe we are a early stage startup" with a great deal left to do before durable success [2]. Beyond the standard attributes of hard work and technical excellence, he looks for evidence of hard work going back as far as education, and above all the desire to succeed, because startup work is hard and much of the pay is equity that can be worth nothing [2]. Two criteria he considers more particular to Glean: people who want to learn things beyond their core job, such as aspiring entrepreneurs treating the journey as an education [2], and people with a personal stake in the problem. That second one is a correction of a Rubrik mistake, where the team did not use its own product daily and had to rely on customers to say what to build. "when you build a product for yourself, it actually brings a different level of passion and excitement and energy" [2]. He tests explicitly for whether the problem is personal to a candidate, and credits that filter for a company where nobody questions whether the work is meaningful [2]. His summary of the whole subject is that "a company is nothing more than its people" [5].

On picking a problem and building the company

On founding, he is against the search for an idea: many people decide to start a company and then go hunting for a problem, and "That's a very difficult way of doing things" [5]. His own path was oblique. He had wanted to be an entrepreneur since IIT but joined Microsoft in 1997 precisely because he felt he had to learn how to code, build systems and talk to people first, and by the time Rubrik happened the ambition had faded and the company came about almost accidentally, when a friend he trusted to lead it asked him to co-found something in enterprise software [5]. Glean began the same way, from frustration rather than a market thesis [3], and he initially assumed he could build it inside Rubrik given how much of the connector work was already done there, before concluding it did not make sense [1]. Recruiting the first team was easy in a way Rubrik's had not been: colleagues from his Google search and AI years who would not join a data protection company were immediately excited by a great search product for work, because the pain is universal to engineers [1].

On what happens after the product works, he is emphatic that scaling gets harder, not easier: "the larger your company becomes, the larger your business becomes, the the more difficult it gets", and founders hoping for a break after product-market fit are in for a shock [6]. His own mistake was conservatism. Once customers show real interest he would now lean heavily toward speed to market, raise more capital, invest early in sales and marketing and go capture the market, because engineer founders tend to under-invest at exactly the moment that limits their upside [6]. He pairs that with a bias toward continuous change, thinking six months ahead about what breaks when the business or headcount doubles, and asking whether the leadership and processes fit the shape the company is about to take, because otherwise you end up reacting to problems you were forced into [6]. On build speed he refuses to generalise from his own long enterprise build, which demanded unanticipated security, compliance and privacy plumbing [6]. Today he would tell a founder to build something in a month or even weeks, get it to customers, and iterate, especially since AI lets an engineer operate as engineer plus product manager plus designer, and a product manager to reach into design and engineering [6].

Takeaways

• The founding insight came from watching Rubrik triple its team and lose productivity, with the top complaint being that people could not find information or the right experts, across roughly 300 internal systems [1][6].
• He puts the cost of the problem at a third of all working time spent looking for information, plus engineers rebuilding things that already existed but could not be found [1][6].
• Glean's technical bet in 2019 combined SaaS interoperability with transformers and BERT to build vector search alongside traditional search, before the terminology existed [1].
• Relevance depends on the asker, not just the document: role-aware answers, authority and recency signals, and a knowledge graph built from observed interactions [1].
• Live-connector assistants are "very brute force in nature" and loop through repeated retrieval passes; pre-organised context delivered "in one shot" is his answer to ballooning token bills, some of which exhaust annual AI budgets within a month [1].
• Start on closed frontier models while an application is unproven, and move to distilled open models at scale for cost, speed, accuracy, regulatory air-gapping and control [3].
• Agents are "a much more advanced version of RPA" and should run supervised, but a contract redline that took two weeks and now takes two hours of review is still more than ninety percent saved [3].
• Hallucination is addressed only by grounding every answer in company documents with clickable citations, and permissions must be enforced per user because inside a company nobody sees everything [4][6].
• Hire for the desire to succeed and for personal pain with the problem, because "when you build a product for yourself, it actually brings a different level of passion and excitement and energy" [2].
• After product-market fit, be aggressive: raise more, invest in sales and marketing early, and resist the engineer founder's instinct toward conservatism [6].