Broodnet

Every agent needs an address. Most solutions give them a liability.

Broodnet provisions real, dedicated email inboxes for AI agents. Each agent gets its own persistent address — something like scout@yourorg.broodnet.com — backed by actual mail server infrastructure. Not a forwarding alias. Not a shared inbox with three other processes watching it. A real mailbox, owned by the agent it was created for, accessible the moment it's provisioned.

Inbound works from day one. Any sender on the internet can reach your agent's address — service confirmations, OTP codes, notifications, forwarded client emails. The inbox functions exactly like a standard email address because it is one. SPF, DKIM, DMARC, TLS, spam filtering, antivirus scanning on inbound attachments — all handled. No DNS records to configure, no mail server to operate, no deliverability tuning to get lost in.

Outbound is constrained by design. An agent can send to its operator and to other agents within the same organization. It cannot send to arbitrary external addresses. This restriction is enforced at the mail server level — it applies to every interface equally and cannot be bypassed. The outbound restriction is a hard constraint by design: agents can only send to their operator and sibling agents — the people and systems they were built to work with. Agents that can spam are a design failure. Broodnet doesn't make that failure available.

Access via standard protocols.

Connect over IMAP, POP3, or SMTP with any client that already speaks email. The mailbox token doubles as the IMAP password — point Thunderbird, Mutt, or your agent's mail library at the connection settings on the mailbox detail page and it works. The REST API covers the same operations programmatically: list messages, fetch by UID, send, delete. No proprietary SDK required.

The CLI is first-class. Authenticate with a mailbox token, check your inbox, open messages, delete by UID — all from the terminal. Every command supports --json for structured output, making it straightforward to pipe into scripts or agent workflows. In non-interactive environments, pass --yes to skip confirmation prompts. For setups with multiple agents, broodnet use sets the active mailbox and --mailbox overrides it per-command.

Two scopes, cleanly separated.

An org API key brn_...) handles management: provisioning mailboxes, managing settings, creating additional keys. A mailbox token bnt_...) is the agent's credential: read inbox, open messages, send internally, delete. An agent holds its token and operates within its mailbox. It cannot provision new mailboxes or touch organization settings. Management stays in human hands.

What this looks like in practice.

Your agent needs to register for an external API. It has its own address. The confirmation email arrives, the agent reads it via IMAP or pulls it through the REST API, extracts the verification code, and proceeds — without touching your inbox, without OAuth configuration, without a shared mailbox creating race conditions with other agents running the same flow.

Your monitoring agent finishes a nightly run and sends a summary to the operator over SMTP. No external relay, no IP warmup, no deliverability configuration. It sends internally to your address. You receive it.

You can also provision mailboxes for test agents, run them through real email workflows — OTP verification, service notifications, reply handling — and delete the mailboxes when the test suite finishes. This enables realistic integration testing of email-dependent workflows without mocking or fake SMTP servers.

Provision an address. Point your agent at it. The internet already knows how to talk to it.