Lumbox gives each agent its own inbox. The main thing that makes it different from rolling your own:

GET /otp is a long-poll endpoint that blocks until the OTP arrives. Your agent just calls it and waits. No polling loop, no webhook setup, no extra infra.

Also ships with Steel Browser integration so the full signup/verify flow is a single skill call: skill_signup_with_email handles navigate, fill form, submit, wait for OTP, enter OTP.

There is also a credential vault where agents never see passwords - they are typed into fields directly without being exposed in the conversation or logs.

We just rebranded from AgentMailr to Lumbox after a trademark conflict with AgentMail (YC-backed). Their $6M raise is good validation the problem is real.

Free tier: 3 inboxes, 500 emails received/month. lumbox.co

Happy to answer questions about the architecture or the long-poll approach.

Comments URL: https://news.ycombinator.com/item?id=47422578

Points: 1

# Comments: 0

When you run multiple agents doing outreach in parallel, the default setup most people land on is having all agents share one email domain and sending identity. This breaks in a few ways at scale:

1. Reputation isolation: if one agent gets flagged for aggressive sending or trips spam filters, the entire domain reputation degrades. Every other agent's deliverability takes the hit even if they're running fine.

2. Reply attribution: all inbound replies land in one inbox with no clean way to route them back to the specific agent that initiated the conversation. Makes conversion tracking nearly impossible.

3. Per-agent A/B testing: impossible to test different messaging approaches at the agent level when they all share an identity.

The pattern that seems right is giving each agent its own dedicated sending address so reputation is isolated per agent and replies route back correctly. But the tooling to do this cleanly - especially the inbound routing piece - doesn't seem to exist in a plug-and-play way for agent workflows.

Curious how others have solved this. Are you managing separate identities manually, using some existing tool I've missed, or just accepting the shared domain limitations for now?

Comments URL: https://news.ycombinator.com/item?id=47386460

Points: 1

# Comments: 0

So I built AgentMailr. You call an API to create an inbox, your agent gets a unique email address, and replies route back to that specific agent. Works for both inbound (OTP parsing, reply routing) and outbound (cold email, notifications).

Bring your own domain is supported so emails come from your domain, not ours. REST API and MCP server are live. Node/Python SDKs are in progress.

Happy to answer questions about the architecture or how I'm handling multi-agent routing.

Comments URL: https://news.ycombinator.com/item?id=47386367

Points: 7

# Comments: 5

a few things people usually ask:

- yes it handles plain text, HTML, and subject line extraction. the parser picks the most likely OTP code across all three so you're not locked to a specific email format

- you can pass a `from` filter to only match emails from a specific sender domain, which helps avoid picking up the wrong code if your agent has multiple services sending to the same inbox

- the long-polling approach means your agent just blocks on one call instead of polling. no webhook server to maintain, no correlation logic to wire up

also wanted to mention - OTP/2FA is just the first thing we're solving. we're building out bulk email sending and marketing email support as well, so agents can do the full email loop: receive OTPs, send outreach at scale, run campaigns. the goal is to be the complete email layer for AI agents.

if you're running agents at scale and hitting edge cases, would love to hear what you're running into.

When an agent tries to sign up or log into a service that sends an email OTP, the options are terrible. You either dump the full email HTML into your LLM context (slow, expensive, fragile) or you write a polling loop that constantly checks for new emails.

AgentMailr solves this with long-polling. You create a named inbox for your agent, then call waitForOtp() which hangs the HTTP request open until the email arrives and returns just the extracted code.

const inbox = await client.createInbox({ "my-agent" }) // my-agent@agentmailr.com

const otp = await inbox.waitForOtp({ timeout: 60000 }) // returns "847291" automatically

Supports 4-digit, 6-digit, alphanumeric codes, and magic links.

Built this because I needed it. Would love feedback especially from people running agents at scale.

Comments URL: https://news.ycombinator.com/item?id=47199017

Points: 1

# Comments: 1