Support Threads That Span Days: Agent Memory via Email

Nylas has released a recipe for building multi-day support agents that use email threading headers as durable memory. By leveraging Message-ID, In-Reply-To, and References headers, the agent can maintain conversation context across days and process restarts. The pattern is implemented via Nylas Agent Accounts and webhooks, with thread_id serving as the persistent session identifier.

Most conversational state management assumes the conversation is happening — a chat session, a websocket, a context window. Email breaks that assumption rudely: a customer replies five days after your agent's last message, and your code is expected to pick up exactly where things left off, with no session, no socket, and a process that has restarted twelve times since. The good news: email already solved durable conversation tracking, decades ago, in three headers. Build on them properly and the thread itself becomes the agent's memory. This is the pattern behind the multi-day support agent recipe https://developer.nylas.com/docs/cookbook/use-cases/act/support-agent-multi-day-threads/ , which runs an LLM support agent on its own mailbox via Agent Accounts https://developer.nylas.com/docs/v3/agent-accounts/ — currently in beta. Every email carries a globally unique Message-ID . A reply adds In-Reply-To the Message-ID being answered and References the full chain of Message-IDs, oldest to newest . That's how Gmail, Outlook, and Apple Mail all decide what belongs to one thread — subject-line matching is only a fallback, and the email threading docs https://developer.nylas.com/docs/v3/agent-accounts/email-threading/ explain why relying on it breaks: recipients edit subjects, two prospects can receive identical subjects, and forwards keep the subject while changing the conversation entirely. You don't manage these headers yourself. Pass reply to message id on a send and the platform populates In-Reply-To and References automatically: curl --request POST \ --url "https://api.us.nylas.com/v3/grants/<GRANT ID /messages/send" \ --header "Authorization: Bearer <NYLAS API KEY " \ --header "Content-Type: application/json" \ --data '{ "reply to message id": "<MESSAGE ID ", "to": { "email": "alice@example.com" } , "subject": "Re: Trouble accessing my account", "body": "Thanks for the extra detail, Alice — here is what I found..." }' The reply threads correctly in the recipient's client and lands in the same thread in the agent's own mailbox. When a reply arrives, the message.created webhook payload includes thread id . That's the durable session identifier. The pattern from the docs: thread id mapped to your internal state — ticket record, workflow step, whatever the agent was doing. thread id . Found it? Restore context and continue. Didn't? It's a brand-new conversation — classify and route it.The dispatch logic at the top of the webhook handler is short, but every line is a guard that earns its place: js app.post "/webhooks/support", async req, res = { res.status 200 .end ; const event = req.body; if event.type == "message.created" return; const msg = event.data.object; if msg.grant id == SUPPORT GRANT ID return; // Skip messages the agent itself sent. if msg.from?. 0 ?.email === SUPPORT EMAIL return; // Deduplicate — webhook delivery is at-least-once. if await db.alreadyProcessed msg.id return; await db.markProcessed msg.id ; // Reply to an existing ticket, or a brand-new conversation? const ticket = await db.tickets.findByThreadId msg.thread id ; ticket ? await handleFollowUp msg, ticket : await handleNewTicket msg ; } ; The self-sent check matters more than it looks: the agent's own replies land in the same mailbox and fire the same trigger. Without that guard, the agent treats its own answer as a customer follow-up and responds to it — an email-based feedback loop you'll discover via a very confused customer. The lookup table must live in a database, not memory. Support threads span days; in-memory maps don't survive deploys. When a dormant thread revives, the agent re-reads the whole conversation through the Threads API: each thread object carries an ordered message ids list, the participants, and last-activity timestamps. Fetch the messages, sort by date, label each as agent or customer, and feed the transcript to the LLM for reclassification — not just reply generation. The recipe is insistent on this: a conversation that opened as a general question often turns into a billing dispute by message two, and routing should adapt. The recipe also hard-codes lifecycle guards around the LLM: A support agent that confidently sends a wrong billing answer is worse than one that says "let me get a human." When the agent does hand off, it should pass the human everything it knows — the ticket category, the turn count, the escalation reason, and a pointer to the thread — so the human doesn't re-read the conversation from scratch. The recipe marks the ticket escalated in the store, and the follow-up handler checks that status first: once a human owns a thread, the agent stays out of it. The handoff mechanism itself is pleasingly low-tech. Because an Agent Account is a real mailbox, the human team can connect to it over IMAP from Outlook or Apple Mail and read or answer the escalated thread directly. The API and IMAP share the same mailbox, so if the ticket is later de-escalated, the human's replies are right there in the thread history the agent rehydrates. Two operational numbers from the recipe worth tracking from day one: And log everything: the classification result, the confidence score, and the generated reply for every interaction. Support emails are auditable communications; don't ship an agent that talks to customers without an audit trail. Mostly you won't — thread id is more stable for application logic than Message-IDs, since the platform assigns it and it spans the whole conversation. But when you need the chain itself, pass fields=include basic headers on a message GET to receive just Message-ID , In-Reply-To , and References without the full header payload, which is often larger than the message body. One more design note: don't assume one reply per outbound. Two people on a thread can both respond, and your agent shouldn't double-reply to the same thread because two webhooks fired. Build the minimal loop — send, store thread id , reply to yourself from a personal account, watch the webhook restore context — then kill your process between the send and the reply. If the agent still picks up the conversation after a restart, your memory model is real. If it doesn't, you've found the bug before a customer did. How long do conversations in your domain go quiet before they come back?