The case for email as the context layer for agents - AgentNews #37
Agent News #037
- Product
- AgentMail
- Sent from
- newsletter.agentmail.to
- Sent
No dark-mode styles — this email renders the same in a dark client.
Agent News #037 Custom domains are now free. Your agent can send from your domain → ( https://www.agentmail.to/blog/custom-domains-free-plan?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Agent News Issue 037 · November 2026 ************************************************** The case for email as the context layer for agents ************************************************** Over the last week I went back through the most common and most interesting use cases our customers at AgentMail have brought us. Using the inbox and our multi-tenancy features as the context layer and the memory layer for outbound agents seems to be a more common use case than I thought. That got me thinking about how we handle context internally, and how we give our own agents context and memory. The answer, for us, is Notion. However, at scale and when the agents are mostly outbound facing, this can be disastrous. Hear me out. ------------------ Notion for context ------------------ Notion sliding in to become the context layer for agents was such a genius move. Every LLM and agent I run connects to the same shared Notion over MCP, a workspace I call Growth HQ. All of our pending and live GTM projects live there. Every time somebody makes a decision, something updates, or something gets rolled back, that Notion gets updated. Every time a new Claude instance needs to start from scratch, build a new feature for an existing workflow, or do something similar, they can query the same Notion and get the context. We use this cross-functionally as well. Everyone on our team has access to that page. Every time a session closes, the context survives. This is excellent, however, this is not the ideal way to preserve context and memory when there are thousands of agents that are facing external partners. -------------------- Where the wiki stops -------------------- But what happens when the agents need to interact with external parties at scale? The other day, on an onboarding call with a startup that does AI customer support, they had this exact setup. They had a fleet of agents that are communicating externally, spread out across multiple pods. The conversations now happen live, in a channel the wiki can't see easily. Someone has to copy it in afterwards. Usually that's a Zapier flow or an inbox AI that summarizes the thread into a Notion page. The summary is a problem. The PDF or attachments will have to stay behind, the figures get rounded, and ultimately important context goes missing. You don't want your note taker to be the judge of what nuance is important and what's not. If your agents are communicating with customers or vendors or external parties at scale, the best context layer or the memory layer is the inbox itself. That's the primitive that we have built AgentMail around. Turns out we have many customers that use AgentMail exactly in this capacity. However, if you're still stuck in the legacy patterns, let me point out where they might break. ----------------------------------------- What people do today, and where it breaks ----------------------------------------- I've seen four fixes, and none of them are bulletproof in a vertical where the whole business runs on email. 1. Pass a summary into the next agent's prompt Cognition's Walden Yan wrote the rule against this last year: "share full agent traces, not just individual messages." A summary carries what the first agent decided to write down. It can't carry the decisions the first agent made without noticing it had made them, and that is what the second agent misreads. 2. Make the CRM the record One integration per agent, and the customer never sees the record, so their correction still arrives by email. 3. Share a memory store Good for recall, weak on provenance. When Tencent shipped team-wide agent memory this year, VentureBeat's first question was whose memory wins when two agents write contradicting facts. You get a chunk back, not the thread or the attachment. 4. Adopt an A2A protocol We spoke about the state of A2A in the last newsletter. This is just overcomplicated and underadopted. Now look at the verticals where companies are putting agents in front of customers and vendors. We have customers that run on more than 100 emails per transaction or negotiation. And these conversations don't follow a strict template and are often very unstructured. For these businesses, the full scope of external communications is already email, so the inbox already has the context, sender, time, position in the thread, the attachments, and, if needed, the human on CC. Nothing really needs syncing. Let me paint some examples here. ------------------------------------------------- Scenario 1: the agent that negotiates in the dark ------------------------------------------------- Say a supplier deploys a quoting agent for its wholesale buyers. For one product line, it emails three stores and gets three different answers back: one asks for a spec sheet, one wants a lower minimum order, one accepts but attaches revised payment terms. A year later, a different agent picks up the same client. If all it has is the CRM, it starts from a one-line note or a summary. If it has the inbox and the thread ids, it reads the three threads, opens the attachment, and starts from what was actually agreed. Context is what the agent reads before it decides. Memory is the same thread, still there a year later. --------------------------------------- Scenario 2: two agents and one customer --------------------------------------- A company runs two agents: one answers support, one chases unpaid invoices. A customer emails support to dispute a charge. At the same moment, the billing agent is about to send that customer a second payment reminder. Both agents live in the same pod, so each can read the other's threads. The support agent opens the billing thread and sees the invoice and the customer's earlier note that their PO number changed. The billing agent opens the support thread, sees the dispute, and holds the reminder. Nobody built an integration between the two agents. They can read each other's mail. --------------------------------------------- Scenario 3: nobody can see what the fleet did --------------------------------------------- Scale the last two examples up. A company now runs twenty agents on email: quoting, support, billing, onboarding, collections, each with its own inbox. The question changes from "did this agent get it right" to "what did all of them do today, and where did one of them go wrong." The usual answer is to make every agent log to a dashboard or post a summary somewhere. The other answer is an orchestrator agent that reads the inboxes directly. Threads can be listed and searched per inbox, per pod, or across the whole organization in a single call, and any attachment can be pulled from any thread the key is allowed to read. The orchestrator doesn't need to own an inbox to do this. Claude, or any agent with the right key, can do it over the API or MCP. One query against the pod replaces polling twenty mailboxes. The same record is your audit log. Every message has a sender and a timestamp that no agent can change, and deleting a thread is a permission you can refuse to grant. When something goes wrong, you open the thread and see what the agent saw, in the order it saw it, including the file it acted on. Give the orchestrator a key with read permissions and no send permission, and it can watch everything without being able to send a word. -------------------------------------------------- Scenario 4: four hundred customers on one platform -------------------------------------------------- Everything so far assumed one company running its own agents. Now suppose you're the company selling those agents. You run the quoting agent, the support agent and the billing agent for four hundred customers at once, and every one of those customers needs its own inboxes, its own history, and a guarantee that nobody else can read it. That's what pods are for. Each customer gets a pod, and that customer's inboxes, domains, threads and drafts live inside it. A key scoped to one pod can't read anything outside it. Your own org-level key can read all of them, which is how you run the orchestrator from scenario 3 across every customer. Webhooks can be scoped to a pod too, so customer A's incoming mail never triggers customer B's agents. -------------------------------------------- Where the inbox might not be the best answer -------------------------------------------- Email is not the ideal tool for fast loops between your own agents, and for two agents editing the same file. Keep those inside the agent. If you need meaning-based recall across years of threads, put a memory layer on top and let it index the inbox. ------------- Where it does ------------- Most of what an external-facing agent does all day is a conversation with someone outside the company. Quotes, disputes, renewals, reorders, approvals. Every one of those conversations already lives in a thread, in full, with the attachment, the timestamp, and the other party's exact words. No summary, sync or protocol is going to reproduce that record better than the record itself. If your agents handle any of it, the inbox is already their context layer. The only question is whether they can query it. So give every agent its own inbox. Put the agents that work together in the same pod. Give the orchestrator read access to all of it. Then stop building summaries. Read the docs on pods and multi-tenancy → ( https://docs.agentmail.to/pods?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Spotlight AgentMail · New Custom domains are now free Your agent can send and receive as support@yourcompany.com on the Free plan, with the same API it uses for an agentmail.to inbox. This used to sit behind the $20 Developer plan. The address an agent writes from is the address a customer replies to, and that thread is the record. Worth putting on a domain you own from day one. • One custom domain, free, for sending and receiving • Automatic on Free accounts made from 4 November. Older ones can ask • DNS in a few clicks through Domain Connect on Vercel or Cloudflare Free sends carry a "Sent via AgentMail" footer. If the domain already runs mail, point it at a subdomain. Set up your domain → ( https://www.agentmail.to/blog/custom-domains-free-plan?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) AgentMail AgentMail now plugs into HydraDB This is the memory layer on top of the inbox that the editorial mentions. A Python connector copies inbox mail into HydraDB with thread and reply links intact, and re-syncs update by Message-ID instead of duplicating. The agent can then look up the price a customer agreed to weeks ago before it writes the reply. Read the announcement → ( https://www.agentmail.to/blog/agentmail-hydradb-integration?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) AgentMail Polling webhooks Push webhooks need an always-on public endpoint and websockets need a live connection. An agent in a sandbox, a serverless function or a cron job has neither. Polling webhooks let it pull its email events off a queue whenever it happens to be running. Built with Svix, in the Python and TypeScript SDKs. Read the announcement → ( https://www.agentmail.to/blog/introducing-polling-webhooks?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Startup Spotlight HydraDB The company behind that integration. HydraDB is an open source graph database built on object storage that links the context scattered across a company, decisions, docs, code and email, so an agent can follow the relationships instead of guessing at a chunk. hydradb.com → ( https://hydradb.com/?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Good Reads Online learning for cost-efficient LLM routing ( https://engineering.ramp.com/post/thompson-sampling-model-routing?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Ramp's gateway runs Thompson sampling over lognormal latency posteriors to pick a route per request, rather than pinning one model. Read it on engineering.ramp.com → ( https://engineering.ramp.com/post/thompson-sampling-model-routing?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Correctness and complexity ( https://pron.github.io/posts/correctness-and-complexity?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Why verifying what a program does is undecidable in general and intractable in most useful cases, so correctness carries a cost no tool removes. Read it on pron.github.io → ( https://pron.github.io/posts/correctness-and-complexity?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Upcoming Events Nov 18 Is Today's Infra Ready for Personal Agents? Wednesday 18 November · 17:00 to 20:00 PT San Francisco, CA · UpScaleX and TinyFish Register → ( https://luma.com/upscalex-71pp?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Nov 18 GTM Workflows in Practice: Roundtable and Dinner Wednesday 18 November · 18:00 to 20:00 PT San Francisco, CA Register → ( https://luma.com/29i0mwzf?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) AgentMail ( https://agentmail.to?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Docs ( https://docs.agentmail.to?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Get Started Free ( https://console.agentmail.to/sign-up?utm_source=agentmail_newsletter&utm_medium=email&utm_campaign=agent_news_037 ) Agent News is published by AgentMail. Unsubscribe ( https://track.customer.io/unsubscribe/dgS43QwDAKCYDJ-YDAGh0amNWFrfGHOKtwlejAs= )
- Accession
- nse/agentmail/2026-11-12/6838
- From
- Adi from AgentMail · adi@newsletter.agentmail.to
- Sent
- 12 November 2026 · 21:00 UTC
