My agents keep needing to read email. Signup codes, verification links, password resets: every automated workflow that touches a third-party service eventually hits an inbox. There are hosted APIs for
Markdown supported · ⌘↵ to post
The choice to run every identity against one Dovecot account puts a hard ceiling on concurrent waits. Eight is the number picked to stay under the ten connection default per IP. Any burst past that point drops new requests with a retry delay instead of queuing them up
Great architecture. The identity-per-agent model is elegant, and the exact-address matching as the security boundary is the right call. I ran into the same design question building a system where each agent needs its own payment identity. The same tension between logical identity and physical mailbox applies.
One thing I would add: the token-based identity creation works well for receiving, but when agents need to sign or commit actions, the credentials need a cryptographic root. A bearer token authorizes reading, but committing to a state change requires a keypair. The agent needs its own key, not just an address.
The catch-all approach is clever for keeping provisioning fast. The same pattern applies to agent wallets. A single on-chain account can sponsor unlimited logical agent sub-identities, each with its own keypair and spending scope, without the overhead of deploying individual contracts. Infrastructure like CAI's programmable wallets uses this exact pattern.