The problem

Most people get mediocre output from AI and blame the model. In practice the model is usually just reflecting the vagueness of the ask back at them. “Help me with this deck” or “summarize this transcript” doesn’t tell an agent what the actual outcome should be, what materials it can trust, what’s off-limits, or when to stop — so it guesses, and the guess looks plausible but isn’t useful. This gets worse as models get more capable and more autonomous: an agent that can run for hours, edit files, and return a near-finished artifact needs a real work order up front, not step-by-step hand-holding it will outgrow in the same session. The same failure shows up at company scale, not just at a single desk. Teams handing off work to agents — for research, drafts, code, analysis — hit the identical problem multiplied across every person doing it their own way: nobody defines what “done” means, nobody says what sources are authoritative versus background, and the result is output that looks finished but has to be redone, with no consistent standard for catching that before it ships.

The approach

I built this as a course around a six-field brief framework — Goal, Context, Sources, Constraints, Quality Bar, Definition of Done — adapted from Nate Jones’s “Useful Question” approach. The idea is to name the actual outcome (not the activity), the background a colleague joining late would need, which materials are authoritative vs. background vs. off-limits, the real-world boundaries that make technically-correct output practically wrong, what would make the result genuinely good rather than just shaped like the deliverable, and exactly what comes back and when it’s finished. The posture is a flashlight: you have to name both the center (intent) and the edges (scope) — telling an agent what to leave out is often more useful than telling it what to include.

The course ships with three standalone prompts designed to run in sequence in Claude, ChatGPT, or Gemini, each one built to ask the user the questions they should be asking themselves before delegating: the Useful Question Builder walks all six fields conversationally and assembles a paste-ready brief from scratch (and tells you when a task is too simple to need one); the Vague Ask Auditor takes a request you’ve already written and diagnoses it field by field — what’s here, what’s missing and what that will break, what’s ambiguous — flagging hollow words like “better” or “cleaner,” then rewrites the request in your own register; and the Definition-of-Done Generator is for when the task is clear but “finished” isn’t, producing a deliverable spec, completeness checklist, quality standard, checkpoints, and boundaries in both compact and expanded form. All three share guardrails: they never execute the task themselves, never invent context on your behalf, calibrate overhead to the stakes of the task, and use your own words for what “good” means rather than prompt-engineering jargon.

What I learned

The two fields people skip aren’t random — they’re the two that actually cost the most when skipped. Almost everyone states what they want but not what would make it good, so the agent optimizes for the visible shape of the output instead of whether it does the job; and almost everyone treats a definition of done as bureaucratic overhead when it’s actually the thing that tells the agent where to stop drifting. Building the course also surfaced a limit worth stating plainly: this only handles work that can be briefed up front. Some tasks — genuinely exploratory or creative ones — have to be shaped first (questions asked, options mapped, tensions surfaced) before a brief is even possible, and forcing a six-field brief onto that kind of work too early just produces a confidently-wrong plan instead of a confidently-wrong draft.

Where this could go

The natural extension is making the audit a gate rather than an optional habit — running the Vague Ask Auditor (or something like it) automatically before a request ever reaches an agent, the way a linter runs before a commit, so bad handoffs get caught before compute is spent on them rather than after the output disappoints. At team scale this is the more interesting version of the problem: the six fields are exactly the categories that go missing when a department hands work to agents without a shared standard for what a “ready” request looks like, and a shared brief template (with the quality bar and definition of done spelled out per project) is a cheap way to keep everyone’s agent handoffs at the same floor instead of each person rediscovering the same failure modes independently.