Inbox Atlas

Region Search
Embedding Search

GoDaddy Domain Name: InboxAtlas.work

Inspiration

We kept running into the same problem: AI agents are terrible at knowing where to look. Ask for "coding competitions" and keyword search can miss a Codeforces email because the message never uses those exact words. Worse, when the information isn't there, agents keep searching, burning thousands of tokens in the process.

We wanted to build a navigation layer for information, not just another search box. Inbox Atlas turns a question into a region of meaning, finds the information that belongs inside that region, and can confidently say when the topic isn't there.

What it does

Inbox Atlas is a token-efficient retrieval system for both people and AI agents.

Instead of returning whole documents or blindly returning the top k chunks, it:

Expands a question into meaningful positive and negative facets.
Searches email and second-brain notes by semantic regions, rather than keywords alone.
Determines whether a topic is actually present, allowing an agent to stop searching.
Extracts only the sentences needed to answer a question within a token budget.
Navigates nested folders before opening individual notes.
Exposes the same retrieval system through an MCP server, web interface, voice, and iMessage.

The results were significant: keyword search found no relevant email for 7 of 12 meaning-based queries, while Inbox Atlas found the relevant emails for all 12. Our context packs averaged 249 tokens, compared with 4,445 for grep-style retrieval.

How we built it

We built Inbox Atlas as a retrieval pipeline rather than simply prompting an LLM.

Grok expands each question into positive and negative facets, such as "Codeforces round" and "ICPC regional," while explicitly excluding things like job coding interviews. Those facets are passed through atlas-embed, our trained encoder built on a frozen BGE backbone with LoRA adapters and distilled from a frozen cross-encoder teacher. A Set Transformer can then learn a region from the facet set.

We trained the encoder on 224,867 cleaned Enron emails, with 19,980 Grok-labeled emails and 491,000 teacher-scored pairs. The main training run took about 90 minutes on one RTX 4070 SUPER.

The rest of the system combines local embeddings, region scoring, hub correction, sentence-level context packing, folder navigation, an MCP server, Postgres with pgvector, voice, and an iMessage interface.

Challenges we ran into

The hardest problem was not finding similar text. It was teaching the system where the boundary of a topic is.

A normal embedding search will almost always return something, even when the requested topic is absent. We needed Inbox Atlas to distinguish "this is relevant" from "this happens to be vaguely similar." We addressed this with hub-corrected scoring against random topic sets and a calibrated yes/no decision, allowing agents to stop instead of continuing to search.

We also had to solve the token-efficiency problem without sacrificing retrieval quality. Returning whole chunks wastes context, so we built a sentence-level context packer that selects the useful sentences and stays within a token budget.

Finally, making semantic retrieval work across both email and deeply nested markdown notes meant building folder-level navigation rather than treating every document as an isolated search result.

Accomplishments that we're proud of

We're most proud that the system's core claims are measured rather than theoretical.

7/12 meaning-based queries returned zero relevant results with keyword search; Inbox Atlas found all 12.
0.867 Recall@10 vs. 0.175 for keyword search.
249 tokens per question vs. 4,445 for grep-style retrieval, an 18× reduction.
31 tokens when a topic is absent, instead of thousands of tokens spent searching.
On a 419-note second brain, the correct note was found 12/12 times in 625 tokens.
Our trained encoder improved vague-query nDCG@10 from 0.635 to 0.692 over the frozen base model.

We're also proud that Inbox Atlas isn't just a backend search algorithm. The same system works as an agent tool, a web search experience, a voice interface, and an iMessage assistant.

What we learned

We learned that retrieval quality isn't just about finding the right document. For agents, retrieval is also about knowing when to stop and how little context is actually necessary.

We also learned that treating a question as a single embedding point is limiting. By turning it into a region with positive and negative facets, we can represent the different ways an idea may appear in someone's inbox while explicitly excluding misleading matches.

Most importantly, we learned that the best metric for an agent retrieval system isn't simply accuracy. It's accuracy per token. Inbox Atlas matches chunk RAG's 75% accuracy while using 249 tokens instead of 740, and it can abstain entirely when a topic is absent.

What's next for Inbox Atlas

The next step is making Inbox Atlas a universal navigation layer for personal information.

We want to fine-tune the retrieval system on each user's own mail, then extend the same interface to calendars, documents, chats, and other personal knowledge sources. We also want agent feedback to become training data, allowing the retriever to continuously learn which context was actually useful.

Longer term, we want Inbox Atlas to move beyond answering questions and become persistent navigation for your entire digital life: agents could discover relevant information across every connected source, know when nothing useful exists, and retrieve only the context they actually need.