How to Design an Agent Brief

An agent brief is a work contract: it connects an outcome to permitted actions and a verifiable artifact. A vague instruction such as “help me grow the business” gives an agent neither a safe boundary nor a reliable finish line. A useful brief makes both explicit.

Define the outcome before the persona

Name the actual deliverable, its audience and its review criteria. “Produce a source-linked competitor update with at most five material changes” is testable. “Be an expert analyst” is not. A role can help organize the work, but it should not substitute for the goal.

OpenAI's agent definitions distinguishes instructions, tools, output types and runtime controls. Use that separation when designing a brief: not every requirement belongs in a prompt, and not every prompt constraint is enforced infrastructure.

Use a complete specification

Write the allowed sources, required tools, trigger and cadence. Then describe actions in order. Include rules for conflicting sources, missing data and duplicates. Define approval requirements before side effects, stop conditions, output shape, success criteria and risks.

A source list is an allowlist, not a suggestion. If the agent needs another source, it should request scope expansion or report the gap. The brief should say whether quoting, storing or republishing the material is allowed. Public accessibility does not automatically authorize redistribution.

Example: competitor monitor

Goal: prepare one weekly private note about three named competitors. Sources: approved public changelogs and pricing pages. Actions: compare against the previous reviewed snapshot, preserve changed passages and summarize business implications separately from facts.

Rules: cite every factual change; do not infer customer counts or revenue; distinguish a changed webpage from an announced policy. Human approval: required before contacting a competitor, changing a CRM record or publishing the note. Stop: after ten pages or fifteen minutes, or when a source requests authentication.

Output: a change table with URL, observed date, previous value, current value, confidence and an unresolved-questions section. Success: the reviewer can verify every change without repeating the entire crawl. Risks: stale snapshots, layout changes and misleading marketing language.

Write rules that tools can enforce

“Do not send email” should be reflected in tool access, not merely in prose. “Read only this repository” should be enforced by credentials and target validation. The brief explains intent; application policy enforces authority.

Specify a budget in units the runtime can monitor: tool calls, elapsed time, spend or records. Define how a partial result is saved when the budget ends. Retrying a failed write needs an idempotency strategy; repeating the entire run is not always safe.

Test the brief with counterexamples

Use an ambiguous announcement, a duplicate source, an inaccessible page and a source containing malicious instructions. Ask what the agent should do in each case before evaluating the generated answer. Include one case where the correct result is “I cannot establish this.”

A good brief does not guarantee good execution. It makes failures visible and reviewable. Evaluate citation quality, false positives, missed changes and reviewer effort. Refine the specification based on those observations.

Customize a template responsibly

Choose the closest Agent Work Specification, then replace sources, reviewers, destinations and budgets. Remove tools that are not necessary. Run once in read-only mode before enabling recurrence. Keep the brief version with each run so that changed behavior can be traced to changed instructions rather than guessed from the output.