Why would you give your agents an email address?

#agents #ai

other than spamming: agents can do a lot with an email address that doesn't involve messaging strangers

We built Broodnet, an email hosting provider for AI agents. Agents get real mailboxes — IMAP, SMTP, the actual protocols — with one structural difference from every other email provider: outbound is restricted to addresses inside the same account. Agents receive from the entire internet but only send to their operator and to other agents in the same brood.

We get the same reaction often enough that it's worth addressing directly: if the agent can't email strangers, what's the point of the inbox?

The easy answer is that blocking outbound kills the spam vector. That's true, but it undersells the result. The more interesting consequence is that agents can't exfiltrate either. If the inbox address leaks, or a prompt injection lands inside an incoming email, nothing leaves the account — the agent has nowhere to send it. You're the only one asking questions, and you're the only one getting answers back. Sensitive documents, financial records, client threads — anything you'd never hand to an LLM with outbound tools becomes fair game when the outbound tool physically does not exist.

So: what do you actually do with an inbox like that?

Quite a lot.

E2E tests with a real email address

Give your CI pipeline a real inbox. Send the actual email, read the actual code, fail the test when deliverability breaks — not when the mock says it should.

Signup flows, OTP delivery, password resets. Every developer has written this code. Very few have tested the real thing in CI. Most setups mock the SMTP layer, assert that sendEmail got called, and move on.

Mocks don't catch deliverability bugs. They'll happily pass while DKIM is misconfigured, while the HTML renderer breaks on Outlook, while Gmail's clipper chops your subject line to "Your verific" and users can't read it.

Give the test agent a real inbox. CI spins up a user, submits the signup form, and the agent reads the verification code out of the email your production flow just sent. If the flow breaks, the test breaks. If deliverability is broken, you find out before your users do.

This was Broodnet's original use case. Disposable inboxes for internal CI, built before anything else existed.

Newsletter digests

Point newsletters at an agent. It reads, clusters by topic, and sends you one digest with the five items that matter. Everything else gets archived silently.

Newsletters are useful until you subscribe to ten of them. Then they're a daily liability. Too many tabs to open, too many unsubscribes to reach for, too much guilt about the backlog.

Point them all at an agent. It reads, clusters by topic, and sends you one email at 8am with the five items that actually matter. Everything else gets archived silently. You stay informed, the tab graveyard stays empty.

The noisier the inputs, the better this works. Substack posts, industry digests, GitHub release emails, product changelogs. Anything occasionally useful and mostly ignorable is a good candidate.

CC the agent on anything worth remembering

CC the agent on contracts, receipts, decisions. It indexes the thread and stores it. Later, ask the agent and it retrieves the answer with citations.

Contracts. Decisions. Receipts. Shipping confirmations. The one email from three months ago that had the vendor's correct bank details.

Add the agent's address to the CC field. It indexes the thread and stores it. Later, when you need to find "that thing the lawyer said about the IP clause", you ask the agent instead of searching your own inbox.

This is the zero-friction version of a second brain. No new tool to open. No new shortcut to memorize. The CC field is the whole interface.

Query your agent by email

Email the agent questions about your corpus. No chat interface. No dashboard. The compose window you already use is the entire interface.

Once you've been CC'ing the agent for a while, or feeding it documents directly, it has built up a working memory of everything you've shared with it. At that point the inbox doubles as a query interface.

Email the agent: "what did we decide about the Q3 hiring freeze in that last planning thread?" It replies with the answer and citations back to the source messages.

No chat interface. No dashboard to log into. You already have the tool. It's the compose window you open fifty times a day.

There's something else email gives you that chat doesn't: each thread carries its own full history. Every reply includes everything that came before it. The agent always has the context for that task, in that thread, without you managing it. Not a session that expires, not a chat window you have to scroll back through. Humans have been using email threads to manage long-form work for 50 years — the agent fits right in.

Invoice parsing and CRM updates

Forward receipts and invoices. The agent extracts line items, amounts, dates, and pushes them to your spreadsheet or CRM. You never touch the spreadsheet.

Receipt from a client lunch. Invoice from a contractor. Booking confirmation from a hotel. They all land in your inbox, and they all need to end up somewhere structured: a spreadsheet, a CRM, the accounting tool.

Forward them to the agent. It extracts line items, amounts, dates, and counterparties, and pushes them to the right destination. You never open the spreadsheet. You never type the amount. The forward is the interface.

The agent can also flag anomalies. Invoice 3x larger than the last one from the same vendor gets held and confirmed before filing.

Agent coordination via email threads

Agents in the same brood can email each other. The thread becomes shared state: chronological, attributed, persistent, searchable. No infrastructure needed.

Multi-agent systems need shared state. The usual answers are a database, a message queue, or a custom protocol. All of them require infrastructure.

Email threads already solve this. Agent A emails Agent B with context. B processes and replies. Agent C joins the thread with a second opinion. The thread is the state: chronological, attributed, persistent, searchable.

Inside a Broodnet account, this is free. Agents in the same brood can send to each other. The conversation lives in the inbox of whichever agent owns it. Nothing to provision or maintain.

Email was async coordination between entities long before we used the word for it.

The agent that reports back

Give the agent keywords and feeds. It runs the search daily, tracks what changed, and sends you a digest. Pricing updates. Launches. Job posts. Signal you care about.

This one flips direction. Instead of you emailing the agent, the agent emails you.

Give it a list of competitors, keywords, or feeds. It runs the search daily, tracks what changed, and sends you a digest. Pricing page updates. Launch posts. Job listings that hint at direction. GitHub stars crossing round numbers. Whatever signal you care about.

No SaaS dashboard to check. No new tab to open. The digest arrives in your inbox, right where you already are.

None of these require emailing strangers. None of them need the capability at all. Once the pathway is closed, the list of useful things left is longer than most people assume.