D2 · Defining Objectives and Tasks

This is one of the two heaviest domains — 18%, about 9 of 50 items on our mock. It tests whether you can turn a wish into a brief an agent can actually execute and you can actually verify. Most failed delegations are decided here: an agent given a vague objective produces vague work, and you cannot tell whether it succeeded because you never said what success was. The skill this domain rewards is writing the objective, not writing the prompt.

What you need to know

A delegable objective has five parts: a goal (the outcome, stated as a result not a task list), a definition of done (the acceptance test you’ll check against), constraints (what it must and must not do), sources of truth (which inputs are authoritative), and checkpoints (where it pauses for you). The goal says what; the definition of done says how you’ll know; constraints and sources bound how; checkpoints control when you get to steer. When an objective is ambiguous, the correct move is almost never to let the agent guess — it is to sharpen the brief, or to instruct the agent to ask before proceeding on the ambiguous point. A good brief is one you could hand to a capable new hire who will not ask clarifying questions.

Learning objectives

By the end of this page you should be able to:

1. Write an objective as a result with a testable definition of done.
2. Separate constraints from the goal, and hard constraints from preferences.
3. Name the sources of truth an agent should treat as authoritative, and rank them when they conflict.
4. Place checkpoints where the risk or uncertainty is highest.
5. Handle an ambiguous objective without letting the agent silently guess.
6. Diagnose a failed delegation as a brief defect before blaming the model.

2.1 Goal: state the outcome, not the keystrokes

The most common briefing error is describing the steps you’d take instead of the result you want. Steps constrain an agent to your path and stop it adapting; an outcome lets it plan while still being checkable.

2.2 Definition of done: the acceptance test

The definition of done is what separates a delegable task from a wish. It is the checklist you will run against the result — so it must be observable, not a feeling.

GOAL:  Produce a competitor pricing summary for the leadership deck.

DEFINITION OF DONE (checkable):
  [ ] Covers all four named competitors
  [ ] One price point per product tier, sourced to a public page with a link
  [ ] A one-line "what changed since last quarter" per competitor
  [ ] Fits on one slide (≤ 6 bullets)
  [ ] Flags any figure it could not verify rather than guessing

A good definition of done does three things: it tells the agent when to stop, it tells you what to check, and — crucially — it tells the agent what to do when it can’t meet a criterion (flag it, don’t fabricate it). Compare that to “make a pricing summary”, where neither party knows what “done” means.

2.3 Constraints: hard rules versus preferences

Constraints bound how the work is done. The critical distinction is between hard constraints (violating them makes the output unusable or unsafe) and preferences (nice to have). An agent that treats a preference as hard wastes effort; one that treats a hard constraint as a preference produces unusable or unsafe work.

Write hard constraints as prohibitions the agent must respect (must not, only, never) and mark preferences as such. D4 develops the further point that a hard constraint on an irreversible action often needs to be enforced by the system, not merely stated in the brief.

2.4 Sources of truth: what is authoritative

An agent will happily blend an authoritative figure with a stale one from the open web unless you tell it which source wins. Naming sources of truth — and ranking them — is what keeps a delegation grounded.

        conflict resolution order (example)
        ┌────────────────────────────────────────┐
   1 ►  │ the document I attached to this task     │  most authoritative
   2 ►  │ approved company knowledge / policy      │
   3 ►  │ the live system of record (tickets, CRM) │
   4 ►  │ the public web                           │  least — and flag it
        └────────────────────────────────────────┘

2.5 Checkpoints: where to pause for a human

Checkpoints are the steering points you build into the objective. They belong where uncertainty or risk is highest — not evenly spaced, and not only at the end. A checkpoint at the end is a review; a checkpoint mid-run is a chance to correct course before wasted work compounds.

The “one before many” checkpoint is the highest-value one on this exam: have the agent do the first item, pause, let you approve the approach, then run the rest. It converts a fifty-way mistake into a one-way one.

2.6 Handling an ambiguous objective

When the objective is ambiguous, letting the agent silently pick an interpretation is the wrong answer nearly every time. There are three legitimate moves, in order of preference:

1. Resolve it yourself before delegating — the cheapest fix when you know the answer.
2. Instruct the agent to ask on the specific ambiguous point before proceeding (a checkpoint on the fork).
3. State an explicit assumption the agent should make and surface, so you can catch a wrong one at review.

Objective is ambiguous
│
├─ Do I know the right interpretation?      ── yes ─► resolve it in the brief
├─ Is it a single, identifiable fork?       ── yes ─► tell the agent to pause and ask
└─ Many small unknowns I can't pre-answer?         ─► tell it to state its assumptions
                                                      and flag them for review

The trap answer is “let the agent decide and move fast”. Speed bought by an unstated wrong assumption is a false economy — you pay it back in rework, and worse if the assumption drove an irreversible action.

2.7 A failed delegation is a brief defect first

When an agent returns the wrong thing, the disciplined response is to interrogate the brief before the model. Most failures map to a missing brief element.

This mindset — brief first, model second — is developed fully in D6. Here the point is that a strong objective prevents most failures before they happen.

Decision framework

Use the GDCSC brief — Goal, Done, Constraints, Sources, Checkpoints — as the five-part template for every delegation. If any row is blank, the task isn’t ready to hand off.

Apply it tomorrow: take any task you’d delegate, fill all five rows, and hand off only when none is blank. A blank row is exactly where the delegation will fail.

Common mistakes

Scenario challenge

Scenario. Devon, a marketing manager on ChatGPT Work, delegates: “Put together a competitive summary of our top competitors’ pricing for the board deck next week.” An hour later the agent returns a two-page document. It covers three competitors (Devon has four), mixes current prices with figures that turn out to be a year old, invents a price for one tier it couldn’t find, and is written as flowing prose that won’t fit on a slide. Devon’s first instinct is that the agent “isn’t good enough” and asks whether a more capable model would fix it.

Expert reasoning trace.

1. Interrogate the brief before the model. Every failure here maps to a missing GDCSC element, so a bigger model would produce the same shaped errors faster. This is a brief defect, not a capability defect.
2. Goal defect. “Put together a competitive summary” is a task, not an outcome — there’s no statement of what the finished artefact must contain, so the agent chose its own scope and stopped at three competitors.
3. Definition-of-done defect. No acceptance test meant nothing checked coverage of all four competitors, one price per tier, or slide-fit. “Done” was left to the agent’s judgment.
4. Sources-of-truth defect. No authoritative source was named, so the agent blended current and year-old figures freely — the classic missing-source symptom.
5. Failure-handling defect. Nothing told the agent what to do when it couldn’t find a price, so it fabricated one instead of flagging the gap.
6. Constraint/format defect. No format constraint (“fits one slide, ≤ 6 bullets”) meant it produced two pages of prose.
7. The fix. Rewrite the objective with all five GDCSC rows: goal = a one-slide competitor pricing summary; done = all four competitors, one sourced price per tier, a change-since-last-quarter line, ≤ 6 bullets, gaps flagged not filled; sources = the shared pricing sheet first, then the competitor’s public page, flag anything unverifiable; constraints = only public pricing, never internal deal terms; checkpoint = pause after the first competitor so Devon can approve the pattern before the agent does the other three.

The point. A more capable model was the wrong lever. The delegation failed because the brief was missing four of its five parts; fixing the brief fixes the output, and the “one before many” checkpoint would have caught the scope and format problems after one competitor instead of after all of them.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• A delegable objective has five parts — Goal, Done, Constraints, Sources, Checkpoints (GDCSC); a blank row is where the delegation will fail.
• State the outcome, not the keystrokes; steps constrain the agent and hide the acceptance test.
• The definition of done is an observable, bounded, failure-aware checklist — it tells the agent when to stop and you what to verify.
• Distinguish hard constraints (must/never) from preferences; agents need to know which they can override.
• Name and rank sources of truth; blended stale and current data is a missing-source symptom, not a model problem.
• Put checkpoints where risk is highest — before irreversible steps and before scaling one item to many.
• Handle ambiguity by resolving it, telling the agent to pause and ask, or having it surface assumptions — never by letting it guess silently.
• Diagnose a failed delegation as a brief defect first; a bigger model rarely fixes a vague objective.