The task ran · the result was wrong

Two emergencies wearing the same face.

Q: It stopped halfway and left a mess. Is that a bug?

No. The work already done stays done, which is reasonable behaviour, but there is no clean summary of where it stopped. Reconciling a half-finished batch by hand is the known weak point, which is why it is worth testing on work you do not care about first.

“It went wrong” means two completely different things when the thing that went wrong can act. Either it changed something and you have a recovery on your hands, or it produced something wrong and you have a re-phrase. Telling them apart is the first move, because the worst thing you can do to the first one is treat it like the second.

The first sixty seconds Which one is mine?

2 kinds of wrong 6 recovery steps 3 causes of bad output Don't re-run it

For an app that will not start, sign in or take a permission, you want Muse not working instead. This page assumes the task ran.

One question splits the whole problem. Everything else follows from the answer.

Before anything else

The first sixty seconds

Stop the run. Do not re-run it.

The instinct when something comes back wrong is to try again, and with a chat assistant that instinct is correct a second answer costs nothing. With an agent it is the worst available move. The same misunderstood instruction gets applied a second time, on top of a state that has already changed, and you now have two passes to unpick instead of one.

It also costs you twice. A run that went wrong still counted against your weekly allowance, and so will the one you fire off in frustration.

So: stop it if it is still going, leave everything where it is, and spend the next minute working out which kind of wrong you are looking at.

If the app never ran the task at all would not start, would not sign in, refused a permission that is a different page: Muse not working.

Triage

Which kind of wrong is this?

One question: is anything different now that would not have been different if you had never run it? Not “is the answer bad” is something changed.

It acted

Something on your Mac is now different

Files moved or renamed, a draft created, a calendar entry added, a form filled. The state of your machine changed, and it changed in a way you did not intend.

A folder does not look the way it did
Names follow a convention you did not ask for
Something exists that you did not create
A batch is half-done and you cannot tell where it stopped

Work the recovery sequence →

It answered

The output is wrong but nothing moved

A list that is incomplete, a summary that misses the point, a total that does not match, an item that does not exist. Annoying, and entirely reversible by closing the window.

You asked it to tell you rather than to do
Nothing on disk has a new modification date
The complaint is about accuracy, not about state
Ignoring the answer completely costs you nothing

Find the cause →

If something left your machine, it is a third case

A message that was sent, or a purchase that completed, cannot be undone by anything on this page. Those actions sit behind a confirmation prompt, which means the recovery path runs through the recipient or the seller, not through your Mac.

Worth knowing rather than dwelling on: it also tells you where the habit needs to change, which is the gate you approved rather than the task you wrote.

It acted

Six steps, in this order

The order is the useful part. Most of the damage people do after an agent mistake comes from doing step five before step three.

Stop the run

If it is still going, end it now. Curiosity about what it will do next is expensive every extra second is more to reconcile later.

Do not re-run the same task

A second run is not an undo. It re-applies the same misreading to a state that has already moved, and it spends another task from your allowance.

Why this is step two: it is the thing people do first, and it is the one action that makes recovery meaningfully harder.

Read the plan it actually ran

The plan is your record of what it set out to do and in what order. Read it before touching anything it tells you where to look, and it usually contains the exact sentence where the misunderstanding entered. What a plan shows.

Work out the blast radius

Only granted areas could have changed. Write down which ones the task had, and treat everything else as untouched rather than searching your whole machine.

The quiet benefit of narrow grants: a small blast radius is mostly what makes a bad task survivable. The permission layers.

Undo newest first

Work backwards from the most recent change Finder’s undo for a rename or move you have just seen, the Trash for anything removed, a backup snapshot from before the run for a batch too large to unpick by hand.

Why backwards: reversing in the order things happened means fighting your own half-finished corrections.

Re-instruct only once the state is stable

Never hand a corrected instruction to an agent working on a half-reverted folder it cannot tell your cleanup apart from the original mess. Get back to a known state, then state the rule precisely enough that you could apply it yourself.

Renames, moves and filing are usually reversible. A half-finished batch is the awkward case, because the work already done stays done and there is no clean summary of where it stopped which is exactly why it is worth testing an interruption on work you do not care about, before you need to.

It answered

Three reasons the output was wrong

When nothing changed, the question is not “how do I fix this” but “why did it come back like that” because the answer determines what you change in the instruction, and a re-run without that change tends to produce the same thing again.

Nearly all bad output traces to one of three causes. They have different tells and different fixes, and none of them looks like a failure when it arrives. Each one hands you a finished, confident, plausible result.

You are not debugging a crash. You are working out which of three silent things happened to a task that thinks it succeeded.

Two of the three are catchable in the plan before a run ever starts, which is the practical reason reading it is worth ten seconds every time.

Three causes, three different edits to the instruction. The re-run is the easy part.

It guessed, and did not say so

Cause one

Your instruction had more than one reasonable reading and it picked one. The guess is usually sensible, which is exactly why it slips past it appears in the plan as a stated intention rather than as a flagged assumption, and those look very different at a glance.

How to tell: the output is internally consistent and completely reasonable, just not what you meant. Re-read your own request and count the readings.

The instruction fix: state the rule rather than the goal, and say what to do with anything that does not fit it.

Rename every file in this folder to supplier-date-amount. If a file is missing any of those three, leave it untouched and list it separately.

It drifted across a long batch

Cause two

Correct on the first few items and quietly inconsistent by the end. Consistency at scale is a different skill from correctness at the start, and this is the one cause the plan cannot catch the plan is written before the work happens.

How to tell: spot-check the last ten items rather than the first ten. If the beginning is right and the end is not, this is your cause.

The instruction fix: make the rule mechanical enough to have no judgement in it, and run a small batch first to confirm the convention before letting it loose on two hundred.

Do the first ten only and stop. Show me the result before continuing.

It produced something rather than nothing

Cause three

You asked for something that was not there, and instead of an empty result you got the nearest thing that resembled it offered without much hedging. An agent under pressure to return output will return output.

How to tell: check one item in the result against the source by hand. If the first one you check does not exist where it claims to, this is your cause.

The instruction fix: make “nothing found” an explicitly acceptable answer, and ask for the gaps as a deliverable in their own right.

List anything you could not find as a separate list. Do not substitute a similar item.

Same three causes we found running the test battery, which is where the tells came from. Two of the three are visible in the plan before a run starts; drift is the one that is not.

Next time

Four habits that make this rarer

None of them is a setting. All four are things you do in the ten seconds before a run.

Read the plan, every time

It is where a guess appears as an intention, and where a step that does not match your request gives the whole thing away. Ten seconds, and it catches two of the three causes above. What to look for.

Make the first run small

Ten files, not two hundred. A convention you can check by hand once is a convention you can trust at scale and a mistake on ten items is an afternoon saved rather than lost.

Grant narrowly

The blast radius of a bad task is exactly the set of areas it could reach. Areas you have not granted are areas you never have to check afterwards. How grants work.

Say what to do with exceptions

Most bad output comes from the cases your rule did not cover. Naming them leave untouched, list separately, stop and ask removes the room in which a silent guess happens.

Reinstalling the app is not on this list, and does not belong on it. A task that ran and got it wrong is an instruction problem or a recovery problem; a broken installation is a different page entirely.

Related help:

FAQ

When a task goes wrong

Muse did the wrong thing to my files. What do I do first?

Stop the run and do not re-run it. A second attempt applies the same misunderstanding to a state that has already changed, and it costs another task. Read the plan it executed, work out which granted areas could have been touched, then undo newest first. The sequence.

Can I undo what an agent did?

Often, but not always. Renames, moves and filing are usually reversible through Finder or a backup taken before the run. Anything that left your machine a sent message, a completed purchase is not, and those are the actions that sit behind a confirmation prompt.

The output is wrong but nothing changed. Is that the same problem?

No, and treating it the same way is the common mistake. A wrong list or a wrong summary is a verification problem with no urgency at all. Fix the instruction and run it again rather than starting a recovery you do not need. The three causes.

Why did it do something I never asked for?

Usually because the instruction had more than one reasonable reading and it chose one without flagging that it was choosing. The guess normally appears in the plan as a stated intention, which is why reading the plan catches this class of problem before it runs.

It worked on the first few files and then drifted. Why?

Consistency across a long batch is harder than correctness at the start, and the plan cannot catch it because the plan is written before the work happens. Spot-check the end of a batch rather than the beginning.

It gave me something that does not exist. What went wrong?

When the thing you asked for is not there, an agent under pressure to produce output may offer the nearest resembling thing instead. Adding a standing instruction to flag anything it could not find changes this noticeably.

Does a task that went wrong still count against my weekly limit?

Assume it does, because the work was performed either way. That is the practical argument against re-running blindly a bad instruction run twice costs two tasks and leaves a worse state. How the meter works.

It stopped halfway and left a mess. Is that a bug?

No. The work already done stays done, which is reasonable, but there is no clean summary of where it stopped. Reconciling a half-finished batch by hand is the known weak point worth testing deliberately on work you do not care about.

Should I reinstall the app after a bad task?

No. Reinstalling addresses a broken installation, which is a different problem entirely. A task that ran and got it wrong is an instruction problem or a recovery problem, and removing the app fixes neither.

How do I stop this happening again?

Read the plan before every run, keep the first run of any new rule small enough to check by hand, and grant only the areas a task actually needs so a mistake has less to reach. The four habits.

Stop first · undo second · re-run last

The instinct to try again is the expensive one.

With a chat assistant a second attempt is free. With an agent it is a second pass over a state that already moved and another task off the meter.

The recovery sequence It will not start at all

Two kinds of wrong
Six recovery steps
Three causes of bad output
Reinstalling fixes neither

Independent guide not affiliated with Meta. Recovery depends on what was changed and what you had backed up beforehand; nothing here can reverse an action that already left your machine. Four habits that make it rarer.