{"slug": "support-threads-that-span-days-agent-memory-via-email", "title": "Support Threads That Span Days: Agent Memory via Email", "summary": "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.", "body_md": "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.\n\nThe 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.\n\nEvery email carries a globally unique `Message-ID`\n\n. A reply adds `In-Reply-To`\n\n(the Message-ID being answered) and `References`\n\n(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.\n\nYou don't manage these headers yourself. Pass `reply_to_message_id`\n\non a send and the platform populates `In-Reply-To`\n\nand `References`\n\nautomatically:\n\n```\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/grants/<GRANT_ID>/messages/send\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"reply_to_message_id\": \"<MESSAGE_ID>\",\n    \"to\": [{ \"email\": \"alice@example.com\" }],\n    \"subject\": \"Re: Trouble accessing my account\",\n    \"body\": \"Thanks for the extra detail, Alice — here is what I found...\"\n  }'\n```\n\nThe reply threads correctly in the recipient's client and lands in the same thread in the agent's own mailbox.\n\nWhen a reply arrives, the `message.created`\n\nwebhook payload includes `thread_id`\n\n. That's the durable session identifier. The pattern from the docs:\n\n`thread_id`\n\nmapped to your internal state — ticket record, workflow step, whatever the agent was doing.`thread_id`\n\n. 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:\n\n``` js\napp.post(\"/webhooks/support\", async (req, res) => {\n  res.status(200).end();\n\n  const event = req.body;\n  if (event.type !== \"message.created\") return;\n\n  const msg = event.data.object;\n  if (msg.grant_id !== SUPPORT_GRANT_ID) return;\n\n  // Skip messages the agent itself sent.\n  if (msg.from?.[0]?.email === SUPPORT_EMAIL) return;\n\n  // Deduplicate — webhook delivery is at-least-once.\n  if (await db.alreadyProcessed(msg.id)) return;\n  await db.markProcessed(msg.id);\n\n  // Reply to an existing ticket, or a brand-new conversation?\n  const ticket = await db.tickets.findByThreadId(msg.thread_id);\n  ticket ? await handleFollowUp(msg, ticket) : await handleNewTicket(msg);\n});\n```\n\nThe 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.\n\nThe lookup table must live in a database, not memory. Support threads span days; in-memory maps don't survive deploys.\n\nWhen a dormant thread revives, the agent re-reads the whole conversation through the Threads API: each thread object carries an ordered `message_ids`\n\nlist, 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.\n\nThe recipe also hard-codes lifecycle guards around the LLM:\n\nA support agent that confidently sends a wrong billing answer is worse than one that says \"let me get a human.\"\n\nWhen 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`\n\nin the store, and the follow-up handler checks that status first: once a human owns a thread, the agent stays out of it.\n\nThe 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.\n\nTwo operational numbers from the recipe worth tracking from day one:\n\nAnd 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.\n\nMostly you won't — `thread_id`\n\nis 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`\n\non a message GET to receive just `Message-ID`\n\n, `In-Reply-To`\n\n, and `References`\n\nwithout the full header payload, which is often larger than the message body.\n\nOne 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.\n\nBuild the minimal loop — send, store `thread_id`\n\n, 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?", "url": "https://wpnews.pro/news/support-threads-that-span-days-agent-memory-via-email", "canonical_source": "https://dev.to/qasim157/support-threads-that-span-days-agent-memory-via-email-29oj", "published_at": "2026-06-13 11:21:59+00:00", "updated_at": "2026-06-13 11:47:21.888518+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "natural-language-processing"], "entities": ["Nylas", "Gmail", "Outlook", "Apple Mail"], "alternates": {"html": "https://wpnews.pro/news/support-threads-that-span-days-agent-memory-via-email", "markdown": "https://wpnews.pro/news/support-threads-that-span-days-agent-memory-via-email.md", "text": "https://wpnews.pro/news/support-threads-that-span-days-agent-memory-via-email.txt", "jsonld": "https://wpnews.pro/news/support-threads-that-span-days-agent-memory-via-email.jsonld"}}