Building an Email Agent That Finishes the Work

Learning to ask the right questions

Loïc Houssier arrived at a harbor with a security researcher’s background and a process-improvement assignment. His colleagues maintained submarine systems he did not understand. To help them find productivity gaps, he had to ask how their work happened and help specialists examine it themselves. Curiosity became a management tool when his technical expertise no longer supplied authority.

Houssier had studied mathematics and considered a doctorate in applied mathematics and cryptography before choosing offensive security research, then working in telecommunications and defense. His later experience in electronic signatures supplied a complementary lesson: sell the business outcome. His Paris-based company pitched technical capabilities to chief information officers; DocuSign pitched value to human-resources leaders and other functional heads. That difference helped persuade his company to join forces with DocuSign.

DocuSign acquired only the signature business. In Houssier’s account, French authorities blocked a sale of the whole company because its other activities included security technology for defense customers. The resulting carve-out—separating the business before selling it—took roughly six months. Teams, source code and systems had to be divided, the data center replicated, and shared systems removed.

That experience informs his advice to European founders: build on strong engineering education with greater emphasis on product creation, growth, organizational scaling and ambition. He encourages serving English-speaking users globally from the outset, while acknowledging progress in Europe’s startup ecosystem and AI businesses.

A seemingly simple signing product also illustrates how global requirements multiply engineering work: - Regional standards: European digital signatures require different technology and dedicated maintenance teams in Houssier’s account. - Local operations: compliance and data-residency requirements introduce dedicated teams and data centers, including in markets such as Canada and Australia. - Different agreement workflows: Japan’s hanko, a stamp-based approach, changes how the product must handle agreements. - On-premises deployment: some customers need a signing appliance. Houssier describes key deletion intended to prevent a thief from signing as its owner, without establishing the exact trigger.

Remove work without slowing the inbox

Superhuman’s AI design starts with a constraint: improve productivity without adding latency or interrupting a fast workflow. Early features fit into existing moments of work—classifying a message, summarizing a long thread or noticing a missing response—rather than requiring users to seek out a separate AI experience.

The assistance takes several forms: - Batch attention: classify pitches and marketing so users can review them at a chosen time, such as Friday. - Prepare the next action: resurface an email after two days without an expected answer, then supply a follow-up draft. - Route the work: recognize an availability request and prepare a reply bringing in the executive administrator who handles scheduling.

Ask AI, the conversational inbox interface, extends assistance across email history. One participant automatically archives roughly 30–40 newsletter subscriptions, then asks each Friday for a summary and suggestions for deeper reading. Others use it to find phone numbers, sponsor contracts and venue agreements.

The interface changes what people think to ask. A longtime user initially triggered Ask AI accidentally from the search bar, then began using it deliberately. Growing familiarity with conversational software and deliberate answer-quality improvements are both offered as explanations for increased use; the user’s impression does not distinguish their effects.

Search beyond the first plausible matches

An approximate memory may be the best query a person has. One participant recovered a presentation link shared around six months earlier by describing an incomplete recollection of a conference. They estimated saving half an hour of manual searching. That anecdote exposes the retrieval problem: many emails can resemble a request without containing its answer.

Deep search uses an agentic loop: the system inspects results and decides whether to continue. Semantic search finds messages related in meaning to the request; pagination lets the agent examine them in batches. 1. Retrieve roughly 40 semantically related emails. 2. Inspect the batch for the requested answer. 3. If the answer is absent, inspect subsequent batches and broaden the semantic search range. For a frequent conference attendee, hundreds of messages may be plausible matches. The first page is only a starting point.

The broader framework combines small tools selected by a plan. Detecting availability, understanding interaction partners and writing email are separate capabilities. A planning step selects the tool needed for each step, then makes the calls. Superhuman developed its own implementation through repeated iteration, choosing multiple models for different strengths.

One targeted failure mode is agent laziness: handing an already delegated decision back to the user. If someone supplies a document link and asks for 15 minutes tomorrow to review it, returning several slots and asking which they prefer leaves coordination unfinished. The desired behavior is to choose a time and schedule it.

Three engineers were described as working on the stack. Most effort went into testing frameworks and matching models to problems, with comparatively little spent constructing the tools. Sonnet reportedly worked well for agent handoffs compared with an unspecified OpenAI alternative—a qualitative observation without versions or benchmark conditions. Proxies allow model and agent implementations to be switched, but the speaker expects framework-specific tuning to increase switching costs.

Evaluate the capabilities inside the answer

Superhuman’s evaluations evolved from query–answer pairs into suites organized around capabilities. Difficult cases encountered during internal use became canonical queries: recurring test cases aimed at a particular problem. Evaluation checks the behavior that produces the answer, as well as the answer itself.

Three dimensions receive distinct treatment: - Agent handoffs: exercise difficult transitions found through internal use. - Deep retrieval: recover one particular fact from many emails. - Relative dates: interpret requests such as “last quarter” against the current date. End-to-end evaluations examine the final answer alongside whether handoffs and date handling were correct.

A memorable acceptance case required recovering the type of wood discussed with a contractor about a table roughly five years earlier. Satisfying that query became a condition for accepting the deep-search approach. High-volume internal inboxes supply demanding cases, though they cannot represent every customer’s data or questioning style.

Aggregation adds computation to retrieval. To answer how much time a user spent in Waymo rides last month, the described workflow selects receipt emails, extracts each trip’s duration and adds the durations together. The speaker calls it reliable without giving an accuracy measurement. Work with Anthropic explores generating and executing code on the fly for aggregation, with broader use under discussion; the exact runtime is unspecified.

Local speed and backend search

Superhuman builds on Gmail and Outlook, including their spam detection, to improve the email systems users already have. It stores email locally for offline use and targets interactions under 100 milliseconds. That is a design goal, not a measured AI response time. The speaker argues that relying on the network would prevent consistently meeting it.

Local and backend history serve different scopes: - Initial offline history: installation downloads the last 30 days of email. - Accumulated local history: messages remain over time, with the example of optimizing for two years of email for a two-year customer. - Backend AI search: infrastructure holds five years of history and uses embeddings and hybrid search, though the combination of retrieval methods is not detailed. The older local search used database rows representing emails.

Mobile storage had used Realm. At the time of the conversation, the speaker described it as partly sunsetted and said the team urgently needed an alternative; SQLite was a possibility, not a selected replacement. Keeping email on-device also contributes to memory and storage complaints.

On-device models are primarily an offline-functionality investment. Semantic search works less well offline, motivating exploratory provider discussions; reducing cost is secondary to preserving quality. Superhuman also uses Swift and Kotlin to control mobile behavior while retaining each platform’s native feel. Whether inference should belong to individual apps or be shared at the device level remains open.

Establish quality, then optimize cost

Inference selection varies by task and changing model quality. The mix includes OpenAI, Anthropic and hosted open models, with Llama and BERT used for classification. Using Google’s cloud also creates a financial incentive to consider Gemini. The provider discussion does not resolve which email data each provider receives or can see.

The respondent’s rule is start with the most capable model, establish acceptable quality, then optimize costs. Speed and ease of working with a provider also matter. A questioner challenges quality as a differentiator between providers serving the same open models, raising heavy quantization as one possible source of differences. The exchange offers selection criteria, not a measured provider comparison.

Billing presents a separate tradeoff: - Fixed capacity provides a spending bracket: the respondent finds paying for a “box” easier to budget within. - Token billing follows usage: the questioner emphasizes that serverless capacity scales up and down; the respondent emphasizes uncertainty in forecasting adoption. Processing every email adds another variable: message length. Average and median token counts across short and long messages become consequential forecasting inputs. Joining a larger organization increased the importance of credible three- and six-month projections.

The questioner argues that very large buyers should evaluate economics at trillions of tokens, where purchasing options extend beyond ordinary serverless pricing. The respondent prioritizes shipping quickly with controllable costs and optimizing after demand is established. Some customers reportedly offered to pay $200 a month for the best model; that is anecdotal willingness to pay, not an announced tier or evidence of purchases.

Drafting is easier than deciding

Asked what desired features current models cannot support, the respondent identifies no specific capability gap: the challenge is execution. That turns the discussion toward how people will interact with email. Houssier imagines a product announcement spoken by Rahul and heard by a customer during a commute. Spoken composition and audio consumption are possibilities, not announced features.

A more immediate opportunity is answering recurring requests with advice the user has already written many times. Automatic response drafting was being tested internally, including polite declines for tooling pitches and replies directing applicants to human resources. Another participant proposes existing snippets plus contextual personalization: keep a proven response and let AI adjust the details.

The unresolved threshold is whether reviewing drafts costs less than writing replies. If users discard enough drafts, preparation becomes another queue to manage. The speaker’s 80/20 and 90/10 acceptance splits are hypothetical ways to frame that decision, not observed results.

The larger goal is an AI executive assistant that handles much of the email work founders and executives delegate to a person. A beta availability feature provides a bounded version: an incoming lunch request produces a draft with three proposed slots, and the user decides whether to send it. One participant wants to avoid individual decisions entirely; Superhuman’s described approach retains human oversight, potentially through the user’s existing assistant.

Availability does not establish preference. A human assistant may know to rearrange a busy calendar for a VIP, or avoid someone after a recent falling-out despite frequent past interaction. Eliminating unnecessary questions about a delegated task therefore does not settle every scheduling decision. One participant prefers batching decisions into a daily call with an assistant rather than remaining involved in each action.

One proposed way to learn those boundaries is to acquire a virtual-assistant business, observe its human workflows and gradually automate parts of the service. The responding speaker considers this intensive but useful for identifying what to automate first. No acquisition commitment is made.

Context helps; personal memory needs a shape

Following Grammarly’s acquisition of Superhuman, the proposed combination assigns complementary roles: - Coda supplies knowledge: Coda Packs are integrations that ingest data, creating a pipeline for company knowledge. - Grammarly supplies workflow context: its presence across applications could reveal what the user was working on before opening an email. Moving from Jira or Google Docs into email could then help an assistant enrich a draft without asking the user to reconstruct the context. Integration and improved accuracy remain future expectations in this account.

That ambition prompts a browser debate. One participant proposes a Superhuman browser; another expects browsers to become thinner or merge into the operating system. Raycast serves as a personal example of a central productivity interface that replaces browser bookmarks. Others point out that HTML rendering, JavaScript, local storage and extensions still need to be provided.

Richer memory raises a different question: could a knowledge graph—entities such as people, companies and projects, connected by relationships—help the assistant understand the user? Superhuman was not yet using a graph database. Challenged on a claim that the technology was not ready, the respondent acknowledges that the team had not tried it and accepts the criticism.

The substantive design concern is whose taxonomy the graph should encode: which kinds of things exist, and how they fit together. People and companies seem straightforward; tasks, projects and initiatives introduce choices about hierarchy and depth. Obsidian illustrates the problem because users define entities through their own templates and workflows. A participant’s Productboard experience offers a parallel: shared categories such as authentication and billing did not make company-specific roadmaps easy to organize into one reusable hierarchy.

The disagreement returns to the desired outcome. One participant wants an assistant that remembers every activity and conversation; the respondent asks what a richer model improves, such as draft accuracy, and raises ongoing computation as a concern. These remain design concerns rather than tested limitations. A specialist memory layer could be something Superhuman consumes: Upside is introduced as an effort to mine email for customer-relationship records and a knowledge graph, not as an existing Superhuman integration.

The competitive ambition is proactive assistance where work already happens. The respondent contrasts that with their characterization of ChatGPT as waiting for requests, arguing that Grammarly’s presence creates opportunities to help earlier. Rahul also reportedly compares Superhuman’s answers with Gemini and OpenAI products, making them practical quality benchmarks as well as competitors.

Measure coding assistance, not generated lines

Superhuman’s coding-AI adoption began in Q1 by removing approval friction: leadership promised budget approval within an hour and security review within 24 hours. Early qualitative feedback favored frontend work, with weaker experiences on the Go backend and poor results for iOS and Swift at that time. v0 became the preferred tool for clickable prototypes, letting the founder review behavior rather than only static designs.

In Q2, the team cataloged successes and failures. Understanding unfamiliar code stood out: one speaker reports replacing a day of tracing entry points and dependencies with roughly 30 minutes using Claude Code. Claude Code and Warp also helped answer implementation questions, such as how Gmail refresh tokens were handled, by returning file links and high-level explanations. These are reported orientation gains, not controlled coding-speed measurements.

Pull-request labels captured two questions: was AI used, and was it productive? The respondent estimated roughly 80% participation in labeling, about 90% AI use among reported cases, and positive impact in about 90% of those AI-use cases. These were approximate self-reports without tool or token instrumentation. AI-assisted pull requests do not measure AI-written code: discovery and understanding counted as benefits.

Reported throughput rose from roughly four pull requests per engineer per week in Q1 to nearly five in Q2 and nearly six in Q3. The increase does not isolate AI’s contribution. The respondent calls pull-request throughput a debatable metric and also credits technical strategy, clearer goals and organization.

Faster engineering creates an organizational question: can marketing explain more features, and can support learn them? A participant raises this as a potential constraint, while Superhuman’s response emphasizes restraint because added capacity can also produce more bugs. At the time, the company was described as having 50 engineers, approximately 100,000 paying users and a senior, fully remote team. Its AI engineers spanned Patagonia to Canada, recruiting people who preferred not to relocate to the Bay Area.

Product judgment still belongs to engineers

The organization operates as a compound startup: Superhuman retains its own profit-and-loss responsibility and Rahul as founder, while Shishir and the parent company’s executive team act as its board. It is adding capacity to expand its reach, with AI also helping onboarding.

A participant raises an outside criticism of AI productivity: if an engineer ships more, who captures the extra value? That participant and the responding voices disagree with the objection. Their counterargument emphasizes fair pay alongside the satisfaction of useful work, quick access to tools and a strong team. In this view, greater effectiveness can benefit engineers through the work experience itself; it is an argument about motivation and retention, not a compensation finding.

The closing argument for learning to code compares AI with the move from assembly to C: a higher abstraction level still requires understanding the machine. Memory, swapping and servers remain relevant when tools conceal them. The prediction is that AI will amplify engineers who understand their work while giving those who avoid understanding it a misleading sense of comprehension.

The hiring pitch makes that responsibility concrete: user-experience ownership includes backend engineers who care about latency because a person experiences its consequences. As technical functionality becomes easier to imitate, the speaker argues, user flows, interfaces and product quality become more consequential differentiators. At the time of the conversation, hiring was broadly open across the Americas, and listeners were invited to try the product and report where it failed them.