Give your AI agent an email inbox with memory

Most email integrations for AI agents solve one problem: sending. Your agent composes a message, calls an API, and the email goes out. That works for notifications and one-off alerts. It falls apart the moment someone replies.

Connecting your agent to Gmail or Outlook introduces other problems. OAuth complexity, rate limits at scale, account bans for automated usage, and security risks: researchers have demonstrated how crafted emails can trick agents into leaking data through prompt injection in email content. Granting full inbox access to an AI agent exposes every message in the account.

An agent that can send but not receive is half-built. An agent that receives but forgets every conversation is barely better. To handle real email workflows, AI agents need a dedicated email inbox with persistent storage, automatic threading, and memory across conversations.

OpenClaw, the open-source AI agent platform with 300k+ GitHub stars, supports email integrations through MCP servers and skills. This guide shows how to give your OpenClaw agent a full email inbox with memory using Nuntly.

Send API vs email inbox: why the distinction matters

A typical email integration gives your agent an API to send messages. If a reply comes back, it arrives as a webhook payload. Once consumed, the payload is gone. You can build your own ingestion layer to store webhook payloads, but that is extra infrastructure to maintain, and it still gives you raw events without threading or conversation context.

An inbox is different. It is a dedicated email address (support@yourdomain.com) that stores every message persistently. Replies are linked to their original conversation automatically. Your agent can query past messages, load conversation history, and build context before responding.

The distinction is structural. With a send-only integration, your agent treats email as a fire-and-forget channel. With an inbox, email becomes conversational. With memory, your agent becomes genuinely intelligent.

Real email workflows are multi-turn. A customer writes in, your agent responds, the customer asks a follow-up three days later. Without an inbox, your agent has no idea what the previous exchange contained. Without memory, it cannot recall context from earlier conversations on the same thread.

How Nuntly email inboxes work

Nuntly's Receiving API provides four building blocks for agent email.

Inbox: a dedicated email address that your agent owns. Every inbound message is stored in full: headers, plain text body, HTML body, and attachments. Your agent receives a lightweight webhook notification with metadata (sender, subject, thread ID) and calls the API to fetch the full content when needed. No MIME parsing.

Thread: Nuntly reads the In-Reply-To and References headers defined in RFC 5322 and links replies to their original conversation automatically. Your agent gets the full conversation history without managing state.

Agent memory: persist context across conversations at three scopes.

Your agent does not need an external database to remember what happened. Memory is built into the platform.

Reply API: send replies programmatically from the inbox address, linked to the original thread. The conversation stays in one place through both the API and the Nuntly dashboard.

When a message arrives in an agent-assigned inbox, Nuntly fires a message.agent_triggered webhook event. Your agent handler is invoked automatically.

Setting up Nuntly with OpenClaw

OpenClaw supports MCP servers natively. Nuntly provides an MCP server that exposes the full platform API to your agent.

1. Create a Nuntly account

Sign up at nuntly.com/signup. The free plan includes 3,000 emails/month with full inbox and memory support. No credit card required.

Create an API key from the dashboard or use the Nuntly Copilot to generate one in seconds.

2. Configure the MCP server

Add the Nuntly MCP server to your OpenClaw configuration (~/.openclaw/openclaw.json):

{
  "mcpServers": {
    "nuntly": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@nuntly/sdk-mcp@latest", "--tools=dynamic"],
      "env": {
        "NUNTLY_API_KEY": "your-api-key"
      }
    }
  }
}

Restart OpenClaw. The Nuntly MCP server provides tools for managing domains, inboxes, messages, and memory directly from your agent.

3. Configure your domain for receiving

Add your domain and configure DNS records following the setup guide. Once your domain is verified, emails sent to your domain land in your agent's inboxes.

4. Create an inbox

Ask your OpenClaw agent:

"Create an inbox called support on my domain example.com using Nuntly"

Or create it programmatically:

import { Nuntly } from '@nuntly/sdk';

const nuntly = new Nuntly({ apiKey: process.env.NUNTLY_API_KEY });

const inbox = await nuntly.inboxes.create({
  address: 'support',
  domainId: 'dns_01jk8a3f7v0x9qr2mn4p6b5t8w',
  name: 'Support Agent',
  agentId: 'openclaw-support-agent',
});

// Initialize inbox memory with agent instructions
await nuntly.inbound.agents.memory.upsert({
  scope: 'inbox',
  inboxId: inbox.id,
  data: {
    instructions: 'You are a customer support agent for Acme Corp. Be concise and helpful. Escalate billing issues to the billing team.',
  },
});

5. Subscribe to webhook events

Configure a webhook endpoint to receive message.agent_triggered events. When a message arrives, Nuntly notifies your handler with the message metadata.

Building a conversational agent with memory

Here is a complete pattern: receive an email, load inbox and thread memory, process with an LLM, reply, and persist the updated context.

import Anthropic from '@anthropic-ai/sdk';
import { Nuntly } from '@nuntly/sdk';

const anthropic = new Anthropic();
const nuntly = new Nuntly({ apiKey: process.env.NUNTLY_API_KEY });

export async function handleInbound(event: { messageId: string; from: string; subject: string }) {
  // 1. Fetch full message content
  const content = await nuntly.inbound.messages.content(event.messageId);

  // 2. Load inbox and thread memory
  const inboxMemory = await nuntly.inbound.agents.memory.get({
    scope: 'inbox',
    inboxId: content.inboxId,
  });
  const threadMemory = await nuntly.inbound.agents.memory.get({
    scope: 'thread',
    threadId: content.threadId,
  });

  // 3. Process with your LLM
  const response = await anthropic.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 1024,
    system: inboxMemory?.instructions ?? 'You are a helpful customer support agent.',
    messages: [
      ...(threadMemory?.history ?? []),
      {
        role: 'user',
        content: `From: ${event.from}\nSubject: ${event.subject}\n\n${content.text}`,
      },
    ],
  });

  const reply = response.content[0].text;

  // 4. Send the reply
  await nuntly.inbound.messages.reply(event.messageId, {
    subject: `Re: ${event.subject}`,
    html: `<p>${reply}</p>`,
  });

  // 5. Persist thread context (summarize to keep memory compact)
  await nuntly.inbound.agents.memory.upsert({
    scope: 'thread',
    threadId: content.threadId,
    data: {
      history: [...(threadMemory?.history ?? []), { role: 'assistant', content: summarize(reply) }],
    },
  });
}

Five steps: fetch, load inbox and thread memory, process, reply, persist. The summarize() call in step 5 keeps thread memory compact as conversations grow. Your implementation can truncate, summarize with an LLM, or extract key facts. No external database, no state management code, no MIME parsing.

The three memory scopes serve different purposes in practice:

• Global memory stores rules that apply everywhere. Your agent's tone of voice, product knowledge base, or escalation thresholds.
• Per-inbox memory stores context tied to a specific address. If billing@ handles a different customer segment than support@, each inbox maintains its own state.
• Per-thread memory stores the conversation itself. Summaries of previous exchanges, extracted data points, or decisions that carry across replies.

Use cases

These patterns work for any OpenClaw agent that needs to send, receive, and remember email conversations.

Customer support automation

A ticket arrives at support@yourdomain.com. The agent generates a response and replies within seconds. Three days later, the customer writes back with a follow-up. The agent loads thread memory and picks up where the conversation left off. No repeated questions. No "could you remind me of your issue?"

Lead qualification

Inbound inquiries land on sales@yourdomain.com. The agent extracts company size, use case, and budget signals from the email body and stores them in per-thread memory. After two or three exchanges, it has enough context to score the lead and route it to the right sales rep with a full conversation summary.

Document processing

Invoices, purchase orders, and contracts arrive by email. The agent extracts structured data (amounts, dates, line items) from attachments and email bodies, stores the extracted fields in memory, and replies with a confirmation. If a required field is missing, it asks a follow-up and remembers the partial extraction.

Onboarding sequences

A new user signs up. The agent sends a welcome email, then adapts the follow-up based on replies. If the user responds with a question about pricing, per-thread memory captures this signal. The next email focuses on plan details instead of the generic onboarding flow.

Multi-agent coordination

Support, sales, and billing each get their own inbox with isolated memory. support@ handles technical questions. billing@ handles payment issues. Each agent maintains its own context without cross-contamination. Nuntly emits webhook events at every step (message.received, message.agent_triggered, message.sent), so you can monitor the full flow from your existing observability setup.

Scaling with namespaces

Namespace: a logical group of inboxes with an optional externalId. Namespaces let you isolate and route emails by tenant, team, or agent cluster.

For SaaS platforms, provision one namespace per customer. Each customer gets isolated inboxes with their own agent assignments and memory scope.

const namespace = await nuntly.namespaces.create({
  name: 'Acme Corp',
  externalId: 'customer_123',
});

await nuntly.inboxes.create({
  address: 'support',
  domainId: 'dns_01...',
  name: 'Acme Support',
  namespaceId: namespace.id,
});

Query all messages for a specific tenant with a single API call. Scale from one agent to hundreds without inbox collisions.

From stateless to conversational

Most email integrations stop at sending. With a dedicated inbox, your agent receives every message with persistent storage built in. With threading, it follows conversations across replies. With memory, it builds context over time.

"I'm actually mapping out a white-labeled support desk for niche agencies. Since you guys launched Namespaces, it looks like a perfect solution for multi-tenant isolation. I'm particularly interested in how your Agent Inboxes can reduce churn for agencies by automating the first touch." Danny, on Nuntly Discord

Receiving is available on all Nuntly plans, including the free tier (3,000 emails/month). Every inbound and outbound message is visible in the Nuntly dashboard with full event timelines, so you can debug your agent's email flow the same way you debug your transactional sending.

Ready to give your OpenClaw agent its own inbox? Sign up for free (no credit card required), install the Nuntly MCP server in OpenClaw, and create your first inbox. The full Receiving guide covers everything from MX setup to agent configuration.

Troubleshooting

MX records not propagating. DNS changes can take up to 48 hours. Use dig MX yourdomain.com to check propagation status. Nuntly's domain dashboard shows verification progress in real time.

Webhook endpoint not reachable. Your endpoint must be publicly accessible and return a 200 status code. Test with a tool like webhook.site before configuring in Nuntly. All webhook events support event replay, so you can re-deliver missed events after fixing your endpoint.

Agent replies landing in spam. Make sure your domain has valid DKIM, SPF, and DMARC records configured. Nuntly generates these automatically during domain setup. Sending replies from the same domain that received the inbound message improves deliverability.

Frequently asked questions

Do I need a separate domain for receiving?

No. You can use the same domain you already use for sending. Nuntly handles both directions from the same domain configuration.

What happens to emails that don't match any inbox?

Every domain has a default catch-all inbox (*) that captures anything not matched by a specific address. You can retrieve these messages through the API or configure a webhook to handle them.

Can I use Receiving without an agent?

Yes. Agents are optional. You can receive and retrieve messages through the API without any agent configuration. Many teams use Receiving purely to store inbound messages and query them programmatically.

How does threading work across sending and receiving?

When a customer replies to an email you sent, Nuntly uses the standard In-Reply-To header (RFC 5322) to link their reply to the original thread. The thread contains both directions of the conversation.

Can I run different agents for different inboxes?

Yes. Each inbox has its own agent assignment. You can run a support agent on support@, a sales classifier on sales@, and leave billing@ without an agent. All within the same domain.

Is agent memory shared between inboxes?

Only global memory is shared. Per-inbox memory is isolated to a single inbox, and per-thread memory is isolated to a single conversation. This prevents context from leaking across different agent responsibilities.