AI workers for Meta Muse.
Muse runs your errands in one context, on one model, with your whole identity. WorkerKit gives it a fleet of specialists: background AI workers with their own instruction, memory, schedule, budget and pre-scoped app access, hosted around the clock and reporting back in short, costed digests. Setup takes about a minute of your time.
What Muse is
A personal agent, one context.
Meta introduced Muse on 8 September 2026: a personal AI agent that runs errands, manages schedules and carries out multi-step tasks across the apps a person connects, on iOS, Android and the web at muse.ai. It works in its own cloud computer, remembers what it learns, runs tasks in the background and on a schedule, and reaches outside services through connectors that a separate system, Sentinel, allows, denies or sends to the person for approval.
| What breaks | Why |
|---|---|
| The chat | It fills with machine output, and the large jobs crowd out the thinking. |
| The model | Every job runs on the one you chat with, whether the job needs it or not. |
| The grant | Every job acts with your whole identity, so one bad instruction or one injected email reaches everything you connected. |
Muse already runs tasks in the background and on a schedule. Every such task still shares three things with your conversation: the same context, the same model, and the same identity, with the full access of every account you connected. That works for a few jobs. As background work grows, the three things above break.
Hired specialists
What a worker adds beside Muse.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs; Muse never has to.
| Aspect | Muse | A WorkerKit worker |
|---|---|---|
| Context | One conversation, shared by every job it carries | Its own, sealed per run; only the digest returns |
| Model | The one you chat with | Chosen per worker from any supported provider, or your own provider key |
| Identity | Yours, with every account you connected | Its own key, with an explicit grant per app, read-only by default |
| When it runs | In your session, and in the background tasks you set | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | Everything, into the chat | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Memory | Muse's memory about you | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Disconnect the service | Disable or revoke one worker; nothing else moves |
The operator pattern
Muse operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in plain language. "Which workers failed today?", "Run the GitHub briefing now", "Pause the scanner." |
| 2 | Muse | Reads its key's scopes first, picks the matching operation, and follows the operating rules in its WorkerKit skill. |
| 3 | The worker | Executes in its own context, on its own runtime, on its schedule or on demand. |
| 4 | Both | Muse reads the result from the fleet feed: one held connection covers the whole fleet, and the run's receipt carries the digest and the settled cost. People receive it through the worker's delivery channels. |
Muse becomes the fleet operator. The workers do the unattended work, and Muse does the thinking about it.
Classification on demand
Create a decision worker from your questions.
Categorize, score or triage connected data, then reuse and adjust the worker.
Reuse an existing worker or decision kit when its questions fit. For a custom classification task, creation compiles a supported source recipe and typed questions into a private kit and an installed decision worker. Optional deploy:true adds deployment; creation never starts a run or adds a schedule. The kit can be edited and published later through the normal kit lifecycle.
Discover recipes with GET /api/directory/mcp/authoring/tools?purpose=decision and read GET /api/directory/mcp/authoring/guide?section=decision; both are anonymous. Check connections with GET /api/manage/apps, then send the request to POST /api/manage/decision-workers. Use the returned worker with the existing deployment, run and instruction endpoints in the workers OpenAPI document. Running needs runWorkers; results need readRuns. Saved setup answers adjust categories/levels; a structural question or source change needs a revised kit and a replacement install. Check receipt status, coverage, omissions, warnings and cost before claiming completion.
Start with email-previews, calendar-events or sheets-rows. These recipes return judgments without app writes. Email previews do not include full threads; calendar events are invitation data, not transcripts; Sheets needs a Google file ID, a finite tab-qualified range and a columns map. A connected app alone does not make every tool a supported source. Source filters select evidence, not permissions: the Sheets recipe grants spreadsheet reads across the linked Drive account.
Supply 1–8 questions: choice with named options, score with ordered levels, or noul for the probability of a statement. Choice adds unclear automatically. Set an explicit confidenceFloor between 0 and 1; it routes uncertainty and does not promise accuracy. maxItems is 1–50, default 20. Creation requires publishKits and installKits; optional deployment also needs manageDeployments.
Use a fresh requestId for each new worker. Retry with the same ID and identical body to recover the original receipt; a changed body returns 409. The response includes tokenId for MCP/CLI worker commands, stable workerId, kitSlug, readiness and nextCall. A deploymentError means the worker already exists: fix deployment on that worker. The receipt is a snapshot; check current worker readiness before running. No worker API secret is returned.
What it unlocks
Background work that stays out of the chat.
Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest returns to the chat. A large crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
- The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
- Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
- Awareness by default Standing monitors and briefings watch continuously and report only what is new. You stop relying on remembering to ask.
- Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer. A chain stops at three questions deep.
- Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
- Kits: install one or make your own Published kits come pre-instructed, pre-permissioned and pre-scheduled, so the job you want likely exists. When it does not, build one in the Studio, turn a tuned worker into one, or have Muse author, validate and publish one through the API.
- Fleet operations Clone a tuned worker for the next client, one at a time or in bulk, with a dry-run preview. Permissions and the restriction rows behind them travel with the copy; schedules arrive disabled.
- Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
What workers can reach
Your apps, by explicit grant.
A worker uses only the accounts you connected to it, with the exact access you approved. A kit cannot reach anything you did not hand it.
| Kind | What a worker can use |
|---|---|
| Connected apps | Email (Gmail, Outlook), calendars (Google, Outlook), Google Drive and SharePoint, Slack, Microsoft Teams, Telegram, Discord, Confluence, Granola, Gong, Shopify, Zendesk, GitHub, CRM, Google Search Console, Google Analytics, BigQuery, Google Maps, web search, Bright Data, Firecrawl, Reddit, SMS and WhatsApp, SEO tools, weather, and Records, the tables a worker keeps between runs. |
| Curated vendor MCP apps | Apify, Stripe, Klaviyo, Webflow, Miro, Meta Ads, Wix, WordPress.com and more, each with tool-level allow and deny. |
| Your own MCP servers | Register any MCP server as a custom app. Its credential is stored on the platform and never handed to a worker. |
Access and control
Scoped per worker, and scoped for Muse too.
| Layer | What it holds |
|---|---|
| Per-worker grant | You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted. |
| The app firewall | Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed. |
| Prompt injection | A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed. |
| Muse's own access | A manager key carries explicit scopes, is shown once and stored hashed. It reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM. Muse reads its scopes before planning, and an admin can revoke the key at any time without touching a worker. |
A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.
How it connects
A custom connector, a key, a skill.
Muse reaches an outside service by holding a credential for it and calling its API, rather than by adding an MCP server. So it reaches WorkerKit over the plain-HTTPS WorkerKit API: an account admin creates a manager key with the scopes the job needs, you enter it through Muse's own hosted API-key entry, and the agent calls the API directly from then on, or uses the wk CLI in its VM. It installs the WorkerKit skill file that carries its operating rules. The key reaches the fleet only; it grants no access to any connected app.
The whole procedure, written for the agent doing it, is the setup guide. The human's part is two steps and about a minute.
Muse Code, Meta's terminal coding agent, is a different product and speaks MCP: it connects to the WorkerKit MCP server with one settings block, as described in Connecting Muse Code to your AI workers and Muse Code connectors. Both reach the same fleet.
Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. The plans are on the pricing page.
Questions
Muse and WorkerKit, answered.
- What is Meta Muse? Muse is Meta's personal AI agent, introduced on 8 September 2026 on iOS, Android and the web at muse.ai. It runs errands and multi-step tasks across the apps a person connects, works in a cloud computer of its own, keeps a memory, runs tasks in the background and on a schedule, and reaches outside services through connectors that Meta's Sentinel system allows, denies or sends to the person for approval.
- Does Muse connect to WorkerKit over MCP? No. Muse reaches an outside service by holding a credential for it and calling its API, rather than by adding an MCP server. So it connects to WorkerKit over the plain-HTTPS API: an account admin creates a manager key, the person enters it through Muse's own hosted API-key entry, and the agent then calls api.workerkit.ai directly with a bearer header, or from the wk CLI in its VM. MCP clients such as Claude and Cursor use the WorkerKit MCP server instead.
- Can Muse read my email or CRM through WorkerKit? No. The manager key Muse holds manages workers and grants no access to any connected app. Workers reach apps, under their own per-app grants, firewall and rules; the fleet surface does not, and no prompt can change that.
- What does the Muse agent need to set this up? A WorkerKit account with admin access, a manager key created at workerkit.ai/fleet-access, and the WorkerKit skill file at workerkit.ai/muse/SKILL.md. The person's part is about a minute: create the key, enter it in Muse. The agent verifies the scopes, installs the skill and runs a smoke test. The whole procedure is at workerkit.ai/muse/setup.
- How does Muse get a worker's results? Two paths. Muse reads them from the fleet feed: one held connection watches every worker on the account, and each run's receipt carries the closing report, a typed digest when the run produced one, and the settled cost. People receive them through the worker's delivery channels: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook. Nothing is pushed into Muse itself, because Meta publishes no inbound surface for it.
- What does it cost? WorkerKit has a Free plan with no card required: 5 workers, 500 tool calls a day and the complete safety layer. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the per-worker and fleet budgets you set. Connecting Muse is not a paid feature.
- Is this the same as Muse Code? No. Muse Code is Meta's terminal coding agent, released in beta on 5 August 2026, and it speaks MCP: it connects to the WorkerKit MCP server with one settings block. Muse is the personal agent, and it connects over the API as described here. Both reach the same fleet.
Ready? The setup guide is written for the Muse agent doing the work, and the API page holds the full contract behind it.