Using Graph RAG to turn corporate email into contextual organizational knowledge
You come back from a week off and log into your company email account, just find out there are four hundred messages in it! Somewhere in there is a decision about a vendor contract, an action item someone assigned to you three threads ago, and a project update that matters but you'll probably never find by scrolling.
The problem isn't just the volume. Email holds relationships — who decided what, who owes whom a follow-up, and how one thread connects to another — while conventional search has a hard time seeing those relationships.
This summer, I mentored an intern project built around a simple question: can Graph RAG — retrieval-augmented generation layered on top of a knowledge graph — turn an Outlook inbox into something closer to a navigable knowledge source?
Microsoft 365 Copilot already uses Microsoft Graph and semantic indexing to retrieve relevant organizational information, including mailbox content. So, this project wasn't about replacing Copilot. We wanted to explore a narrower question:
Can an explicit, domain-specific knowledge graph add value when email questions depend on relationships across people, projects, decisions, and threads?
Why Traditional Email Search Falls Short
Keyword search answers "find emails mentioning Project X." It has a harder time answering the question people actually have: What decisions were made about Project X, who made them, and what's still open?
Three gaps explain why:
Information fragmentation. Relevant information is scattered across threads, people, and dates.
Loss of conversational context. A single reply often depends on everything that came before it — and sometimes on other threads weeks later.
Weak relationship understanding. Search can find similar words, but it doesn't necessarily understand that a decision led to an action item, or that two conversations months apart concern the same unresolved issue.
The Key Idea: Model Email as a Graph
Instead of treating each email as an isolated text chunk, an LLM extraction pass identifies key entities and relationships, mapping them into an in-memory Python knowledge graph.
A thread stops being a wall of text and becomes a small local graph. Stitch enough of these together and an inbox starts to look less like a pile of documents and more like a network of who-did-what.
That's the core difference from ordinary RAG. Traditional RAG retrieves relevant text. Graph RAG can also retrieve the relationships connecting those pieces.
For example:
Alice raised a concern about Project X → Bob proposed a change → Alice approved it → Charlie was assigned the follow-up.
If those relationships are represented explicitly, a query about Project X can retrieve the connected context rather than relying entirely on finding the right sentence in the right email.
This doesn't mean Graph RAG is automatically better. A question such as "What was the vendor's proposed price?" probably doesn't need a graph. The graph earns its cost when the answer depends on multiple connected pieces of information.
What About Microsoft 365 Copilot?
Microsoft 365 Copilot already grounds its answers in Microsoft Graph and a semantic index across mailboxes and other Microsoft 365 content (learn.microsoft.com). So before going any further, it's worth asking the obvious question: doesn't this already solve the problem?
Not entirely, and that gap is exactly what motivated this project. Microsoft Graph is fundamentally a data and API layer — it exposes messages, participants, and metadata, but it doesn't build an explicit map of who decided what or which action item came out of which thread. Our knowledge graph does that on purpose: it extracts the specific relationships an inbox implies, then lets retrieval follow those connections directly, rather than leaving that reasoning to happen implicitly inside a general-purpose index.
None of this competes with Copilot. It's a narrower layer underneath it, and Microsoft's own extensibility model — which lets developers build specialized Copilot agents with added knowledge and actions — is a natural place for something like this to plug in.
Three Practical Use Cases
We tested the approach on the Enron corpus, supplemented with synthetic email threads generated via LLM prompts to model multi-threaded decision changes and vendor negotiation scenarios that historical data lacks. The results were uneven — and that was probably the most interesting finding.
Prioritization and action items worked well — This is where the graph structure paid off most directly. Connecting the same task or deadline across separate threads is exactly the kind of relationship conventional search can miss.
Information search also held up — Questions requiring context from multiple related messages benefited from traversing the graph instead of matching text alone. The system could connect people, projects, and related conversations rather than returning only the messages with the strongest keyword matches.
Summarization was the weak link — We initially expected the graph's additional structure to improve summaries. It didn't help nearly as much as expected.
The likely explanation is simple: summarization is primarily a compression problem. The graph's value is in surfacing relationships. Those capabilities are related, but they aren't the same.
Graph RAG's advantage isn't uniform across email tasks. It is strongest when the question depends on connecting information across messages, and weakest when the task is essentially "make this shorter."
Why Graph RAG Instead of Traditional RAG?
| Dimension | Traditional RAG | Graph RAG |
|---|---|---|
| Retrieval Target | Relevant text | Text and explicit relationships |
| Orientation | Document/chunk oriented | Entity/relationship oriented |
| Best Used for | Factual lookup ("What does this email say?") | Connected context ("How are these pieces of information related?") |
The distinction matters because not every question needs graph reasoning.
"What's the meeting time?" is a retrieval problem.
"What decisions have we made about the vendor, who owns the remaining actions, and what changed since last month?" is a relationship problem.
Knowing when not to use Graph RAG is just as important as knowing how to build it.
From Inbox to Organizational Memory
The deeper idea isn't really about summarizing email faster. It's about organizational memory.
Corporate inboxes contain traces of decisions, expertise, project history, and commitments. Much of that knowledge becomes difficult to recover once a conversation goes quiet or moves between people.
A graph provides a way to connect those fragments.
This project is narrower than broader enterprise knowledge-graph efforts that combine email with calendars, chats, documents, and other organizational data. Instead, we focused on one high-friction source that almost every organization already has: email.
The question was deliberately practical:
Can we make the relationships already hiding inside email easier for an LLM to retrieve and reason about?
Toward a Copilot Agent for Email Management
The longer-term direction for this work is turning the graph into something people can actually use, not just a research artifact.
Microsoft's Copilot extensibility model already supports specialized agents that draw on outside knowledge sources and can take actions like archiving, flagging, and moving messages. That points toward an architecture where Microsoft 365 keeps doing what it already does well, and a purpose-built agent steps in specifically when a question calls for relationship-based reasoning:
The graph isn't meant to replace Microsoft's existing retrieval. It's meant to be used selectively — the way you'd bring in a specialist rather than have them handle every case.
Challenges and Lessons Learned
Two things stood out.
Entity resolution is a known gap, and we didn't close it.
We didn't get far enough to reliably collapse name variants and references into single entities. "Robert Smith," "Bob Smith," and "Bob" might all refer to the same person. A project may also have different names or abbreviations. That's not a minor implementation detail. It is one of the foundations the rest of the graph depends on, and it's something I'd prioritize differently next time.
Evaluation was harder than building the system.
Questions such as "Is this the right action item?" or "Is this summary faithful?" don't always have one clean answer. Reasonable people can disagree, especially when the source emails themselves are ambiguous.
The hard part of a project like this isn't standing up Graph RAG. It's building the unglamorous foundation — entity resolution, relationship quality, provenance — and having a defensible way to determine whether the system is actually working.
Conclusion: From Email Retrieval to Contextual Understanding
None of this required a new algorithm. Enterprise email is already moving toward AI-assisted retrieval, and Copilot is proof of that. What this project adds is narrower and more specific: an explicit graph that captures the relationships an inbox implies, used selectively where the question actually depends on them. Graphs aren't the answer to every email problem, and reaching for one where a simple lookup would do misses the point. But when the real question is how people, decisions, and threads connect over time, that structure is what actually gets an LLM to the right context — not just the right words.
Top comments (0)