The Problem
Email is where work lives—and dies.
Projects, decisions, people, documents, deadlines. All of it flows through email, accumulates in threads, gets lost in volume. The average knowledge worker spends hours per day in their inbox, most of it trying to extract what matters from what doesn't. Sisyphus had a boulder. You have unread messages.
Grammarly had built a dominant position in writing assistance. But writing is only half the communication problem. The other half is reading—comprehending, synthesizing, acting on the information buried in your inbox.
The question Grammarly brought to us: Can AI help people read email the way Grammarly helps them write it?
The Constraint
This was 2022. Early days for applied AI in production consumer products. The question wasn't just "what should this do?" but "what can this do—technically, right now?"
Before designing anything, I had to understand what Grammarly's AI could actually deliver:
- Extractive summarization: Mark the most important sentences
- Abstractive summarization: Generate new, condensed summaries
- Entity recognition: Detect people, projects, organizations, terms
- Question generation: Identify what an email asks or answers
Some capabilities were production-ready. Some were experimental. Designing for AI capability that doesn't exist yet is science fiction. Designing for AI capability that ships next quarter is engineering. The gap between those two is where most AI products go to die.
The System
I designed a reading assistant that surfaces what matters and connects it to what you already know.
The Model: Entities and Summaries
I started by dissecting emails—different types, different purposes, different structures. What information do they contain? What would a human extract if they were taking notes?
This gave me the entity model:
- People: Name, email, domain, relationship (internal/external, team, frequency of contact)
- Organizations: Companies, clients, vendors referenced
- Projects: Named initiatives, workstreams, recurring topics
- Documents: Attachments, shared files, links to collaborative workspaces
- Questions: What does this email ask? What does it answer?
The Architecture
The system extracts entities from every email, relates them to each other, and builds a knowledge graph over time. The graph gets smarter the way compound interest gets richer: slowly, then obviously. When you read a new message, the assistant surfaces:
- A summary of the thread
- The people mentioned, with context from past correspondence
- Related documents and prior conversations
- Questions the email raises or answers
The experience lives in a Chrome extension, overlaid on Gmail. Users opt in to ingestion. The system learns as you work.
The MVP
I defined the minimum viable version: "I save what's important. I give it context. Reader surfaces it when I write." One sentence. The whole product in seventeen words.
I mapped each design concept to a specific AI capability Grammarly could ship today—not next year. Where extractive summarization was production-ready, we leaned on it. Where abstractive summarization was experimental, we designed fallbacks. The flow diagrams were engineering specs, not pitch decks—they showed integration points with Gmail, data dependencies, and failure states. (Failure states are the part of the design most designers skip. They're the part that matters most when the system meets the world.)
What the Work Demonstrated
The project didn't ship. External circumstances ended the engagement before release.
But the design itself proved several things:
- Reading assistance is a viable product category. Grammarly owned writing. The entity model and knowledge graph architecture showed how the same company could own comprehension—turning inbox chaos into structured, contextual intelligence.
- 2022-era AI could support the vision. By mapping ambitious goals to realistic capabilities, the design proved that email comprehension didn't require future technology. Extractive summarization, entity recognition, question detection—the pieces existed. The system design made them cohere.
- The entity model extends beyond email. People, projects, documents, questions—these aren't email-specific. The same architecture could structure knowledge from Slack, Notion, Google Docs. The design was a foundation, not a feature.
In under six months, we went from idea to working code. The product didn't launch. The proof of concept held. Patient, correct, waiting for the infrastructure to catch up with the insight.