# 5.2 Brief the outcome, not the steps (/managing-ai-workers/the-four-part-brief/outcome-not-steps)

---
type: Document
title: "5.2 Brief the outcome, not the steps"
description: "Why a brief describes the result instead of the steps, and how to tell which steps still belong in it."
status: stable
order: 205.2
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-05T08:59:51Z
chapter: "05"
part: II
expert_status: required
concepts: [ "5.2" ]
last_verified: 2026-10-06
sources:
  - id: v1-just-delegate-it
    title: "Just Delegate It (Panaversity, first edition, verified 2026-10-06)"
    resource: https://agentfactory1.panaversity.org/docs/just-delegate-it-crash-course
generated:
  at: 2026-11-05T08:59:51Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** You give a taxi driver turn-by-turn directions and miss the closed road the driver knew about.

An outcome describes what exists when the work is done. Someone else should be able to tell from it whether the work is finished. "Get the payment run ready" fails that test. This passes it: "Mark every open invoice *pay*, *pay after approval*, *hold* or *not due*, with a reason. Pay covers invoices due on or before October 30." Anyone can check the result: does every invoice have a mark and a reason? End the outcome with that test, in one sentence that starts "Done when": "Done when every open invoice has a decision and a policy section." It tells the worker when it has finished, and it gives you the first check for the result. A check like this takes one of two forms. It can be a yes or no, as this one is. Or it can be a number to match: "Done when the CSV has as many rows as there are open invoices" (5.7). "Done when it looks good" is neither. The worker cannot tell when to stop, and you have nothing to check. Ask for a result you can review before anything is approved. The proposal comes back first, and Dave's approval is the last step, not a question halfway through.

Steps describe the method, how to do the job. They feel safer. But the result can only be as good as your steps, and a worker that follows orders rarely questions them. Maria's step 2 used the wrong payment terms, and the worker carried out the error instead of noticing that the vendor record disagreed. An outcome lets the worker choose the method, and lets you compare the result with what you asked for.[^v1-just-delegate-it]

Some steps still belong in a brief. Write a step when it is a **control**. A control is a step required by policy, by law or by a system that uses the result. "Take payment terms from the vendor record, never from the invoice" is a control, because Brightline's AP policy says the vendor record is the authority on terms. It is a rule about which source to trust, so it goes in the context. "Do not change the invoice list" is a control too. It limits what the worker may do, so it goes in the constraints (5.1). "Sort by vendor" is only a preference. If it matters to you, put it in the format. If not, leave it out.

The test is one question: *would a capable new colleague be wrong to do this another way?* If yes, write the step. If no, leave the method open. A new colleague who took the terms from the invoice, or edited the invoice list, would be wrong. So those steps go in. One who sorted by invoice number instead of vendor would not be wrong. So that step stays out.

![Three columns under the title Between too little and too much. On the left, too little: Dave's one line, "Get this week's payment run ready. Everything's in the AP folder," with outcome, context, format and constraints each marked guessed, and a note that missing details become assumptions. In the middle, in gold, the Four-Part Brief. Outcome: what should exist when done. Context: who it's for, why, and sources. Format: its shape and destination. Constraints: rules, and what it may do alone. Below them: keep required controls, from policy, law and system requirements. On the right, too prescriptive: Maria's fourteen steps, with step 2, use the terms printed on each invoice, marked with a warning sign. The wrong source gives the wrong due date: the vendor record says Net 15, the invoice says Net 45. A note says a detailed method can preserve a mistake. A footer reads: describe the result, specify the controls, leave the method open.](img/too-little-too-much.png)

*Figure 5.1. Between too little and too much. The Four-Part Brief describes the result and names only the steps that are controls.*

[^v1-just-delegate-it]: Just Delegate It, Panaversity, first edition.