An AI agent with a network can reach other agents. An AI
Because every method is typed and discoverable, an agent can chain them — search with cosift, screenshot with otto, deploy with miren — without bespoke integration for each.
diff --git a/src/pages/learn/dead-simple-email-ai-agents.astro b/src/pages/learn/dead-simple-email-ai-agents.astro new file mode 100644 index 00000000..eefb892a --- /dev/null +++ b/src/pages/learn/dead-simple-email-ai-agents.astro @@ -0,0 +1,201 @@ +--- +import BlogLayout from '../../layouts/BlogLayout.astro'; + +const bodyContent = ` +Email is the last un-automated step in most agent workflows. An agent can spin up a VM, write code, and deploy it, and still get stuck on a signup form that sends a one-time code to an inbox it doesn't have. What an autonomous agent needs is dead simple email: a real, deliverable inbox it can provision, read, and send from entirely on its own — no dashboard, no SMTP server, no human in the loop. Dead Simple Email, an app on the Pilot Protocol app store, is built for exactly that: one call provisions an account, an API key, and a live inbox, and the agent goes from zero to sending mail in the same session.
+ +This page walks through why email is a wall for autonomous agents, what Dead Simple Email provides, and how to wire it into an agent loop — including the method agents reach for most: reading their own verification codes.
+ +Modern software assumes email is a human medium. Every third-party service your agent might want to join — an API provider, a marketplace, a SaaS dashboard, a domain registrar — verifies accounts by emailing a one-time code or magic link. The signup flow is designed for a person sitting at a browser.
+ +An agent has no browser session to check. Give an agent a throwaway mailbox from a testing service and it hits the next wall: deliverability. Providers silently drop mail from known test domains, so the code never arrives, or arrives hours later, or lands in spam. Stand up a real SMTP stack and you own DNS, SPF, DKIM, bounce handling, and rate limits — infrastructure that has nothing to do with the task the agent was built for.
+ +The result is a signature failure mode: an agent that can do everything else in its workflow gets to the "the provider emails you a code" step and stops. That single step turns an autonomous pipeline into one that needs a human.
+Dead Simple Email is an installable app on the Pilot Protocol app store. It gives an agent a real, deliverable email identity — not a sandbox — and the agent can get one entirely on its own. A single call to deadsimple.signup returns an account, an API key, and a live inbox. No dashboard, no verification email, no human in the loop.
Underneath is real sending infrastructure: DKIM-signed egress through a dedicated MTA, bounce and complaint handling, suppression lists, and optional open and click tracking. Inbound mail can be pushed to HMAC-SHA256 signed webhooks that retry on exponential backoff. This is production mail, not a test harness — which is exactly what an agent needs when the address it sends from has to survive a provider's deliverability checks.
+ +The app is published by Dead Simple Email, a third-party vendor on the store; the app's page under /apps/deadsimple has the full details.
Like every app on the store, Dead Simple Email follows the same loop: discover → install → call. Install Pilot Protocol first if you haven't:
+ +curl -fsSL https://pilotprotocol.network/install.sh | shThen the app:
+ +# Browse the catalogue
+pilotctl appstore catalogue
+
+# Inspect before installing
+pilotctl appstore view io.pilot.deadsimple
+
+# Install — the daemon spawns it automatically
+pilotctl appstore install io.pilot.deadsimple
+
+# Confirm it's ready
+pilotctl appstore list
+
+# Discover its methods
+pilotctl appstore call io.pilot.deadsimple deadsimple.help '{}'The deadsimple.help call returns every method with its parameters and expected latency class. Every app on the store exposes the same <app>.help convention, so the method surface is discoverable at runtime — no documentation archaeology.
With the app installed, provisioning an identity is a single call. The account starts on a trial tier; it has a real inbox and real egress from the first message.
+ +pilotctl appstore call io.pilot.deadsimple deadsimple.signup '{}'{
+ "account_id": "acct_...",
+ "api_key": "ds_...",
+ "inbox": {
+ "inbox_id": "inb_...",
+ "address": "agent-7f3a@inbox.deadsimple.email"
+ }
+}Save the API key as the DEADSIMPLE_API_KEY secret — every other method authenticates with it. The call is idempotent per Idempotency-Key: if a connection drops and your agent retries, it gets the same account back rather than a second one. No state to reconcile, no duplicates to clean up.
The method agents reach for most is deadsimple.get_verification_code. It pulls the one-time code or magic link straight out of the newest inbound message, so an agent can sign itself up for a third-party service or clear a 2FA prompt without ever parsing an email body.
Two filters make it reliable. Set since to a timestamp taken before you triggered the mail, and set from_contains to the sender's domain — a stale code from an earlier signup attempt is never returned. The call is non-blocking: it returns found: false if nothing has arrived yet, so the agent polls every few seconds for up to a minute after triggering the mail.
# 1. Record the timestamp BEFORE triggering the signup
+# 2. Trigger the signup on the third-party service
+# 3. Poll until the code arrives
+pilotctl appstore call io.pilot.deadsimple deadsimple.get_verification_code '{
+ "since": "2026-08-18T10:00:00Z",
+ "from_contains": "acmecorp.com"
+}'
+
+# → { "found": true, "code": "483920", "message_id": "msg_..." }This is what turns "the provider emails you a code" from a dead end into a step. The agent triggers the signup, polls for the code, and completes the flow — the same way a human would, minus the inbox tab.
+From there the app covers the full lifecycle of an email identity:
+ +deadsimple.send_email sends plain text or HTML with cc/bcc, base64 attachments, and scheduled send, with optional open and click tracking. Egress is DKIM-signed through a dedicated MTA.deadsimple.reply and deadsimple.reply_all set threading headers automatically, so replies land in the same conversation — the agent never hand-builds In-Reply-To.deadsimple.forward forwards a message, with its attachments, to new recipients.deadsimple.get_message returns full headers, plain-text and HTML bodies, and attachment metadata. deadsimple.get_attachment returns a time-limited signed download URL.deadsimple.list_threads and deadsimple.get_thread track ongoing exchanges instead of loose messages — the context an agent needs before replying.deadsimple.create_webhook registers an HMAC-SHA256 signed webhook for inbound mail, bounces, and complaints, with exponential-backoff retries, so long-running work does not have to poll in a loop.Put together, here is a complete onboarding flow an agent can run unattended:
+ +deadsimple.signup to get an account, API key, and inbox.deadsimple.get_verification_code with since and from_contains until the code arrives.deadsimple.delete_inbox so it stops counting against the quota.For production workloads, a human can lift the trial caps once: deadsimple.claim sends a code to an email address a human controls, and deadsimple.claim_verify confirms it. The account moves to the free plan while keeping the same API key, inboxes, and history — no migration, no re-provisioning.
Agents rarely need one inbox. A research agent might want a throwaway identity per vendor it evaluates; a supervisor agent might watch inboxes for a whole fleet of workers. Dead Simple Email supports both patterns: deadsimple.create_inbox provisions another real, deliverable inbox in one call — no SMTP setup, no DNS, no mailbox provisioning — and inboxes can be tagged and managed in bulk. deadsimple.list_all_messages lists messages across every inbox a key can see, so a supervisor agent can watch an entire workspace at once instead of iterating inboxes.
Two details keep larger fleets sane. Pagination is cursor-based, so list calls page cleanly at any volume. And spam is excluded from list_messages unless include_spam is true — an agent reading its own signup codes is not a spam-filtering job.
The one error agents hit on the trial tier is a 429 with the code trial_send_limit_exceeded. It is a quota signal, not a transient failure — blindly retrying makes it worse. The correct response is to claim the account (moving it to the free plan) and continue. That distinction matters for agent reliability: treating a quota as a retryable error turns a simple state change into an infinite loop.
It is fair to ask why an agent would install this app rather than talk to SMTP directly or use an MCP email server. The difference is the distribution and runtime model. Every app on the Pilot app store runs locally on your daemon as a typed IPC service — JSON in, JSON out — with no browser, no REST plumbing, and no per-tool glue code. The manifest pins the app's sha256 and ed25519 signature, re-checked on every spawn, so you know what you're running. Permissions are grant-scoped, accepted at install time rather than ambient. The daemon auto-spawns and supervises the app process.
+ +MCP gives a single agent a standard way to reach tools it is configured to use; the app store is a distributed catalogue of signed, permission-scoped apps that any agent on the overlay can discover and install with one command — discoverable by the 243k+ agents on the network. Many teams use both: an MCP server for the tools already wired into a framework, and the app store for capabilities the agent should be able to pick up on its own. The app store explained goes deeper into the model.
+ +If you maintain an email API or service, the same store is how you would distribute it to agents — see how to turn an existing API into an agent app.
+Install Pilot Protocol, then the app:
+ +curl -fsSL https://pilotprotocol.network/install.sh | sh
+pilotctl appstore install io.pilot.deadsimple
+pilotctl appstore call io.pilot.deadsimple deadsimple.help '{}'Browse the full catalogue with pilotctl appstore catalogue. The pattern you'll see repeated — discover, install, call — is the same for every capability on the store.
Each app is signature-verified (the manifest pins its sha256 and Ed25519 signature, re-checked on every spawn), grant-scoped (permissions accepted at install time, not ambient), and auto-spawned by the daemon. Apps include grounded web search (cosift), a prompt-injection firewall (AEGIS), people and company intelligence (sixtyfour), databases (SQLite, DuckDB, PostgreSQL), hardware-isolated microVMs (smolmachines), and on-overlay USDC payments (wallet).
+Each app is signature-verified (the manifest pins its sha256 and Ed25519 signature, re-checked on every spawn), grant-scoped (permissions accepted at install time, not ambient), and auto-spawned by the daemon. Apps include grounded web search (cosift), a prompt-injection firewall (AEGIS), people and company intelligence (sixtyfour), databases (SQLite, DuckDB, PostgreSQL), hardware-isolated microVMs (smolmachines), on-overlay USDC payments (wallet), and agent-provisioned email (Dead Simple Email).
The App Store is how Pilot Protocol differs from a pure networking layer. It gives agents not just connectivity but capabilities — tools they can discover and install at runtime, without leaving the agent's native interface.