Say the outcome, not the steps.
Everyone arrives at Muse with chatbot habits, and the first few tasks go sideways because of it. A chat prompt asks for words back, so you describe the answer you want. An agent task asks for a change in the world, so you describe the state you want to end up in and then three things a chatbot never needed: the scope, a boundary, and how it knows it has finished.
Three habits that work on a chatbot and fail on an agent
Listing the steps. With a chat assistant, spelling out your process helps. With an agent it competes: Muse forms its own plan, and a half-described route just gives it two plans to reconcile. Describe where you want to end up and let it work out how. Give steps only when the order genuinely matters and say why, so your constraint does not get optimised away.
Leaving the scope implied. A chatbot with a vague question gives a vague answer and no harm is done. An agent with a vague scope picks one, and picking is where runs go wrong. “Tidy up my files” contains no folder, no date range and no definition of tidy. Nearly every “why did it touch that?” traces back to this.
If you cannot say what it must not do, you are not ready to hand over the task. That sentence is the cheapest safety feature you have.
Walking away immediately. The appeal is that it works while you do something else, and eventually it will. For the first several runs, stay and watch. You are not supervising the software so much as learning how it interprets you which is exactly what makes later runs safe to leave alone.
One thing that carries over unchanged: correcting beats restarting. “You put the June ones in the wrong folder, move those” is better than rewriting the whole task. What Muse is · how it differs from Meta AI.
Four parts, and the two people always leave out
Tidy up my downloads folder.
An outcome, sort of, and nothing else. No date range, no definition of tidy, nothing it must not do, and no way to know when it has finished. It will make four decisions you never made.
File every PDF in Downloads from the last 30 days into folders by month. Do not delete anything or touch other file types. Show me the list when you are done.
Outcome, scope, boundary, finish condition. Twenty-eight words longer and there is almost nothing left to guess at.
The outcome is the state you want to exist afterwards. Not “sort my files” but “every receipt in a folder named for its month”. Describe the end, not the journey.
The scope is which things. Which folder, which week, which account, which file types. This is the part people skip most and the part that causes the most trouble an unstated scope is not an empty one, it is one the agent fills in for you.
The boundary is what it must not do. Do not delete, do not send, do not spend, do not touch anything outside that folder. Stating it in the task is cheaper than catching it at the confirmation prompt, and far cheaper than catching it afterwards.
Boundaries are not paranoia, they are precision. “Do not touch other file types” is you saying what you meant, not you distrusting the software.
The finish condition is how it knows it is done: a file in a named place, a list in the panel, a total reported back. Without one, an agent decides for itself when the job is complete, and its idea of complete may be narrower or wider than yours.
Five first tasks, in order of nerve
Each one exercises a bit more of what Muse can reach. Do them in this order and you will know whether you trust it before anything irreversible is on the table.
Sort a folder you could rebuild
“File every PDF in Downloads from the last 30 days into folders by month. Do not delete anything. Show me the list when you are done.” The whole loop, with nothing at stake.
Reversible · files onlyFind something and summarise it
“Find the invoice from Harper in my files and tell me the amount and the due date. Do not move or change anything.” Reading only a good test of whether the scope you gave was clear.
Read-onlyTurn your calendar into a note
“List next week’s meetings with who is in each one, as a note called Week Ahead. Do not change any calendar entries.” Now two areas are involved, which is where plans get more interesting to read.
Two areas · creates one noteDraft something it will not send
“Draft a reply to Priya’s last message saying I need until Friday. Leave it as a draft do not send it.” This is the one to run while watching, because the boundary is doing real work.
Drafts · does not sendLet one thing through the gate
Only once the first four have behaved: a task that ends at a confirmation prompt, so you see the gate for yourself. Read it properly rather than clicking through. What it asks about.
Reaches the gate · you approve
Then repeat whichever one behaved. Trust is per kind of task rather than global: a sort that has gone well four times is the one you can walk away from, while a new shape of task starts back at the first rung. And if a task stalls or the agent cannot reach something it needs, that is usually a permission you have not granted yet rather than a fault when Muse is not working.
How to read a run while it is happening
Four things appear on screen during a task. Knowing what each is for turns watching into something useful rather than anxious.
| What you see | What to do | Why |
|---|---|---|
| The plan names a folder you did not mean | Stop now Correct the scope and run it again. | Nothing has happened yet. This is the one free correction in the whole run. |
| A step touches an area you did not expect | Stop and look Ask what it was for before continuing. | Usually a loose scope rather than anything sinister, but it is worth knowing which. |
| It asks a question mid-run | Answer it Then fold the answer into the task next time. | The question is telling you which part of your task was underspecified. |
| A confirmation prompt appears | Read it properly Approve only if it matches what you asked for. | Meta classes some actions as sensitive and stops. Clicking through defeats the only gate there is. |
| It finishes but the result looks thin | Say what is missing Do not rewrite the task from scratch. | Correcting keeps the context. A fresh task throws away everything it already got right. |
| It finishes and you cannot tell if it worked | Note that Your finish condition was not checkable. | A task you cannot verify at a glance is a task that was not ready to delegate. |
Four things to keep off the list for now
Not forever, and not because the software is untrustworthy because these are the ones where being wrong costs something you cannot get back.
Anything irreversible
Deleting, overwriting, submitting. Give it the version that files and drafts, and keep the version that removes and sends for later if ever.
Anything that spends
Purchases sit behind a confirmation, which is the right design, but a task built around spending is not a good way to learn how it reads you.
Client and confidential material
An agent working inside your apps reaches more than a chat box does. If a confidentiality clause covers it, keep that area ungranted. What each area covers.
Anything you could not check
If you could not tell a good result from a bad one at a glance, you cannot supervise it. Do that task yourself until you can describe what right looks like.
One more, quieter risk worth knowing: anything that both reads content and acts can be influenced by the content it reads, which is true of every agent product rather than this one in particular. Per-area access and the confirmation gate exist for that reason. More on the shape of the risk.
Beginner questions
How is asking Muse different from prompting a chatbot?
A chatbot prompt asks for text back, so you describe the output. An agent task asks for a change in the world, so you describe the state you want to end in plus the scope, a boundary and how it knows it has finished. The four parts.
Should I tell it the steps to take?
Usually not. It plans its own route and a list of steps competes with that plan. Give steps only when the order genuinely matters, and say why, so your constraint does not get optimised away.
What should my first task be?
Something reversible in a folder you could rebuild sorting files into dated subfolders is the classic. It exercises the whole loop with nothing at stake if it misreads you. The first five.
Can I stop a run once it has started?
Yes, and you should whenever the plan looks wrong rather than hoping it corrects itself. Stopping leaves a partly-done job, which is exactly why a first task should be one where partly-done is harmless.
Why did it do something I did not ask for?
Almost always an unstated scope. If the task did not say which folder, which week or which account, it picked one. Name the scope and the behaviour usually disappears. Reading the run.
Does it remember how I like things done?
Do not count on it. Treat each task as self-contained and restate your preferences, in the same way you would restate a writing sample to a chat assistant. Keeping your good tasks in a note saves retyping them.
What should I not hand it yet?
Anything irreversible, anything that spends money, anything under a confidentiality obligation, and anything where you could not tell a good result from a bad one at a glance. The four.
How much should I watch it?
Closely for the first several runs, because you are learning how it interprets you rather than checking up on it. Once a particular kind of task has gone well a few times, that kind is the one you can leave alone.
What does a confirmation prompt mean?
Muse has reached something Meta classes as sensitive, such as sending or purchasing, and will not proceed without you. Read what it says rather than clicking through it is the only gate in the run. More.
It keeps asking me questions instead of working. Why?
Usually the task was underspecified in a way it cannot safely resolve. Answer once, then fold that answer into how you phrase the task next time so it does not have to ask again.
Two sentences. Four parts. Watch it run.
The outcome, the scope, what it must not do, and how it knows it is finished. Everything else is practice.
Independent guide not affiliated with Meta. Descriptions of confirmations and permissions reflect Meta’s own published statements; read them yourself before granting access.