Meta's Muse Is Here. Is Your API Ready for Its Users?

Your next user won't open your app

On September 8, Meta launched Muse, a personal AI agent that sends emails, books travel, fills in forms and checks out on your behalf. It is rolling out in the US on iOS, Android, the web and WhatsApp, with a free tier and paid plans at $20 and $100 a month.

Most of the coverage asked one question: will people trust Meta with their inbox and their card? If you build or run an API, there is a more practical one. When a Muse user says "rebook my flight" or "cancel that subscription," how does the agent actually reach your product, and does it reach it well?

That question is the agentic era in one line. A growing share of your users will never open your app or read your docs. They will send an agent to do it for them.

What Muse actually is

Muse is less a chatbot than a small, supervised computer that works for one person. Strip away the launch video and you get six parts:

• A private VM per user. Each person gets an isolated cloud virtual machine with its own built-in browser, so the agent keeps working in the background when nobody is watching (Fox Business).
• Sentinel, a gatekeeper agent. A separate system controls Muse's access to the internet and connected services. Users can split read from write access, and set finer permissions inside a single service (Axios).
• Credentials the model never sees. Passwords and payment details sit in a secure store and are used without being shown to the agent (YourStory).
• Approvals and an audit trail. Real actions such as sending an email or spending money need explicit approval, and every action is logged (SoyaCincau).
• Connectors. Meta's catalog of integrations, plus custom connectors Muse can write itself for services that expose an API or CLI. More on this below.
• The Muse Spark models. Meta's agentic model family. The developer API for Muse Spark 1.1 has been in public preview since July, is OpenAI-SDK compatible, and Meta's own testing puts it ahead on tool-use benchmarks such as MCP Atlas (ProPakistani).

Look at how much of that list is about access. Meta spent its launch explaining which services the agent may call, with which permissions, using which credentials, and how each call is recorded. That is API governance, rebranded for consumers.

Two roads into your product: the browser or the API

When Muse needs to act inside a service, it has two ways in, and only one of them is good for you.

The browser road. Muse opens your site in its VM, reads the page, clicks buttons and fills forms, just as a person would. It needs no partnership and works on almost any site. It is also slow, brittle (a renamed button breaks the flow) and nearly impossible to scope. A logged-in browser session cannot tell "read my invoices" from "close my account."

The API road. Muse calls a connector: a built-in one, an aggregator, or one it writes itself against your API. Calls are fast and deterministic, permissions map to real scopes, and both sides can log what happened. This only works if your API is discoverable, described accurately and safe to hand to an agent.

Sentinel's read-versus-write switch only means something on the API road. So the browser is what agents fall back to when your API is not ready. Every time an agent scrapes your UI instead of calling your API, your API has lost a user it should have had.

Connectors are the new app store

Muse's connectors decide which products its users can actually reach, which makes them a distribution channel. There are three ways in today:

1. Built-in connectors. Meta builds these with the service provider and writes the skills that use them. They run in a privilege-separated worker, so the agent never touches the OAuth token (Parallel).
2. Aggregators over MCP. On September 29, Zapier became a named connector, giving Muse access to more than 9,000 apps through its hosted MCP endpoint, limited to the apps and actions each user approves.
3. Custom connectors. A user can ask Muse to build a connector for any service with its own API or CLI. Muse fetches the API information itself and stores keys in its credentials store. Meta does not review these connectors, so the user is trusting the provider directly (Parallel).

The consumer app has no "add MCP server" setting yet. Meta's coding agent, Muse Code, accepts MCP servers directly, and providers can submit an MCP server or API to Meta's connector catalog (Skills Playground).

In Muse Code, a remote MCP server is a few lines in ~/.config/muse/settings.json:

{
  "mcp_servers": {
    "your-api": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

The third road is the one API teams should think hardest about. For a custom connector, your published spec and docs are the integration. Muse reads whatever you have published and writes code against it on a real user's account. If your OpenAPI file is a year stale, your auth flow lives in a wiki, and a third of your endpoints are undocumented, the connector Muse builds will be wrong, and nobody at Meta will catch it.

API docs used to be written for a developer who would read carefully, ask in Slack and test in a sandbox. Now the first reader may be a model that reads once, generates a client and acts immediately.

What an agent-ready API looks like

An agent-ready API is one an agent can find, understand and call safely without a human translating. In practice that means seven things:

Requirement	Why agents need it
A complete API catalog	Agents find undocumented endpoints. You should find them first.
A contract as the source of truth	An OpenAPI spec that matches the running code is what a custom connector is built from.
Scoped access per consumer	Read and write scopes, per partner and per agent, so "read-only" on the agent side means read-only on yours.
A hosted, authenticated MCP server	A native door for agents, instead of each one writing its own client from your docs.
Docs written for a model reader	Clear descriptions, real examples and explicit error semantics. The model cannot ask a follow-up question.
Logs and usage per consumer	You need to see when agent traffic arrives and what it does.
Drift detection	When code and contract diverge, a person reviews it before agents call the changed endpoint.

The docs row is the one teams underestimate. Here is an endpoint described for a human who can ask a colleague:

/v1/sub/{id}:
  delete:
    summary: Delete sub

And the same endpoint described for a model that cannot:

/v1/subscriptions/{subscription_id}:
  delete:
    operationId: cancelSubscription
    summary: Cancel a subscription at the end of the current billing period
    description: >
      Stops the subscription from renewing. The customer keeps access until
      current_period_end. This cannot be undone; to resume, create a new
      subscription.
    security:
      - oauth2: [subscriptions:write]
    responses:
      "200":
        description: Subscription scheduled to cancel. Returns the updated subscription.
      "409":
        description: Subscription is already cancelled.

The second version tells an agent what the call does, what it cannot undo, which scope it needs and what each failure means. That is the difference between a connector that works and one that cancels the wrong thing.

None of this is new to good API teams. What changed is the cost of skipping it. A human developer works around a stale spec. An agent acting for a user just gets it wrong.

A door, or a window

Muse is one agent. Every major AI company now ships one, and each will reach your product somehow. The only question is whether it comes through a door you designed, with scopes, logs and a contract, or through a window it found in your UI.

The agentic era rewards APIs that are known, governed and callable. Start with the checklist above, and read your API the way an agent will: through your spec, your docs and your scopes.

What about you: is your API ready for agent traffic, or are agents already scraping your UI? I'd love to hear in the comments.