What Is Muse Engineering? Designing Work for a Personal Agent

Muse engineering is the practice of designing work for a personal agent: deciding what outcome you want, what access the agent gets, which path it should take (connector, browser or human), and how it proves it finished. It is a term this site uses, not a Meta product or an official Meta discipline. We use it because the builds in this catalog that work share a pattern, and the prompt is usually the least interesting part of it.

Muse engineering vs prompt engineering

Prompt engineering is about the wording of a single request to a model. You tune the instructions, examples and format until the answer comes back right.

A personal agent like Muse changes what you are designing. According to Meta, Muse keeps working in the background after you close the app, remembers preferences, and acts across email, travel, forms and purchases. It runs inside a dedicated VM, reaches services through connectors, and has a browser for everything else. A good request still matters. But the outcome depends more on four other things:

Prompt engineering asks	Muse engineering asks
What words get the best answer?	What does "done" look like, and what is the agent allowed to decide?
What context goes in the prompt?	What accounts, files and connectors should it touch, and at what permission level?
How do I format the output?	What evidence should it leave so I can check the result?
How do I retry a bad answer?	Where should it stop and hand back to me?

Prompt engineering is one input to Muse engineering. It is not the whole thing.

The five principles

These come from reading the catalog, mostly the entries that worked and a few that did not.

1. Define the outcome and the authority, not the steps

State what done looks like and how much the agent may decide on its own. Chandra Bhavanasi authorized Muse to accept any AT&T fiber offer under $70 a month. He reports it came back with $40 a month plus three months free. The instruction set a ceiling. It did not script the call.

Compare that with a vague "lower my bill". Without a stated limit, the agent either has to stop and ask at every offer, or it guesses.

2. Grant the narrowest access that can finish the job

Muse's controls are granular, so use them. Connectors can be set to read-only. On the Mac, each app is Off, Read only, or Read and interact. Builders in the catalog go further:

• muse-fileapi only exposes whitelisted directories. Writes happen in two phases, and every call goes to an audit log.
• The Muse Proxy for CalDAV stores calendar passwords once and hands Muse scoped keys instead.
• One user screened 50 unread Instagram DM threads with the Messages connector while leaving every thread unread. The task was read-only by design.

3. Prefer a structured path over pixels

If a service has a connector or an API, use it before you let the agent click through a website. Structured calls are faster, easier to audit, and less exposed to prompt injection from page content. When a connector does not exist, have Muse write one. One user got a working Linear connector in under a minute from an API key. David Singleton showed Muse writing its own integration code in the user's VM.

The browser is still useful. It is the fallback, not the default.

4. Make it leave receipts

An agent's summary is a claim. Design the task so the agent produces evidence you can check.

• The delegate-to-muse skill tells the caller to review the diff and re-run the tests "rather than trusting the summary".
• ocodex runs cheap Spark workers and has one paid supervisor audit every claim against a machine-readable ledger.
• The 77k Instagram story census prompt saves cursor state every 10 pages. A long job that stops can resume, and you can see how far it got.

5. Design the handoff before you need it

Some steps need a human: a verification code, a payment, a judgment call. Decide in advance where those points are. When raunaq's Muse called Xfinity, it got through the phone tree to a person but couldn't read a verification text, so it patched him into the live call. That is a good failure, because the agent handed over the conversation instead of giving up.

Meta builds some handoffs in. On the Mac, Muse asks before sending email or making purchases. The Change Verifier connector goes further for payee changes. It returns clear, review or block, and holds the change until a named owner accepts it.

A worked example

Say you want Muse to find recurring charges you have forgotten about and cancel the ones you don't use. Idobn did a version of this: a receipt audit across six months of email that found a $100 a month subscription on a corporate card.

The prompt-engineering version:

Go through my email and cancel subscriptions I don't need.

That gives the agent too much discretion and no way to prove its work. What counts as "don't need"? Can it cancel something tied to a work card?

The Muse engineering version:

Goal: a list of every recurring charge in my Gmail receipts from the last six months, and cancellations for the ones I approve.

Access: read Gmail. Read-only on the Plaid finances connector, to confirm charges actually posted. Do not change any payment method.

Output first: a table with merchant, amount, frequency, last charge date, the card it hit, and a link to the receipt email. Mark anything on a card ending in 4417 (work) separately.

Authority: you may cancel anything under $15 a month with no sign of use in my email in the last 90 days. For everything else, ask me.

Path: use a connector or the merchant's account page. If cancellation needs a phone call or a code sent to me, stop and tell me which ones.

Proof: for each cancellation, save the confirmation email or a screenshot of the confirmation page.

Each principle is in there. The outcome and authority come first, with a dollar threshold. Access is narrow, and Plaid is read-only. The structured path comes before the browser. Every action leaves a receipt. The human handoff is named ahead of time. You can also schedule it: the same brief, run monthly, turns a one-time cleanup into a standing check.

The card number in the example is a placeholder. The pattern is the point.

The architecture principle: connector, browser step, or human?

When you design a task, each step goes to one of three places. Here is how we would decide.

Hand it to a connector when:

• the service has an API or a directory connector (Gmail, Plaid, Ticketmaster, Duffel and others at launch)
• the step repeats, or runs on a schedule
• you want read-only access, scoped tokens, or an audit trail
• the data is sensitive enough that you want Sentinel and credential surrogation in the path (Meta's security design)

Hand it to a browser step when:

• there is no API and the task is a one-off, like the Verizon gift card payment or the Delta compensation claim
• the site allows agents. Amazon blocked Muse purchases as of September 20, so a browser step there will fail. One user worked around it with a self-hosted cart API reached over SSH, which is a connector in all but name.
• a wrong click is cheap to undo

Hand it to a human when:

• a one-time code, CAPTCHA or identity check lands on your device
• the action moves money past your stated limit, or cannot be reversed
• the decision is a judgment call you have not delegated
• the agent has failed the same step twice

A quick rule of thumb: when a step repeats, turn it into a connector. When it happens once, a browser step is fine. When it can't be undone, a person should make the call.

For builders, the rule reverses. If your product keeps showing up as a browser step in users' tasks, that is a sign you should ship a connector. The HVAC and plumbing shop connector takes this approach: quote, hold a slot, book, send a deposit link, check status. Each is a structured call instead of a form the agent has to fill in. Meta's developer platform is where directory connectors are submitted for review.

Frequently asked questions

Is Muse engineering an official Meta term?

No. It is this site's framing for a set of practices we see in working builds. Meta's own documentation talks about connectors, permissions and the Muse Secure VM, and we build on those. We do not claim Meta endorses the term.

How is Muse engineering different from prompt engineering?

Prompt engineering tunes the wording of one request. Muse engineering designs a whole job for an agent that acts over time. That covers the outcome and authority, the access it gets, whether each step uses a connector, a browser or a human, and the evidence it leaves.

Should I build a custom connector or let Muse use the browser?

Use a connector for anything repeated, scheduled, sensitive or high-volume. Use the browser for one-off tasks on sites without an API, where mistakes are cheap to undo. Muse can build a custom connector from an API key, and Meta does not review custom connectors, so check what it built.

How do I stop Muse from doing something I didn't approve?

Set connectors to read-only where possible, and use per-app permissions on the Mac. Write an explicit authority limit into the task, such as a dollar ceiling, and name the actions that need your sign-off. Meta says Muse asks before sending email or making purchases on the Mac. Its own help page also warns that the agent may take unexpected actions.

Where can I see examples of well-designed Muse tasks?

Browse Triage & routing for tasks with clear limits and outcomes, and the Skills shelf for connectors built with scoped access. The Start Here guide has a reading order.