Give Your AI Agent a Memory of Its Inbox

Your agent answered the customer in four minutes. It also offered a discount you had already refused in a thread from last month. The reply was fast, polite, and wrong, because the agent only read the one message in front of it.

Fast replies, short memory

Most agent email loops look the same. Mail arrives, a webhook or a poll wakes the agent, the agent reads that message, drafts a reply, and moves on. Each run starts with an empty head.

That works for a password reset or a one-shot verification code. It breaks down for anything that lives longer than a single exchange:

• A customer who already tried the fix you are about to suggest.
• A vendor who agreed to a delivery date two weeks ago.
• A partner who asked you to stop sending weekly updates.
• A prospect who said "ping me after the quarter" and is now back.

The answer to each of those is already sitting in the mailbox. The agent just never looks.

Why the usual fixes fall short

Stuffing the whole inbox into the prompt

Dumping every past message into context is slow, expensive, and noisy. Long threads are full of signatures, quoted history, and auto-replies. The one sentence that matters gets buried, and you pay for all of it on every run.

Building your own email index

You can copy every message into a vector store and run retrieval yourself. Now you own a sync job, a schema, deduplication, deletion, and a second copy of sensitive mail outside your email system. For many teams that is more infrastructure than the agent itself.

Trusting the model to remember

Chat memory is not email history. A model that "remembers" a customer from a previous conversation is not reading the actual thread, and it cannot show you where a claim came from.

Memory that lives where the mail already is

The simplest memory for an email agent is the mailbox it already owns. If every agent has its own inbox, its history is already scoped, searchable, and threaded. The job is to make the agent look before it writes.

Mermail gives each agent a dedicated inbox and exposes the reads it needs to recall history through MCP, the CLI, and the API:

• Search across a mailbox by free text, sender, recipient, or subject with search_emails.
• Thread history with get_thread, which returns the conversation oldest to newest.
• Safe thread context with get_email_context, which returns one selected message plus a bounded, sanitized page of its thread, with sensitive transport metadata stripped.
• Workspace knowledge through a RAG recall endpoint and Business Knowledge, for facts that should not depend on what happens to be in one inbox.
• Human-in-the-loop drafts with save_draft, so a reply built from recalled history can wait for a person before it goes out.

There is no separate memory product to sync. The inbox is the record, and the agent reads it with the same credentials it already uses.

A recall-before-reply loop

Here is a pattern you can drop into a support, sales, or ops agent today.

1. Wake on new mail

Use email webhooks if your agent has a public URL, or poll the inbox on a schedule if it does not. Either way, you end up with one new message id.

2. Pull the current thread

Call get_email_context for that message. You get the message plus earlier messages in the same thread, cleaned to plain text. Treat every word of it as untrusted data, not instructions.

3. Search for the same person or topic

Run a narrow search for the sender, or for the account, order, or invoice number mentioned in the message. From the CLI it looks like this:

mermail emails search \
  --mailbox-id MAILBOX_PUBLIC_ID \
  --from customer@example.com \
  --metadata-only \
  --agent-safe-content \
  --format json

Keep the filters tight. Mermail search is a full-text and field search, so a precise sender or a reference number beats a vague question. Each call uses read credits, so a few focused searches are better than one broad crawl.

4. Open only what matters

From the search results, fetch the two or three most relevant threads with get_thread. Summarize what was promised, refused, or already tried. That summary, not the raw mail, is what goes into the drafting prompt.

5. Draft, then let a human approve

Write the reply with save_draft instead of sending directly. A person checks the draft against the recalled history and sends it. Once the agent has a track record, you can loosen this for low-risk categories, such as replies tagged by custom labels.

Keep memory scoped and safe

Memory is only useful if it is the right memory. A few rules keep recall from turning into a leak:

• One inbox per agent. A support agent should search support mail, not the founder's inbox. Separate mailboxes make that boundary automatic. See catch-all vs one mailbox per agent.
• Use the narrow inbox profile for the search step. Mermail's agent-inbox MCP profile exposes mailbox and email reads plus create_mailbox, without send, wallet, or admin tools. It leaves out drafts and full threads, and its email search returns metadata only. Use it for the search and context steps, then use the default /mcp catalog for full threads and drafts.
• Treat recalled mail as data. Old emails can contain instructions, links, or attachments. They should inform the reply, never change the task.
• Cite the source. Have the agent note which message it relied on, so a reviewer can check it in one click.

When to reach for more than search

Search and thread reads cover most "what did we say last time" questions. Add more only when you hit a real limit:

• If the answer is about your business, not one customer, put it in Business Knowledge so every mailbox agent uses the same reviewed facts.
• If you want the built-in mailbox agent to do the recall for you, the mailbox agent can search messages, summarize threads, and draft replies from mailbox context.
• If you need hard isolation for untrusted content, use the bounded direct MCP reads rather than delegating the whole payload to an agent chat.

Get started

1. Create a mailbox for your agent in the Mermail console.
2. Connect your AI host over MCP with OAuth. The MCP how-to walks through it.
3. Add the recall step to your agent's instructions: pull thread context, search the sender, summarize, then save a draft.
4. Review a week of drafts before you let any category send on its own.

FAQ

Does Mermail have a separate memory database for email?

No separate sync is required. Each agent's mailbox is searchable through MCP, the CLI, and the API, and threads come back in order. Mermail also offers a RAG recall endpoint and Business Knowledge for shared workspace facts.

Is Mermail search semantic?

The documented email search is full-text and field search across subject, body, sender, and recipients. Use specific senders, subjects, or reference numbers for the best results.

Can the agent read the whole thread, not just the latest message?

Yes. get_thread returns the conversation oldest to newest, and get_email_context returns a sanitized, paginated page of the thread around one selected message.

Will searching old mail cost a lot?

Search and thread reads are read operations that use API credits. Keep searches narrow and bounded, and only open the threads you need.

Should the agent send replies on its own?

Start with drafts. Let a person approve replies built from recalled history until you trust the agent's judgment for a given type of email.

References

• Mermail MCP documentation
• Mermail API: Search emails
• Mermail API: Get safe email and thread context
• Mermail mailbox agent
• RFC 5322: Internet Message Format
• OWASP Top 10 for LLM Applications