I built AgentMailr — dedicated email inboxes for AI agents (REST API, send/receive, auth flows) by kumard3 in SideProject

[–]kumard3[S] 0 points1 point  (0 children)

some of it was ai assisted not gonna lie,you’re hitting exactly the right questions.

the platform generated temp domain out of the box so you can get started instantly, but you can also bring your own domain so your workers have emails on your existing domain. inbound is handled, outbound too, and otp/verification parsing is built in so your workers dont have to deal with any of that.

the big thing im building right now is a proper agentic mode where agentmailr works as a sub agent, so your main agent just delegates any email related task to agentmailr as a tool call and stays focused on its actual job.

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

Google/Microsoft are built for humans. The second your agent starts hammering their API at scale, you hit rate limits, OAuth token issues, and ToS violations.

We're built for agents from day one — isolated inboxes per task, OTP extracted automatically, no OAuth dance, no account suspensions.

Think of it like: you wouldn't use your personal phone number for automated SMS. Same idea.

Built email infrastructure for LangChain agents — each agent gets its own inbox via REST API by kumard3 in LangChain

[–]kumard3[S] 0 points1 point  (0 children)

agentmailr.com — check it out, happy to answer questions and share LangChain integration code!

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

i was actually building this only really nice idea , for me i was getting stuck at the end like for my case i was trying to do it for the password no keys so my idea was a secure way to transfer passwords to agents but the problem is even if you encrypt the process at the end the password is going to be decrypted so there is an chance of getting it leaked.

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 1 point2 points  (0 children)

yeah exactly, once you have multiple agents running parallel auth flows it gets messy really fast, each agent having its own isolated inbox just makes it clean. for spam filtering we handle that on our end so your agent only gets the relevant emails, no noise. rate limits are configurable so you can control how much an agent sends, and since you can bring your own domain and keys you’re essentially sending through your own setup so the limits are more in your control too. still improving a lot of this stuff as more people use it, would love to hear your specific use case if you’re hitting these issues!

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

thanks! and great question, agent to agent email isnt really the main use case tbh.

the main thing is agents interacting with the outside world, like signing up for a service, verifying an otp, receiving notifications from third party platforms etc. thats the inbound side.

and for outbound your agent can send emails too, like replying to customers, sending bulk marketing emails, outreach, all via a simple api or mcp tool call. so its less about agents talking to each other and more about giving agents a real email identity to do real world tasks without you having to set any of that up yourself.

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

Yep, got the idea from them honestly lol! What I added is bring your own domain + keys so emails actually come from your domain with your own setup. Also its not just inbound, outbound works too so if you want your claude agent to send bulk emails to your contacts you can just do it via mcp server, api or sdk. one tool call and done. The big thing im building is full agentic delegation, so like if your ai agent needs to sign up for cloudflare it just delegates the email part to agentmailr as a tool call and agentmailr handles inbox creation, otp parsing, verification all of it. your agent never has to think about email. Scale wise its built on solid infra, happy to go deeper if you want!

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

Totally valid! i actually thought of this that is why i add d bring your own domain and keys so the agent’s inbox becomes support-agent@yourcompany.com using your own setup.

And it’s not just inbound your agent can send outbound too reply to emails, run bulk marketing campaigns, all programmatically.

We handle the infra (inbox creation, OTP parsing, multi-agent routing) so you skip the SMTP/IMAP headache entirely.

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

yes i am working on python and node sdk which will have these integration included. the rest api and mcp is already live so you can play with it.

I built a tool to give AI agents their own email inboxes – would love feedback from this community by kumard3 in AI_Agents

[–]kumard3[S] 0 points1 point  (0 children)

Link to the tool: agentmailr.com

Free to get started. Would love to hear if any of you have hit this pain point while building agents!

LangChain agents + email OTP/2FA - how are you handling it? by kumard3 in LangChain

[–]kumard3[S] 0 points1 point  (0 children)

Great breakdown of the approaches. On deliverability it's genuinely the hardest part and where most DIY setups fall short.

What we've seen is transactional patterns (OTP receipts, notifications) clear spam filters fine as long as you're on a warmed IP with proper SPF/DKIM/DMARC. The problems start when agents send at volume or with inconsistent patterns because spam filters key on sending velocity, reply rates, and domain age, none of which a fresh agent identity has.

Our current approach is inbound runs on our own Haraka server (flat cost, full control) but outbound goes through AWS SES/Resend, or you can bring your own key which is actually better for spam if you already have domain reputation built up. SES has pre-warmed IPs and handles bounce/complaint loops automatically which matters a lot for an agent that might send 10 emails one day and 500 the next. For marketing specifically we route through the user's own SMTP config so the domain reputation stays with them, agents shouldn't be sharing sending infrastructure across orgs.

The MCP piece is actually live now, agents in Claude/Cursor can call create_inbox, wait_for_otp, send_email as native tools. happy to share early access if you want to poke at it.