Briefing the agent well

The posture you work in and the surface you run it on can wear into reflexes. The brief is the steering - and on budgetcli, the course’s illustrative personal-finance API, a vague brief steers you somewhere you didn’t want to go.

Here’s the difference that catches people. In a chat, a vague question is cheap: you read the half-useful answer and ask again, a few seconds lost. With an agent, a single prompt can trigger a chain - read the categorization rules, run the tests, edit four files, run them again - that grinds for minutes before it surfaces anything you can review. By the time an ambiguous instruction bites, the agent has already touched files on a guess. Vagueness didn’t cost a re-ask; it cost a run and a diff you now have to unpick. The skill is reducing ambiguity before execution, not correcting it after.

A brief the agent can’t misread carries the same four parts every time - no template, no headings, just don’t leave one out:

1. Goal - what done looks like in one concrete sentence, with an outcome verb. Not “look at the CSV importer,” but “add support for the Monzo statement format to the CSV importer.”
2. Context - the framework and an analogous bit of the codebase to copy. “Same service; follow the pattern in src/importers/barclays.ts.” A pointer to real code is worth a paragraph - the agent reads the reference and matches it.
3. Constraints - what not to do. “No new dependencies, don’t touch the accounts schema, money stays integer cents.” The off-limits list is where most wrong-but-reasonable runs come from.
4. Completion criteria - a check it can actually run. “A Monzo export imports clean and npx vitest run tests/importers/ exits zero.” Now it knows when it’s finished instead of when it’s tired.

Most of this only needs saying once. The durable stuff - money is cents, the taxonomy, the test command, the off-limits files - already lives in your rules, and the agent reads it at session start. Your per-task prompt carries only what’s specific to this task. If you catch yourself re-typing a convention into a brief, that’s the signal that it was never task-specific: it belongs in a rule, not the prompt.

Stop and rewrite, don’t nudge

When a run heads somewhere wrong, the instinct is to nudge it back - “no, not like that, do it this way.” Sometimes that works. But when the run went wrong because your prompt had two valid readings and the agent picked the one you didn’t mean, nudging is the slow road: you’re correcting on top of a foundation built from the wrong interpretation, and each correction inherits the original ambiguity.

The faster move is to stop, throw the run away, and rewrite the brief so the reading you wanted is the only one left. Interrupt immediately - the longer a misread run goes, the more diff you discard. Then write a fresh prompt with the same four parts, the ambiguous one nailed down: “the running balance is per-account, not the sum across accounts” stated up front rather than discovered three corrections in. A clean restart from a sharper brief beats five rounds of “no, the other thing,” because the ambiguity was a bug in the prompt, not a failing of the agent.

This is also why the Ask and Plan postures earn their place. When you’re still figuring out what to ask for, explore in Ask - the read-only built-in mode, where nothing can move while you learn - then drop to Plan (the built-in mode that researches read-only and turns your brief into an editable markdown plan you approve before anything is built) or Agent once the brief is sharp enough to commit to. Cursor’s built-in modes are Agent, Ask, Plan, and Debug, as of September 2026; no single docs page lists the set, and the course’s modes lesson maps which have one. The cost of a misread is zero when nothing was changed.

That is every deliberate move of the course made automatic. What remains is not a technique: stand back from the course’s own progression - the arc from a first reviewed change to an unattended run - and read what its shape was teaching. Next: the look back.