# 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-10-06T13:16:37Z
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://agentfactory.panaversity.org/docs/just-delegate-it-crash-course
generated:
  at: 2026-10-06T13:16:37Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87
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?

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 policy section 2 says so. "Do not change the invoice list" is a control. "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, format, inputs and autonomy 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. Format: its shape and destination. Inputs: the sources, and which rules govern. Autonomy: what it may do without asking. 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.