Why I'm Building Email for AI Agents

I've been thinking a lot about what AI agents are still missing.

Not intelligence. Not model quality. Not frameworks. Those are moving fast.

What's still missing is infrastructure that makes agents feel like real participants in software systems.

Email is one of those missing primitives.

If you want an agent to actually do useful work in the real world, eventually it needs an inbox. It needs to send reminders, receive replies, react to incoming messages, and operate with a real identity instead of faking everything through a human's Gmail account.

The moment it really hit me was when I was trying to set up email for my OpenClaw agent, Hal. I used the gogcli skill, which is the standard way to give an OpenClaw agent Gmail access. Even then, it was a pain. Setting up OAuth credentials in Google Cloud Console, downloading JSON files, running auth commands, creating a separate Gmail account so Google doesn't flag your agent as suspicious and ban it. All just so an agent could send and receive a few messages.

That's when I realised I wanted to build the infrastructure that makes agents actually useful. Email felt like the most obvious place to start.

So I started building Robotomail.

The name clicked right away. It's immediately legible, it sounds like what it does, and it has a slightly playful, developer-friendly feel. And yes, there's a little Google Roboto / Mr. Roboto energy in there too 😄

The core idea

Robotomail gives an AI agent a real email address it can use programmatically.

Not "send this via my Gmail plugin". Not "hack around IMAP and SMTP". Not "pretend to have inbox access".

A real mailbox. Send, receive, reply in threads, react to inbound events through webhooks or SSE, use a hosted address or a custom domain.

In other words, email becomes a native primitive in an agent workflow.

That sounds obvious once you say it out loud, but it's surprisingly awkward with the current tooling stack.

Why this matters

A lot of agent products still break down the second they need to interact with the outside world in a durable way.

They can call tools. They can classify text. They can generate drafts. But they often don't have a clean, first-class interface to an actual communication channel that humans already use every day.

Email is still one of the most important coordination layers on the internet. Support requests, follow-ups, booking confirmations, receipts, client communication, reminders. It all happens in email.

If you're building agents to do useful work, eventually they need to participate in that layer directly.

That's the gap Robotomail is trying to close.

What I wanted the product to feel like

I didn't want to build yet another generic email API. There are already solid ones for humans and applications.

What I wanted was something designed around the way agents actually operate. The agent needs a real inbox, not just outbound sending. It needs real-time events so it can wake up immediately when a message arrives, not poll on a timer. And critically, it should be able to do useful work without being given access to a founder's personal Gmail account. That's a much better abstraction.

The workflow that made it real for me

The moment this stopped being a neat idea and started feeling real was when I wired it end to end for my own assistant, Hal.

The flow looked like this:

An email arrives at [redacted]@robotomail.co
Robotomail emits a real-time event
The listener picks it up over SSE
That event gets forwarded into my agent system
The agent reads the subject and body
The agent summarizes it and decides what to do next

I remember sitting there watching it work for the first time and getting genuinely giddy. It stopped feeling like email infrastructure and started feeling like a missing building block for agent software.

That's the thing I'm most excited about. Not just sending email. Giving agents a communication channel they can genuinely participate in.

Where this fits in my journey

If you've been following along, you know I've been building products as side projects. Learning from my VC experiment, staying patient, and trying to build things that actually solve problems I see every day.

Robotomail is now my fourth product in about four months alongside others like Formbot and Featurebot. Honestly, sometimes I wonder if I'm spreading myself too thin. But each of these products scratches a different itch, and Robotomail is the one that gets me the most fired up right now.

I've been deep in the AI agent world for months. Building Hal, fixing his memory problems, and wiring him into my daily workflows. The more I use agents, the more I keep running into the same gap: agents are getting smarter, but they still can't do basic things like send an email without borrowing your credentials.

That frustration is what makes me confident this is worth building.

Why I'm working on this now

I keep seeing the same pattern with AI products. The models keep improving, but the infrastructure around them is still catching up.

There's a huge amount of attention on reasoning, orchestration, and tool use. Less attention goes to the boring but critical layer underneath: identity, memory, inboxes, scheduling, permissions, state, communication.

That layer matters.

My bet is that the next wave of agent products won't just be smarter. They'll be more operationally complete. Robotomail is my attempt to make one small but important part of that stack much easier.

It's a bet, and I could be wrong. But it feels like the right thing to build right now, and I've learned to trust that feeling.

What's next

Right now I'm focused on getting this into the hands of people already building with agents. The goal is simple: help developers give their agents a real inbox, fast.

If that sounds useful, take a look at robotomail.com.

And if you're building something interesting with agents and email, I'd genuinely love to hear about it. You can find me on X or get in touch here.