Writing a goal an agent can actually finish

A chat prompt asks for an answer. A Cowork goal specifies a finished state that someone else will produce while you are not watching. That is closer to briefing a contractor than to asking a question, and it fails in the same ways briefs fail.

The four parts

The outcome. What exists when this is done, in what form, where. "A markdown table at the top level of this folder" beats "a summary".

The boundary. What it may touch and what it must leave alone. This overlaps with folder scope without being the same thing: scope is enforced, the boundary is instruction. Say both.

The ambiguity rule. What to do when the input does not fit the task. This is the part almost everyone leaves out, and it is the part that determines whether you can trust the output.

The stopping condition. When to come back and ask rather than press on.

A worked example

Too vague, and you get something plausible you cannot check:

Go through the contracts folder and summarise the important stuff.

Over-specified, and you have written a program badly:

Open each PDF. Use pdftotext. Search for the string "Notice Period". Take the next 40 characters. If that fails, try "notice period" lowercase…

About right:

For every contract PDF in this folder, extract the counterparty, the end date, and the notice period. Produce one markdown table sorted by end date, saved as contract-summary.md in this folder.

Do not modify any of the source PDFs.

Where a field is missing or genuinely ambiguous, write "unclear" rather than inferring it, and list those files with a one-line reason in a section below the table.

If more than a quarter of the files turn out not to be contracts, stop and tell me instead of finishing.

The last two paragraphs are what make the result reviewable. Without them, the table is uniformly confident and you have no idea which rows to check.

Why "leave the method alone"

Prescribing steps constrains it to your guess at the approach, which is usually worse than the one it would have found, and it makes the run brittle: one wrong assumption in your procedure and it follows you off the cliff. Specify the destination and the guardrails; leave the route open.

The exception is when the method genuinely is the requirement — a house format, a mandated tool, an order of operations that exists for a reason. Then it is a constraint, and it belongs in the boundary.

Try this

Take a goal you have already written and add exactly one sentence: what to do with the cases that do not fit. Run both versions on the same folder and compare the outputs. The difference in how much of the result you can trust is usually larger than the difference in the result itself.

What goes wrong

No ambiguity rule. The single highest-value omission. An agent asked to fill a column will fill the column, and a guess looks exactly like a fact in a table cell.

No stopping condition. Without one it will complete the task as literally described even after the task has stopped making sense — thirty rows of nonsense in place of one question.

Confusing scope with instruction. "Do not modify the sources" is a good sentence and a bad protection. If it genuinely must not write there, connect a folder where it cannot.

Asking for judgement you cannot audit. "Flag anything concerning" produces a list you cannot evaluate, because you do not know what it did not flag. Ask for the criterion instead of the conclusion.

How to check it worked

Read the "unclear" list before the main output. If it is empty on input you know is messy, the goal was under-specified and the confident-looking result is the thing to distrust.