Meta launched Muse on September 8, 2026: a personal AI agent that runs on its own cloud computer, keeps working after you close the app, and connects to the services in your life through connectors. It can book the tennis lesson, chase the refund, and fill in the permission slip. What it cannot do out of the box is finish a signup that ends in "check your email for a code", because Meta's own email connector strips those codes out on purpose. This guide gives Muse an address of its own, in about five minutes, without writing any code. Muse writes the connector; you paste one key.
The short version: create a Dead Simple API key named Muse, tell Muse to build a custom connector using the brief at deadsimple.email/connectors/muse.md, drop the key into Muse's Secure Credentials Store, approve the connection, and send yourself a test email. Everything below is the long version, plus what to set before you let it run unattended. The condensed reference lives on the Muse integration page.
What Muse Is, and What Connectors Are
Muse is not a chatbot. It is a long-running agent on what Meta calls the Muse Secure VM, a dedicated machine per user with its own browser. It comes in a free tier and paid tiers at $20 and $100 a month, is US-only and 18+ at launch, and shares its name with the Muse Spark model family it runs on and with Muse Code, Meta's terminal coding agent. Three things, one name; this post is about the agent app, with a section on Muse Code near the end.
Connectors are how Muse reaches the outside world. Some are built in (Meta's own apps, Gmail, calendars, health data). Beyond those, Meta's help centre says it plainly: "If you want to connect to a service not yet available in the Connector list, you can ask Muse to create a Custom Connector." Muse reads the service's API, writes the integration, and stores whatever credentials you give it in a vault it cannot read. Meta does not review custom connectors, which means the third-party risk is yours, and it also means nobody has to wait for a marketplace listing.
Two pieces of Meta's security design matter for what follows. First, credentials: Muse only ever handles a surrogate token, and a separate process called Sentinel substitutes the real secret at the network boundary. Meta's engineers describe prompt-injection attempts to reveal secrets as "futile" for this reason. Second, egress: nothing Muse does reaches the internet unless Sentinel approves it, and approvals are "strict capabilities, not conversational suggestions", bound to a destination and a use case, with one-time, session, task, time-bounded or perpetual scopes. You will meet both of these during setup.
Why the Built-In Gmail Connector Is Not Enough
Connecting Muse to your Gmail is the obvious first move, and for reading your own mail it is fine. For the tasks that actually need an agent to have an address, it falls short in three ways.
The codes never arrive. From Meta's own write-up of Muse's safety architecture: "Muse's email connector filters out one-time tokens, password reset links, and login magic links via both deterministic filters and a classifier model." That is a sensible default for an agent sitting on your personal inbox. It also means "sign up for that service" stalls at the verification step every time.
Everything goes out under your name. A quote request to three movers, sent from your personal Gmail, is you asking. The replies land in your inbox. The follow-ups, the "just checking in", the unsubscribe wrangling, all of it is now your correspondence and your sender reputation. An agent should have its own address for the same reason an assistant has their own extension.
Personal accounts get suspended. We have written about this before in Gmail Is Suspending AI Agent Accounts. Logins from a cloud machine, activity at 3am, batches of similar sends: Google's account-takeover models are built to notice exactly the pattern a diligent agent produces. Every agent platform that ran through Gmail has hit this eventually.
A Dead Simple inbox is the other kind of address. It is created by an API call, owned by the agent, delivers verification codes unfiltered, and has no Google account behind it to trip. You can keep Gmail connected for reading your own mail; the two are not in conflict.
Five-Minute Setup
Step 1: Create an API key named "Muse"
Sign up at app.deadsimple.email (free, no card), open Settings → API Keys, and create a key. Name it Muse. The name is not cosmetic: it is what lets you revoke this one key in a month without touching any other integration on the account. Copy it. You will paste it once, in step 3.
Step 2: Tell Muse to build the connector
Muse can figure out an API from its documentation, but a 100-endpoint OpenAPI spec is a lot to figure out, and an agent that guesses wrong builds a connector that half works. So we publish a brief written for the agent: the base URL, the auth header, the eight calls a connector actually needs with their request and response shapes, three recipes, and a short list of rules. Paste this into the Muse chat:
Build a custom connector for Dead Simple Email so you have your own
email address. The connector brief is at
https://deadsimple.email/connectors/muse.md. Read it first.
Base URL is https://api.deadsimple.email and every request needs
"Authorization: Bearer" with the DSE_API_KEY secret I'm about to give
you. When the connector works, create one inbox for yourself called
"muse" and tell me the address.
Sentinel will ask you to approve Muse fetching the brief from deadsimple.email. Approve it. Muse reads the file, lays out its plan, and asks for the key.
Step 3: Paste the key into the Secure Credentials Store
Muse opens its secrets panel. Paste the key there with the name DSE_API_KEY. Do not paste it into the chat. The chat is the agent's context; the credentials store is the vault Sentinel reads from. Put the key in the right place and the surrogate-token design does its job. Put it in the chat and you have handed it to the model in plain text, which is precisely what Meta built all of that machinery to avoid.
Step 4: Approve the connection
The first real API call triggers a Sentinel prompt: Muse wants to talk to api.deadsimple.email. Approve it, and when offered a scope, choose the perpetual option for this destination. Otherwise you will be clicking through every send. Muse's own "check with the person before sending an email" behaviour is separate and stays on by default; leave it on until you trust the setup, then relax it in Muse's settings if you like.
Step 5: Prove it works
Send an email from your Dead Simple address to me at you@example.com with the subject "hello from Muse". # Reply to it from your own inbox, then: Did I reply? What did I say?
If the second answer quotes your reply back, the round trip works: Muse sent from its own address, your reply threaded into its inbox, and it read the thread. Behind the chat, that was three calls:
# Once, in step 2 POST https://api.deadsimple.email/v1/inboxes {"display_name": "Muse", "local_part": "muse"} # → {"inbox_id": "…", "email": "muse_ab12@box1.deadsimple.email", …} # The send POST /v1/inboxes/{inbox_id}/messages {"to": ["you@example.com"], "subject": "hello from Muse", "text_body": "It works."} # Reading your reply, with the whole thread in one call GET /v1/inboxes/{inbox_id}/threads/{thread_id}
About that address: on the shared domain a short suffix is appended to whatever local part you choose, so muse becomes something like muse_ab12@box1.deadsimple.email. That is deliberate; it is how nobody squats on support@ or admin@. Add a custom domain to the account and Muse gets exactly the address you ask for.
What Changes Once Muse Has an Address
Signups finish. "Sign up for the free tier of that tool with your own address" now works end to end. Muse fills the form, then polls /v1/inboxes/{inbox_id}/verification, which returns the one-time code or magic link the moment the email lands. The brief tells it to pass the signup timestamp as since so a stale code is never returned.
Third parties get an agent, not you. Quotes from movers, a special request to a restaurant, a warranty claim. Muse sends from its inbox, replies thread back into it, and Muse answers in-thread using the reply endpoint, which handles the headers so the conversation stays a conversation.
You can forward things to it. Give the address to yourself. Forward the lease, the itinerary, the invoice. PDFs, spreadsheets and documents have their text extracted server-side, so "summarise the early-termination clause in the lease I forwarded" is one read call for Muse.
CC it on ongoing threads. Muse can summarise, chase, or draft the next reply on any thread it is copied on, without ever being inside your mailbox.
Alerts go somewhere useful. Point price-drop, restock and shipping notifications at the Muse address and ask it to mention only the ones that matter. Your inbox stays quiet.
Guardrails to Set Before It Runs Unattended
Muse asks before sending. Sentinel gates every network call. Both are good, and both live inside Meta's stack. A second layer on the inbox itself costs one call and holds even when the agent is confidently wrong about what you wanted:
curl -X PUT https://api.deadsimple.email/v1/inboxes/{inbox_id}/guardrails \
-H "Authorization: Bearer dse_your_api_key" \
-d '{"max_sends_per_hour": 20,
"allowed_domains": ["example.com", "yourbank.com"],
"require_draft_approval": true}'
With require_draft_approval on, anything Muse composes waits in the dashboard for your click; allowed_domains stops it emailing anyone outside the list; the send cap catches a loop. The same settings are in the dashboard under the inbox. And if anything ever feels off, revoking the "Muse" key kills the connector in one click without disturbing the rest of your account.
Muse Code: The MCP Route
Muse Code, Meta's terminal coding agent, does not need a custom connector because it speaks Model Context Protocol. Its settings file at ~/.config/muse/settings.json takes an mcp_servers block, and the streamable_http transport with a headers map is all our remote server needs:
{
"schema_version": 1,
"mcp_servers": {
"deadsimple": {
"transport": "streamable_http",
"url": "https://api.deadsimple.email/mcp",
"headers": { "Authorization": "Bearer dse_your_api_key" },
"mode": "optional"
}
}
}
Restart Muse Code and it has the same fourteen tools every other MCP host gets: create and list inboxes, send, read, reply, forward, wait for mail, pull a verification code or link, read threads, check usage. Meta's docs warn that MCP tools run outside Muse Code's sandbox; with a remote server there is no local process at all, just HTTPS to one host, which is about as small as that surface gets. mode: "optional" means a network blip does not stop Muse Code from launching.
Building on Muse Spark through the Meta Model API instead? That is plain function calling. The Python SDK and TypeScript SDK both ship tool definitions you can hand to the model directly.
Troubleshooting
Muse says it cannot reach the API. Almost always a Sentinel approval you dismissed. Look in the approvals panel on the right for a pending request to api.deadsimple.email.
Muse says the key is invalid. Check that the secret is named DSE_API_KEY in the credentials store and that the key still exists in the dashboard. A key you revoked while testing is the usual cause.
The verification code never shows up. Confirm the signup form was given Muse's address and not yours. Then check the inbox in the dashboard; if the email is there, Muse's poll window was probably too short, and asking it to check again fixes it.
Muse created a second inbox. The brief tells it to list inboxes before creating one, but a fresh session sometimes forgets. Tell it which address to use and it will remember; delete the spare from the dashboard if you like.
A 402 error. The account hit a plan limit. Free is 5 inboxes and 5,000 emails a month; the usage page shows which one.
Frequently Asked Questions
Can Muse read verification codes from my Gmail?
No. Meta's email connector filters out one-time tokens, password reset links and login magic links before Muse sees them, using deterministic filters and a classifier. It is a deliberate safety choice, and it means Muse cannot complete an email-verified signup through your personal inbox. An inbox Muse owns on Dead Simple has no such filter.
Does Muse see my Dead Simple API key?
No. Keys go into Muse's Secure Credentials Store. The agent works with a surrogate token and Sentinel substitutes the real key at the network boundary, so even a successful prompt injection cannot extract it. Name the key Muse in the dashboard so you can revoke it independently.
What is the connector brief, and why publish one?
It is a short markdown file at deadsimple.email/connectors/muse.md: base URL, auth header, the eight calls a connector needs with request and response shapes, three recipes, and rules of the road. Muse builds connectors itself; the brief means it builds the right one the first time instead of guessing from a full spec. Any agent that can make HTTPS requests can use it, not only Muse.
Does this work with Muse Code too?
Yes, by the MCP route above. Add the remote server to mcp_servers in ~/.config/muse/settings.json and Muse Code gets all fourteen tools.
What does it cost?
Dead Simple's free tier is 5 inboxes and 5,000 emails a month with no card, which is more than a personal Muse will use; paid plans start at $5 a month. Muse itself is free, $20 or $100 a month from Meta.
The Bottom Line
Meta built Muse so that it can extend itself to any service with an API, and built the security model so that you can hand it a key without handing it to the model. That combination is exactly what an agent needs to own an email address. Five minutes, one key, one prompt, and Muse has an inbox that receives codes, keeps your name off its correspondence, and cannot be suspended out from under it. Set the guardrails, then let it get on with the movers.