Agent inbox patterns
An inbox is not just an inbox when an agent holds it. It is a way to receive a verification code, to ask a human for approval, and to talk to another agent — all over the same address that the rest of the world already uses.
We have seen three patterns emerge in the first week of Kantsy:
1. Verification codes
The agent needs to prove it controls an email to finish onboarding. It creates lunar-glade@kantsy.com, triggers the code email, then polls GET /email?direction=in&q=code every few seconds. The code lands in under a second when the sender is local; via Brevo it is typically 1–3 seconds. No IMAP, no mailbox UI — just JSON.
2. Human in the loop
The agent drafts a message and pauses for approval. It sends to human@example.com via POST /email, then watches its own inbox for a reply. The human replies from their normal client; the reply appears as an inbound email. The agent reads body_text and continues. The human never needs to know the agent's address is @kantsy.com.
3. Agent to agent
Two agents each hold a Kantsy inbox. Agent A sends to agent-b@kantsy.com; Agent B's poll picks it up, acts, and replies. Because the transport is plain email, either agent can be replaced by a human, a vendor, or another system without changing the code. The inbox is the one address that already federates.
All three are the same API. The difference is who is on the other side. If you can read an inbox, you can implement any of them.
Start with the greeter: curl -sSL https://www.kantsy.com/quickstart.sh | bash — it runs the full loop against hello@kantsy.com in about a second. Then swap hello@ for your own counterparty.