Day 1, 4:02 p.m.: a customer asks your agent a billing question and gets an answer. Day 6, 9:30 a.m.: they reply "actually, that didn't work." If your agent lives in a chat widget, that second message starts from zero — the session died with the tab, the context is gone, and the customer gets to repeat themselves. If your agent lives in a mailbox, the reply arrives inside the conversation, with the full history attached by the protocol itself.
That's the argument in one before/after: chat sessions evaporate; email threads persist. And for agents that work across days rather than minutes, the thread is the most underrated memory substrate available.
Email threading runs on three headers, as the threading docs lay out. Every message carries a globally unique Message-ID
. A reply adds In-Reply-To
(the ID it's answering) and References
(the full chain of IDs, oldest to newest). By the time a thread is five messages deep, References
holds five Message-IDs in order — a complete, tamper-evident record of the conversation's shape, maintained by every mail client on earth.
Compare that to what we hand-roll for chatbots: session stores, conversation tables, context windows we serialize and rehydrate. Email gives you the equivalent for free, federated across organizations, and — this is the part I find most compelling — human-auditable. Anyone with mailbox access can read exactly what the agent's memory contains, because the memory is the correspondence itself. No vector store inspection tools required.
With Nylas Agent Accounts (in beta), the agent owns the mailbox where this accrues, and you never parse headers by hand. The Threads API groups messages by their header chain; each thread object gives you ordered message_ids
, participants
, and activity timestamps. When a reply fires message.created
, the payload includes a thread_id
— fetch the thread, walk its messages, and the agent has its full conversational past before deciding anything. Tip from the docs: fields=include_basic_headers
fetches just the three threading headers when you need them raw, skipping a header payload that's often larger than the message body.
One tempting shortcut deserves a warning. Plenty of implementations match replies by subject: if it starts with Re:
and contains the original subject, it must be a reply. The threading docs list exactly how that breaks. Recipients edit subjects — "Q3 budget review" comes back as "Re: Q3 budget review — updated numbers attached." Two prospects receive the same "Following up on your demo request," and a reply to either matches both. A forwarded thread keeps its subject while losing its conversational context entirely. Headers reference specific Message-IDs, not human-editable text; match on them first, and treat subject matching as a last-resort fallback for ancient mail clients.
The write side is symmetric and just as automatic: pass reply_to_message_id
on the send and Nylas populates In-Reply-To
and References
for you, so the reply threads correctly in every recipient's client. Better still, the memory works across access paths. If the agent sends through the API and a human supervisor later replies from Apple Mail over IMAP, everything stays in one thread, because grouping follows the header chain rather than the send mechanism. One transcript, multiple writers.
Now the honest limitation, which the docs are upfront about: the thread is episodic memory, not working memory. It knows the words exchanged. It doesn't know which task the agent was on, which workflow step, which ticket. That mapping lives in your application:
// On outbound: bind the thread to internal state.
threadState.set(sentMessage.threadId, {
taskId: currentTask.id,
step: "awaiting_reply",
});
// On inbound webhook: restore context, or treat as new.
const context = threadState.get(inboundMessage.threadId);
if (context) await resumeTask(context.taskId, inboundMessage);
else await triageNewMessage(inboundMessage);
In production that map belongs in Postgres or Redis, not memory — conversations span days, and an in-memory map doesn't survive a deploy. So the architecture is two layers: the thread holds the durable transcript, your store holds a thin pointer from thread_id
to agent state. The heavy content lives in the mailbox; you persist only the index.
Persistence cuts both ways: threads come back from the dead. The multi-day support agent recipe treats revival as a first-class case with concrete policies worth stealing:
That last one captures the design mindset: a chatbot architecture asks "is the session alive?" A mailbox architecture asks "what does this silence mean?" — a genuinely richer question.
The fair counterargument: email is slow and threads are noisy. Latency is measured in minutes to days, quoted text and signatures pollute the transcript you feed the model, and a CC'd third party can wander into the "memory" mid-conversation. For interactive flows — debugging a config live, navigating a UI — chat's immediacy wins, and nothing here argues otherwise.
But most agent work that matters commercially isn't interactive. Support, scheduling, procurement, follow-ups — these are inherently asynchronous, multi-day processes, and forcing them into session-shaped memory is why so many "AI assistants" forget you between Tuesday and Friday. Match the memory model to the conversation's natural tempo.
A concrete way to test the idea: take one workflow where your agent currently loses context between sessions, give it a mailbox, and store nothing yourself except the thread_id
→ state mapping. Run it for two weeks. My bet is the surprising part won't be the persistence — it'll be how much easier debugging becomes when you can read your agent's memory in an email client.