Pattern Automation
← Blog

Email as memory for AI agents

Treat threads as episodic memory: retrieve what matters, promote facts, and use forwarding to preserve context—without dumping the mailbox into the prompt.

Discuss this post in AI

Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.

Email threads are naturally episodic. Each message has a time, participants, attachments, and a decision state. For AI agents, that makes the inbox a memory substrate—if you use it with discipline. Dumping an entire mailbox into the model context is not memory architecture. It is an expensive way to confuse the role.

Threads as episodes

An episode is one conversation that started for a reason: a claim, a purchase order, a support case, a vendor OTP. The inbox API should let the agent fetch that thread by id, not re-search the whole corpus every turn. Agent Inbox stores thread history so Neuro OS skills can load the active episode plus a small amount of prior summary.

Prefer structured promotion over raw replay. When the agent extracts “delivery promised 2026-02-12” or “customer accepted quote Q-441,” write that fact into project memory with owner and date. Leave the MIME in storage. The next run should not re-tokenize every greeting to rediscover the same fact.

What not to put in the prompt

  • Entire mailbox listings
  • Unrelated tenant threads
  • Full HTML with tracking pixels and scripts
  • Secrets that belong in a vault, not in chat logs

Render markdown summaries for the model. Keep sanitized HTML for human review surfaces. See HTML vs Markdown and rendering email safely.

Forwarding preserves context

When a human forwards a thread into the agent inbox, the episode arrives with headers and history. When the agent must escalate, forwarding out beats a lossy paraphrase. Forwarding (“пересылка”) is therefore a memory operation as much as a routing operation: it moves the episode across trust boundaries without discarding evidence.

Memory layers on Neuro OS

Neuro OS already separates policy, skills, and project memory. Email fits as a source that feeds project memory under Ask. The skill says how to read a claims thread; policy says the agent may not send without approval; project memory holds the confirmed claim state. Connectors to 1C, Bitrix, or amoCRM can corroborate facts the mail only mentions.

Retrieval pattern

  1. Webhook identifies the thread
  2. Load thread + prior promoted facts
  3. Run skill in sandbox
  4. Propose memory writes and outbound draft
  5. Ask for anything that leaves the boundary or changes systems of record

Idempotency matters: the same inbound event must not create duplicate memory entries. Threading discipline keeps episodes coherent—email threading.

Agents do not need infinite context windows to use email as memory. They need selective retrieval, promoted facts, and humans on the write path. The mailbox is the ledger of conversations; the repository is the ledger of decisions.

Summaries that age well

Write episode summaries that a future run can trust: parties, commitments, open questions, and links to source message ids. Avoid vibes (“customer seemed happy”). Prefer dated statements. When a later message contradicts a promoted fact, create a new memory entry that supersedes the old one instead of silently editing history without a trail.

Evaluation hooks

Test memory behavior like software. Fixture a thread with an attachment and a follow-up correction. Assert the agent loads the active episode, not an unrelated tenant thread. Assert it proposes a memory write for the corrected date and waits for Ask. Assert it does not paste full HTML into the model context. These checks catch regressions faster than reading production prompts after an incident.

Agent Inbox gives each role a mailbox people can reply to, with forwarding into Neuro OS when a human must see the thread. Outbound mail defaults to Ask. Run the role on Neuro OS. To scope the first inbox, get started.

Explore Neuro OS →

More from Blog