Most agentic-coding sessions fail in the first prompt. Either it’s a vague intent (“build the dashboard”) or a shopping list of 30 constraints the agent skips by line 4. We’ve found a middle path: spend 12 minutes upfront writing the task brief, then let the agent run. Here’s the structure we teach.

The five sections every brief needs

Every brief we hand an agent has the same five sections, in the same order: Outcome, Constraints, Examples, Success Criteria, Escape Hatch. They are short — 30–60 seconds each to write — and they are non-negotiable. Skipping any one of them produces predictable failure modes that we have measured across hundreds of sessions.

The discipline is in the order. Outcome first stops the agent from optimising for the wrong target. Constraints second stops it from going off-piste. Examples ground the abstract in the concrete. Success criteria let the agent know when it’s done. The escape hatch tells the agent what to do when it gets stuck — without that, agents either fabricate or grind.

Section 1: outcome, not implementation

The Outcome section is two or three sentences. It describes what the system should do once the change is in, in user-visible or business-visible terms. ‘Users on the Pro plan can export their dashboard as a PDF.’ Not ‘add a PDF export endpoint to the API and a button to the dashboard component.’ The implementation is the agent’s job. Yours is to define the goal.

If you find yourself unable to write the Outcome in plain English in 60 seconds, that is information. It usually means you don’t yet know what you want, and any code generated will be premature. Stop, talk to whoever is asking for the feature, and come back with a real outcome.

Sections 2–5: constraints, examples, success criteria, escape hatch

Constraints are the things the agent must respect: stack, libraries, security boundaries, performance ceilings. Three to five bullets, no prose. Examples are the most undervalued section: a single concrete example of input → output, or one similar feature elsewhere in the codebase, transforms output quality. Show, don’t tell.

Success criteria define done: ‘tests pass, /api/export returns 200 with a PDF body for a Pro user, the dashboard shows a working button.’ Specific and verifiable. The escape hatch tells the agent what to do if it can’t make progress: ‘if you encounter unfamiliar code in the billing module, stop and ask. Don’t guess.’ This single sentence prevents the most expensive class of agent failure: confidently generating wrong code in a domain it didn’t fully understand.

Worked example: a feature flag system in 12 minutes

Outcome: ‘Engineers can enable/disable features per-user via a config file, and the rest of the application checks flags through a single helper.’ Constraints: ‘TypeScript, no new dependencies, must work in the existing /src/lib pattern, must be testable without mocking.’ Examples: ‘see /src/lib/permissions.ts for the pattern we want to mirror.’

Success criteria: ‘helper exported from /src/lib/flags.ts, three tests covering flag-on, flag-off, and unknown-flag, used in at least one real call site.’ Escape hatch: ‘if anything in the existing build pipeline blocks adding /src/lib/flags.ts, stop and surface that — don’t attempt to modify build config.’ Twelve minutes of writing. An hour of agent work. A clean PR.

Want us to teach this to your team?

We’ve taught this five-section structure to engineering teams across UK SMEs and B2B SaaS, and the velocity delta is consistent: 2–4× more tasks completed per engineer per week, with fewer ‘agent went rogue’ incidents. It is not magic. It is a 12-minute discipline.

Our agentic AI coding courses cover this in depth, including team-specific drill exercises, before-and-after metrics, and the supporting review pattern from review the plan, not the code. Half-day to two-day formats, in-person in Birmingham or remote across the UK.