Seven things a real brief answers.
The specific job, not the general idea
"Help with customer support" isn't a brief — it's a category. "Answer pre-sales questions about pricing tiers and features, using our current docs" is. Name the exact job, not the department it lives in.
The inputs it will actually see
What triggers it, and what does the raw input look like — an email, a form submission, a webhook payload? Include a few real examples, especially the messy ones, not just the clean happy-path case.
The actions it's allowed to take
List the specific, bounded actions — send a reply, update a record, tag a ticket — not "handle the request." An agent needs a defined set of moves, not an open-ended mandate.
What "done" looks like
A concrete, checkable definition of success for a single run. If you can't describe what a correct outcome looks like, the brief isn't ready yet — that's a sign the process itself needs to settle first.
Where it should hand off, and to whom
The specific conditions that should trigger a handoff to a person, who that person is, and what context they need to pick up the case without re-investigating it from scratch.
What it should never do
The explicit boundaries — actions that are always off-limits regardless of how confident the agent is. This matters more than the list of what it can do.
How you'll know it's working
The specific signal you'll check after launch — error rate against real inputs, time saved, escalation volume — not a vague sense that it "seems fine."