Why Glean and context graphs finally made enterprise AI click for me

A few months ago, a director asked me to automate how we respond to fleet discount requests. Simple ask. Except the “process” lived in five different places: an email chain with the fleet account manager, a Slack thread where a friend of mine in finance shared margin concerns, a spreadsheet with last quarter’s approvals, a CRM note about the customer’s churn risk, and someone’s memory of what we did for a similar account last year.

Where do I even point an agent at that?

I sat with the request for a while. I mapped out the data sources. I sketched decision trees. And I kept running into the same wall: there was no single place where the logic lived. The “process” wasn’t documented; it was distributed across people, tools, and institutional memory.

The data existed. What was missing was the context, and I didn’t know how to build that.

What my AI experience didn’t prepare me for

I’ve had the chance to work closely with AI systems for a couple of years now — building data pipelines, ML models, RAG systems that actually made it to production — but most of that work was contained. Build a retrieval system over these documents. Train a model on this dataset. Create an ingestion pipeline from this source to that destination.

Cross-system workflows are different. The fleet discount question isn’t answered by one system: it requires pulling margin data from finance, churn signals from customer success, historical precedent from a conversation with the previous fleet director… and then synthesizing all of that into a recommendation that matches how the organization actually makes these calls.

I tried stitching together automations, custom scripts, prompt chains with handoff logic. Some worked for narrow tasks, but none scaled to how work moves across an organization.

I wasted more time than I’d like to admit on approaches that felt clever but couldn’t handle the messiness of real enterprise work.

The moment it clicked

Late December, I came across an article on X from Jaya Gupta that was oddly high on bookmarks and making a lot of (good) noise. The title — calling context graphs “AI’s trillion-dollar opportunity” — caught my attention, and something shifted.

Jaya’s thesis was simple: the last generation of enterprise software became valuable by being systems of record. Salesforce owns customer data. Workday owns employee data. SAP owns operations. These systems are excellent at capturing what exists: the current state of the business.

But they don’t capture why, or even how, decisions were made. The exception that got approved. The business rule that justified it. The cross-functional context that informed it. That reasoning lives in Slack threads, email chains, meeting conversations and, of course, people’s heads. It’s never been treated as data.

A context graph captures that layer: the decision traces, the exceptions, the patterns of how work gets done. It makes precedent searchable. It gives agents the playbook that humans carry in their heads.

I read that and thought: this is exactly what I’ve been struggling with. There was finally a name for it.

What a context graph is

A context graph is a model that connects your enterprise entities — people, documents, tickets, systems — with the actions and events that happen between them. It captures not just what exists, but how work flows: who did what, in what order, and with what outcome.

I’ll continue with the example from before.

To answer whether we should approve a fleet discount, I need margin data from finance and the churn risk flag from customer success. Those live in different systems, owned by different teams, with no shared logic connecting them.

A traditional system can tell me: “This customer has a 15% churn risk score.” It cannot tell me: “The last three times we saw this risk profile, we approved an 8% discount, and here’s the reasoning that justified it.”

That’s the difference between a database and a playbook. An agent doesn’t need to know “there’s a discount request.” It needs to know: “When requests like this come in, these are the steps that typically lead to resolution, here’s where they deviate, and here’s why.”

When you make actions a first-class entity, with timestamps and causal relationships, you’re no longer describing what exists. You’re describing how change happens. And that’s exactly what an agent needs to operate autonomously.

Real work is complex

People switch context constantly. They reuse the same document across multiple efforts. They start a document, abandon it, and pick it back up three days later. A single “edit doc” event might belong to multiple parallel streams of work.

The process for handling a fleet discount isn’t written down anywhere. It exists as pattern recognition in the heads of people who’ve done it before. When someone new joins, they learn by watching, asking questions, and making mistakes.

Tribal knowledge, it’s called. But that’s just a polite way of saying: the most important context in your organization isn’t captured anywhere a system can access it.

And this is the gap that keeps enterprise AI stuck in pilot mode. Agents demo well on clean, bounded tasks. They struggle in production because production means ambiguity, exceptions, and context that lives outside any single system.

Finding Glean

My honest first reaction to Glean was skepticism.

I’ve seen many “enterprise AI platforms” that promise everything and deliver a chatbot with a nice UI and, sometimes, a fine-tuned LLM. I assumed this was more of the same.

I started using it. The interface was good. The connectors were impressive. It actually pulled from the systems where work happens (and with messy data), not just the systems where work gets documented. But I didn’t understand what was under the hood.

Then Arvind Jain, Glean’s CEO, published a response to Jaya’s article endorsing context graphs. And a few weeks later, a deeper technical breakdown of how they build them. I didn’t expect to learn this much about their architecture (and vision), but he explained it in detail.

Arvind made a distinction I think is critical: you can’t reliably capture the “why” behind decisions. The “why” is a thinking step that lives in someone’s head (as in the example I shared earlier). Sometimes it’s hinted at in a Teams meeting or a Slack message, but most of it never gets written down.

What you can capture is the “how.” The sequence of actions. The tools used. The order of events. The patterns that repeat across people and situations.

Over many cycles, the “how” approximates the “why.” You can infer rationales from patterns in how work repeatedly gets done, not by trying to store every human thought but by observing behavior at scale.

A few things stood out from Arvind’s technical breakdown:

Four layers, each depending on the one below

First, deep connectors that capture not just documents, but change events: who edited what, when, in what sequence. Second, a knowledge graph that resolves entities across systems (so “Dunder Mifflin Inc” in your CRM and “Dunder Mifflin” in support tickets become the same customer). Third, a personal graph that tracks individual work patterns: your tasks, your projects, how you move through tools. Fourth, the context graph itself, which aggregates anonymized patterns into process playbooks. Each layer depends on the one below it. Skip a layer, and the whole thing breaks.

The system learns the workflow by watching

This surprised me most. Glean doesn’t define “here’s the process for handling X.” Instead, they observe patterns, assign probabilities to different paths, and let agents choose the most likely one for the situation. When an agent runs, its actions become new data for the graph. Successful runs reinforce patterns. Runs that fail or need intervention highlight gaps. Every agent execution becomes feedback that improves the next one. That’s a learning system.

The privacy model, and my doubt about it

To build useful process models, you need to aggregate behavior across people. Jain describes their approach. Traces are abstracted into anonymized steps: action type, tool family, timing, outcomes. No raw text, no user identifiers, no customer-specific content. Patterns only count if they appear across multiple distinct users. That sounds right in principle. But I don’t know how it holds up in practice: how anonymous is “anonymized” when you’re dealing with small teams or unique workflows? Employees won’t adopt tools that feel like surveillance. If Glean’s privacy model works as described, it’s a differentiator. If it doesn’t, it’s a privacy problem.

What this means

I don’t know if Glean becomes the trillion-dollar company Jaya Gupta’s article suggests.

But the direction makes sense. More than that, it’s the first architecture I’ve seen that actually matches how enterprises and big (really big) organizations operate.

Companies spent decades recording and digitizing transactions. We built systems of record for every object in the business: customers, orders, employees, tickets. But we never captured the reasoning that connects them. The “how did we decide this” and “why did we make an exception” stayed in people’s heads, or got buried in communication tools that were never meant to be queried.

Context graphs are an attempt to capture that layer. To make the “how” of work legible to AI, so agents can do more than retrieve information: they can participate in processes.

I don’t think this is fully solved yet. Building these systems is hard. Keeping them accurate as organizations change is harder. But for someone who’s spent years trying to automate work that refuses to fit into neat, shiny boxes, it’s the first approach I’ve seen that doesn’t require pretending enterprises are simpler than they are.

The companies that get here early will have an advantage built on better context, not better frontier models. I don’t think Glean has it figured out, but they’re working on the right problem: most enterprise AI is still trying to make chatbots smarter, and this is trying to make organizations legible to machines. That’s the problem I want to be working on.

---

References

• “AI’s Trillion-Dollar Opportunity: Context Graphs” — Jaya Gupta & Ashu Garg, Foundation Capital (December 2025) — thread on X
• “Context is the Next Data Platform” — Arvind Jain, Glean (January 2026) — glean.com/blog/context-data-platform
• “How Do You Build a Context Graph?” — Arvind Jain, Glean (February 2026) — thread on X

Originally published on LinkedIn, February 2026.