How to write a product brief an AI agent can actually execute

Why human briefs don't work for agents

Humans read briefs and ask questions when something is ambiguous.

Agents don't. They infer.

The inferences they make are usually plausible, frequently wrong, and almost always confident.

A brief that works for a senior engineer ('add notification preferences') will produce wildly different results when fed to Cursor or Claude Code.

The fix isn't to make agents smarter. It's to make briefs less ambiguous.

The five sections

• Objective — one sentence, plain language. What changes after this ships.
• Outcome — measurable. The number that moves and how to verify.
• Constraints — what the agent must not do. Existing patterns to follow. Files not to touch.
• Edge cases — the inputs or states that need explicit handling.
• Verification — how the agent confirms it worked. Tests, manual checks, or both.

Section by section

Objective is the part most PMs do well. 'Users can configure their notification preferences.' Fine.

Outcome is where briefs usually go thin. Not 'users can configure preferences' but 'the configure-notifications event fires for at least 12% of users who land on the settings page, measured over the first 14 days post-launch.'

Constraints are where briefs typically break. The agent doesn't know your file structure, your existing patterns, or which abstractions are off-limits.

Edge cases are the part senior engineers hold in their head and forget to write down. 'What if the user has no email on file? What if the Slack integration is disconnected?'

Verification closes the loop. 'Unit test on the persistence layer. Playwright test on the form. Smoke check that the existing notifications still send.'

An example

Objective: Add a settings page at /settings/notifications where users can toggle email, in-app, and Slack notifications.

Outcome: 25% of weekly active users visit the page within 30 days of launch. Persisted preferences are reflected in the next notification dispatch.

Constraints: Use the existing useUser hook from src/hooks/use-user.ts. Persist to the user_preferences table — schema is already defined. Match the layout of /settings/profile/page.tsx. Do not add new dependencies.

Edge cases: User has not yet connected Slack — show the toggle disabled with a 'Connect Slack first' link. User toggles all three off — show a confirmation modal.

Verification: Vitest test on persistence. Playwright test on the toggle UI. Manual smoke check that toggling email off prevents the next welcome email.

Where the brief comes from

Even a perfect brief is downstream of a decision.

If you can't answer 'why are we building notification preferences right now,' you'll write a brief that ships a feature against an unstated assumption.

Synchronise treats the brief as the second artefact in the chain. The decision is first. The brief inherits the decision's evidence chain so the agent — and, more importantly, the human reviewing what the agent shipped — knows what success was supposed to look like.