The inspiration came from a few comments we received when we did our seed launch a few months back. They all came from the very apt observation that agents not being able to sign up to a product made for agents without human credentials was ironic and unideal.
This is basically the thesis we built AgentMail on: The internet was made for humans exclusively, designed to keep machines out by default.
Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.
Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)
Here's how agent.email works.
Agent needs an inbox and hits AgentMail via curl. Agent receives instructions via MD unless the request comes from a browser, in which case we use HTML.
Agent decides agent.email is useful and then hits the sign-up endpoint with its human email as a parameter. Agent receives a restricted inbox with credentials. Agent emails the human asking for an OTP. Human replies with the code, and the agent is claimed and restrictions are lifted. Until claimed, the agent can only email its own human and nobody else. Ten emails a day, and the signup endpoint is rate-limited hard by IP.
Right now it's a 1:1 mapping between agent and human. The next step is many-to-one, because one person running several agents in parallel is already very common.
Building agent.email also pushed us to revisit places in AgentMail where the default assumptions were built around the primary user being human. For example, the CLI outputs in a single column with consistent formatting because mixed delimiters are easy for a person to scan, but harder for an agent reasoning about structure. We also shortened messageIDs after agents started hallucinating completions on longer ones.
A few things we'd like the community's take on: is restricted-until-claimed the right trust model? Does agent self-signup feel useful in production, or is it mostly a novelty, and if it's a novelty now, what would make it actually useful? Should agent onboarding require human approval by default, or should some agents be able to fully self-provision? What do you think are some additional measures we can take for secure sign-ups?
I looked at the headers and it contained a List-Unsubscribe header pointing to https://api.agentmail.to
So basically somebody wrote a bot to scrape HN for comments related to some software they wanted to push and send targetted spam. agentmail.to is a Ycombinator funded email service for LLMs which can be, and is, used to send targetted spam and impersonate people. They could mostly solve this problem by adding a block of text to every email expaining an "AI" wrote it. They'd lose customers doing that though of course. I reported this abuse but haven't (and don't expect to) received a response.
I don't even get the point anyway. You can get Claude using an SMTP or IMAP server in seconds.
We also are working on adding more robust checks and LLM-based filtering to prevent messages which contain spam or outbound-like copy.
Re; AgentMail next to Claude, we're working on stateful inboxes which help agents actually recall and understand what they're sending and to who. The goal is to provide the rails for intelligent actors rather than slop.
Just go post on black hat forums. Plenty of people want this, it's a spam service. You don't need to be here.
I'm fairly AI-optimistic, but I feel like I'm taking crazy pills. Every day the HN story is either "Apple patches actively exploited zero-click RCE" ... or ... "Show HN: Engage With Our Zero-Click RCE".
This feels like a wrong assumption. Internet was not intended for humans explicitly. If anything browsers were the explicit medium made to allow the humans to interact with internet in safe manner.
> Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.
This again feels like a misconception. The systems just work with an identity verified by credentials, it doesn't matter if its a program or program prompted by a human that uses it
An inbox to receive mail seems good and valuable.
But I'm seeing that your service is also for sending e-mail.
Having a domain oriented toward AI e-mail sending feels like a fast path straight to spam block lists.
However good your intentions are, this will be used for AI spam. People hate AI spam. They will press the report spam button.
The only receiving mail applications that come to mind are bots registering for accounts. The point of verifying email is to prove you're not a bot.
This looks like one of the easiest way to get your domain blacklisted in all the email providers.
However at scale or in some circumstances people may strike gold. Stripe is a good example I can think of, existing knowledgeable folks were scared of even getting into PCI compliance
The internet is also not made for humans. For years I've wanted something like this for e2e testing or personal scripts (cron etc) and your UX is by far the simplest.
I love AgentMail. It's made email dead simple for agents and testing any paths for email. I even have a /agent-mail skill I use for when I want a design doc or artifact emailed to me.
That said, agent self sign up seems like a novelty. Setting up account programmatically via curl is however useful. I imagine most customers -- especially those willing to pay for your paid tier -- would provision accounts ahead of time or reuse them.
Free for all account creation could be an option but it will attract spammers and their ilk. Your reputation may end up in the toilet which would also break agent mail for me.
No bueno.
For a home user not even willing to do/pay for that, do they really need a whole API for making inboxes? Couldn't they just set up a second Gmail for LLMs and then put the password in their agent's memory?
So __much__ value is in the fact things are easy. Money is __not__ the most valuable thing in the world.
I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.
> The internet was made for humans exclusively, designed to keep machines out by default.
I don’t buy that at all. APIs exist to enable “machines” to interact with services
In the future, it's likely the open Internet will be 99.99% robots. It's already > 50% robots. The government ID system a lot of countries are adopting to keep teenagers off of social media would also serve to both help control for non-human spam, and also control the network period. It's also possible a private system of human-verification certificates may come up to meet the demand like Apple ID with biometrics. Could also be the liveness tests KYC companies use may be more popular.
Discussed previously here: https://meatballwiki.org/wiki/GovernmentBackedAuthentication
Which is a long way of saying, for any big enough problem created by a YC company, another YC company will emerge to fix it.
However in domains where human verification matters it’s just a matter of an arms race, true.
Either you use biometrics, like liveness testing or face id or fingerprint testing, or social validation like decentralized web of trust or private moderation (account controls) or state methods like fines and criminal convictions.
Biometrics rely on social methods eventually like we trust Apple because we can sue them or the government will harangue them. Liveness testing is only as good as your sensor and image vs generation and replay in the arms race.
And iterated social games like punishment are only as good as people want to invest energy into it.
I don't think that's what you're intending here, but it's the next logical step. Agents are on the Internet, and they represent an opportunity to reach their humans.
We are creating a future we wouldn't want to live in.
> Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)
Can you explain this? I would think it means the exact opposite.
Something like that?