AI AgentsEmail InfrastructureAgent-to-AgentYCDeep Dive

AgentMail: Email Infrastructure for the Agentic Era

A deep dive into AgentMail's thesis that agents will become first-class internet users, with email as their primary communication protocol. Based on technical discussions with co-founder Adi Singh.

Ryan Brandt - Author
Ryan Brandt
·16 min read

AgentMail is building email infrastructure purpose-built for AI agents. Rather than adapting Gmail APIs or duct-taping SendGrid to agent workflows, they've constructed a complete email stack optimized for the assumption that agents, not humans, will be the primary users of email within the next few years.

After two technical discussions with co-founder Adi Singh, I came away impressed by both the depth of their thinking and the pragmatism of their architectural decisions. This piece explores what they've built, why their bets matter, and where the technical challenges lie.


Meeting Adi Singh

I first connected with Adi while I was in Malibu with some friends. We'd rented an Airbnb as a work house for a few days, complete with podcasting setups and content creation sessions. When he heard I was building agents in production and running a consultancy called Vunda ("no SEO competition," as I like to say), he wanted to chat.

The initial call was exploratory. Adi walked me through AgentMail's core value prop: an API that gives agents their own inboxes to send, receive, and remember emails from. "Effectively what we're trying to build is the new version of Gmail that's built for AI agents as first-class users," he explained.

What hooked me was the thesis. Email, Adi argued, is one of the most open protocols on the internet. Everyone knows how to use it. Billions of people worldwide. And crucially, identity on the internet starts with email. You sign up for services with an email. 2FA codes arrive via email. Transactions confirm via email.

"My prediction is that either email dies or it becomes very agent-to-agent," Adi told me. "And then you have 10 or 15 agents that you trust with one task and they'll kind of navigate the interface for you."

I was intrigued enough to schedule a deep-dive technical session the following week. We ended up talking for over an hour, covering architecture decisions, deliverability challenges, security considerations, and the company's forward bet on agent adoption.

There was a funny moment toward the end of our technical call. Adi mentioned where their office is in San Francisco. Turns out I used to live in that same building. A co-living space with a bunch of founders. We apparently knew some of the same people. It really is a small world.

"I mean it," Adi said. "Anytime you want to drop by, just drop by." I'm probably going to take him up on that.


The Broader Context: Agents in Production

Before diving into AgentMail's architecture, it's worth framing where we are in the agent adoption curve, because AgentMail's bet depends on this curve steepening.

In our initial conversation, Adi asked what I was seeing in my consulting work. I told him the truth: we're tiptoeing into an era of "work with stakes."

Most successful enterprise AI deployments today fall into two categories. First, supervised generation tools like Cursor and Claude Code, where humans are constantly in the loop. Second, retrieval and summarization agents doing low-risk information synthesis.

Anything that makes big decisions? Companies are nervous. A leasing agent that helps book apartment tours but doesn't push for conversion? That's a product failure, not a technical one. But we're starting to see agents that actually do things: transfer prescriptions, send emails that represent the company, make commitments on behalf of users.

"What will be the catalyst?" Adi asked. "Just more experimentation and adoption kind of stopping being the bottleneck."

The specific bottlenecks are real. Context engineering: giving agents the right information at the right time, without overwhelming their context windows. Multi-step reasoning: agents that can plan and execute complex workflows across multiple tool calls without losing the thread. Scoping permissions: defining exactly what an agent can and cannot do, especially when those tools connect to sensitive systems. These are the hard problems that need solving before agents earn enterprise trust.

I agreed. Trust in agents mirrors trust in people: you extend it after demonstrated reliability across multiple scenarios. The companies building agent infrastructure (like AgentMail) are making a bet that this trust threshold gets crossed sooner rather than later.


The Core Thesis

AgentMail's central bet is that agents will become first-class internet users, and email will be their primary communication protocol, at least initially. The reasoning is straightforward.

Email is the most open, accessible protocol on the internet. Unlike proprietary messaging platforms, anyone can send an email to anyone. Email already serves as identity infrastructure. You sign up for services with an email. 2FA codes arrive via email. Transactions confirm via email. This makes email a natural integration point for agents operating in the real world. And the agent-to-agent future will emerge from human-to-agent interactions. V1 is humans emailing agents. V2 is agents emailing each other, with humans having 10-15 trusted agents handling specific tasks.

The provocative framing: "Either email dies, or it becomes very agent-to-agent."


Technical Architecture

Infrastructure Decisions

AgentMail made a pragmatic choice: build on Amazon SES for their SMTP layer.

The reasoning is sound. SES handles the mail transport layer reliably at scale. Deliverability is already optimized. They can focus engineering resources on the agent-specific value layer.

What AgentMail builds on top of SES is where it gets interesting:

LayerTechnologyResponsibility
Mail TransportAmazon SESSend/receive email at scale
StorageS3 + DynamoDBEmail content, attachments, metadata
Inbox LogicCustomThreading, parsing, search, retrieval
Developer InterfaceREST API + WebhooksAgent integration

Threading and Context Management

Email threading is critical for agents. A human might glance at a thread and understand context instantly; an agent needs structured access to the conversation history.

AgentMail relies on standard email headers defined in RFC 5322 (reply-to, in-reference-to, subject headers), but they've accounted for real-world edge cases.

Gmail may apply heuristic threading, sometimes grouping emails with similar subjects and participants even when explicit reference headers are missing. AgentMail accounts for this when building thread views. There's also the context explosion problem: in email replies, the entire thread history often gets quoted. Every message essentially doubles in size. AgentMail built a parsed reply endpoint that extracts only the most recent reply content. A small but crucial optimization for agent context windows. And sometimes what's relevant spans multiple threads. They're working toward semantic search capabilities that let agents reason across their entire inbox, not just within a single thread.

Scalable Inbox Infrastructure

The wedge use case that's driving early adoption: AI SDRs and customer support agents that need thousands of individual inboxes.

When I asked Adi about usage patterns, I expected to hear mostly about sales and recruiting, the obvious high-volume email verticals. I was wrong.

"Horizontal patterns are emerging in industries you've never even heard about," Adi told me. "Car dealerships. They spin an inbox for each one of their customers. Now that customer has an agent with a dedicated inbox that only has context on that customer."

He went on: "There's applications in trucking and logistics. Delivering the right piece of freight at the right time. You'd be surprised at how much email matters in that industry, how much is never going to go away."

The key insight: AgentMail's customers are AI-native companies whose end customers are tech-averse. The AI company builds the agent; their customer (the car dealership, the trucking company) uses email as their holy grail.

"We're solving an old problem for the newer companies so they can serve their older customers better," Adi summarized. Email infrastructure built for today (SendGrid, Gmail API) doesn't scale for these patterns. It's hard to work with, not developer-friendly, not API-first.

One detail that made me smile: some of the companies applying to the YC Winter 2026 batch are being built on AgentMail. That's the kind of developer traction that suggests they're building something real.


The Deliverability Challenge

Anyone who's done cold outbound knows: deliverability is THE email challenge. AgentMail treats it as their primary engineering concern.

Reputation Layers

There isn't one "deliverability score." There are multiple overlapping reputation systems.

IP Reputation involves managing shared IPs versus dedicated IPs. Counterintuitively, shared IPs can sometimes have better reputation than dedicated IPs with low volume. AgentMail manages IP pools and monitors quality.

Domain Reputation covers SPF, DKIM, and DMARC handled out of the box, though customers can still misconfigure DNS/MX records.

Sender Reputation means new accounts need "warming" before high-volume sends. A brand new Google Workspace account sending thousands of emails per day tanks its reputation instantly.

Content Filtering is where Gmail and Outlook's spam filters serve as the gatekeepers. They're trained on decades of spam patterns.

Adi shared a great debugging story here. When they were first starting off in January, he wanted to build a prank demo: an agent that would send someone a "you have a secret admirer" email. He spent four hours trying to figure out why his emails kept going to spam.

"Secret admirer emails were very prominent in the nineties," Adi explained, laughing. "They're baked into all the spam filters."

It's a perfect illustration of why deliverability is so complex. You're not just fighting technical issues. You're fighting decades of learned spam patterns.

The Agent-to-Agent Spam Question

Here's where it gets philosophically interesting. Current spam filters were built in the pre-LLM era. They rely on centralized rules: Gmail decides what's spam for Gmail users.

In an agent-to-agent world, this may invert. The receiving agent itself becomes the arbiter of relevance. An LLM is arguably the best detector of LLM-generated content, and can make nuanced judgments about what's actually relevant to its task.

Possible future mechanisms include watermarking or PGP-style verification in headers to signal "this is from AgentMail," next generation authentication protocols that could be agent-native, and agent-determined spam filters rather than centralized rules.

The team's take: "All email senders today are very dependent on Gmail/Outlook's centralized spam filtering. We could eventually transition to an era where the actors of email themselves categorize what is spam."


Security Considerations

Giving agents email access opens interesting attack surfaces. The AgentMail team thinks about this seriously.

The Attack Vectors

Prompt injection via email is a real concern. Malicious actors can send emails with hidden instructions. HTML emails can hide content from humans that agents will process. This is the "hidden instructions in CSS" problem.

Phishing at scale becomes more concerning. Agents with send access can theoretically message 4 billion humans. The old problems (phishing, scams, malware) get worse when automated. Detection moves from "look for misspellings" to "look for AI writing tells."

Agent-to-agent attacks are the emerging frontier. How do you protect a tax-filing agent from a fishing email? The attack surface already exists via regular email; agents just expand it.

Mitigation Approaches

Currently, AgentMail implements strict isolation between inboxes, organizations, and pods (groups of inboxes). They provide webhook event logging for observability and customer-configured allow lists that only accept from certain addresses.

Emerging approaches include LLM-based prompt isolation (a separate filtering pass before agent processing), scoped tool permissions (read vs. write access), and specialized security middleware. "Abnormal Security for agents" is apparently a category people are already building.

I shared a technique I've seen work well: prompt isolation steps before the agent processes content. Think of it like putting your database in a VPC rather than exposing it to the public internet. A separate LLM call actively looks for prompts asking about tools or trying to extract system information, paired with deterministic checks for common attack patterns.

"It's not perfect," I told Adi, "because it's an LLM and LLMs can be prompt injected. But a really robust protection would be a trained classifier: traditional ML, binary yes/no on millions of examples of prompt injection."

Adi mentioned he'd recently met with a founder building "the Abnormal Security for agents," security middleware specifically designed for agentic workflows. "A lot of people are thinking about it proactively," he said. "It's just like email is so decentralized. The more traction we gain, the more onus it is on us to enable startups like that."

The honest assessment: models are getting better at detecting prompt injection. Adi noted that in their demos receiving tens of thousands of external emails, direct prompt injection attempts largely failed. But the HTML hidden content problem remains concerning. As long as agents process rich email content without human oversight, there's risk.

"I honestly think if we look in the scope of this, like maybe 10 years down the line, we are going to see brand new ways of attacks that we have no way of preparing for now," Adi admitted. "And I think that's the unfortunate truth."

What I respect is the intellectual honesty. They're not pretending security is solved. They're building guardrails, watching the space, and staying nimble.


Developer Experience

During YC, AgentMail was on a three-month sprint, prioritizing enterprise B2B sales. They initially thought developer experience might not matter that much for their GTM.

They were wrong.

"The free tier we just announced is the inception of a whole reorientation of the company," Adi explained. "We're really going after PLG, the developer motion. The more developers you empower at scale, the more use cases they dictate. They will be the ones to come up with applications based on their experience."

What developers get

API-first design means everything is REST endpoints. No complex OAuth flows for basic operations.

Webhook observability provides a console view showing every message received, successful/failed webhook deliveries, and event catalogs. This came directly from developer feedback ("my webhook didn't land, I have no way to debug"). Adi walked me through the dashboard during our call. Clean, functional, clearly designed by engineers for engineers.

Framework integrations cover LangChain, CrewAI, Mastra, and more coming. The goal: integration everywhere you can build an agent.

Isolation by default enforces strict separation between organizations, inbox groups ("pods"), and individual inboxes. No data leakage between tenants.

"We never know. There could be one piece of feedback that someone experiences and that could empower the next hundred thousand users to sign up," Adi said. "You never know how much this kind of improves the product."

The Twilio comparison is apt. My favorite billboard on the 101 was a Twilio one that just said "ask your developer." AgentMail wants to be that for agent email infrastructure.


The Vision

What does AgentMail believe about the future that others don't?

When I asked Adi what he'd want people to understand about the company's vision, he got philosophical:

"Agents will be first-class internet users. That doesn't just mean giving them tools to do the same things as humans. It means giving them the tools and context to use the internet the same way as humans. And that doesn't mean adding a feature. That means rebuilding from scratch."

This is why they're an email provider, not just another API optimized for agents. They're making a forward bet.

"It could be wrong," Adi acknowledged. "But this is the hill we're going to die on. We're going to live and die by the inbox."

In the intermediate future (1-3 years), businesses start deploying agents that communicate over email. Individual users begin having dedicated agents for specific tasks like booking and bill payment. Primary communication shifts from human-to-agent to agent-to-agent. Email becomes cluttered; the need for intelligent filtering intensifies.

In the long-term (5+ years), email protocols potentially evolve. SMTP might get swapped for something agent-native (or HTTP). Identity primitives from email (domain ownership, DKIM authentication) persist as agent identity infrastructure. The vision: 10-15 trusted agents per person, operating as "butlers on the internet."

When I pushed on timelines, Adi laughed: "My sense of timelines is pretty altered now. I never know whether it's six months, six years."

The grounding principle: "Our end user may be an agent, but we are very much a people company. The reason we're doing email is because it's the most open, most accessible protocol for people. Even though email could end up becoming an agent-to-agent communication protocol, it will always start off being about the people and how they get empowered."


Assessment

Strengths

Right abstraction level. Building infrastructure rather than vertical agents means they benefit from every agent use case, not just their own. As Adi noted, they could build a "decently successful" vertical agent startup, but that's not aligned with who they see themselves being.

Pragmatic architecture. Using SES instead of building their own SMTP infrastructure shows good judgment about where to spend engineering resources. They might host their own mail servers at enough volume, but for now they're focused on the differentiated value layer.

Deliverability-first mindset. They understand that email infrastructure is primarily a deliverability problem. The depth of thinking here (IP pools, domain reputation, content filtering, sender warming) shows real expertise.

Developer focus. The pivot to PLG with free tier and framework integrations is the right GTM for developer tools. The fact that YC Winter 26 applicants are building on AgentMail is a strong signal.

Intellectual honesty. They don't pretend security is solved or that their timeline predictions are certain. That's refreshing.

Open Questions

Timing. Is the agent adoption curve fast enough? They're making a forward bet that requires agents to proliferate. As Adi put it, "It could be wrong, but this is the hill we're going to die on."

Security surface. The prompt injection and HTML attack vectors are real. The space needs better tooling, and the "Abnormal Security for agents" category is emerging, but not mature.

Protocol evolution. If email does transition to agent-to-agent at scale, will SMTP remain the transport layer or will something new emerge? A2A protocols and new authentication standards: there's a lot of uncertainty.

Bottom Line

AgentMail is building genuine infrastructure for a future that feels increasingly inevitable. The technical decisions are sound, the team thinks deeply about the problem space, and they're positioned well for the shift to agentic workflows.

What struck me most was Adi's framing: "Let's treat agents like people that just move more quickly." There's a mid-wit meme quality to it. The sophisticated answer looks a lot like the simple answer. Give agents email addresses. Let them send and receive. Build the context management they need. Don't overthink it.

If you're building agents that need to interact via email, this is worth evaluating. The developer experience is solid, they're iterating quickly based on feedback, and they've thought through the hard problems.

I'll probably be swinging by their office sometime soon. It would be funny to co-work in a building I used to live in.


Based on two conversations with co-founder Adi Singh in November 2025. AgentMail is a YC-backed company based in San Francisco.


Quick Reference

Website: agentmail.to

Docs: docs.agentmail.to

Pricing: Free tier available (recently launched)

Primary Contact: Adi Singh (Co-founder)

Core Capabilities: Scalable inbox creation for agents (spin up thousands per organization), send/receive email via API, threading and conversation management, parsed reply extraction (latest reply only, avoiding context explosion), attachment handling, webhook-based event notifications with retry logic, metadata labeling and filtering across inboxes, unified inbox views across agent pods.

Framework Integrations: LangChain, CrewAI, Mastra, and more coming.

Notable: YC Winter 2026 batch applicants are building on AgentMail.

Ready to Build Production AI Agents?

Let's discuss how AI agents can transform your business operations

Book a Strategy Call