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.
The protocol already built your memory layer
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.
