When an agent does something odd, the first instinct is to blame the model. Usually the brief is the problem. It said what to do but not why, or it covered the normal case and nothing else.
A brief for an agent is a lot like a brief for a new person on the team. The difference is that a new person will ask questions when something is unclear. An agent will guess. So the brief has to answer the questions before they come up.
Say what done looks like
"Summarise this week's support tickets" is a task. "Post a summary in #support every Friday with the five most common issues, one line each, and link the tickets" is a task with a finish line.
Spell out the output: where it goes, what format it takes, how long it should be and who reads it. If you've seen a good version before, paste it in as an example. One real example does more than a paragraph of description.
Give it the reason behind each rule
Rules without reasons break the moment a situation doesn't quite fit. "Never reply to a ticket in under an hour" is a rule. "We wait an hour because customers often fix the problem themselves and close the ticket" is a rule the agent can apply with judgement.
When the agent knows why a rule exists, it can tell the difference between a case the rule was written for and one it wasn't.
Cover the awkward cases
Most briefs describe the happy path. The trouble lives at the edges. Before you finish, ask yourself what should happen when:
- The information it needs is missing or out of date
- Two sources disagree
- The request is outside what it's allowed to do
- A customer is upset, or mentions something legal or medical
- It isn't sure
The answer to most of these is "stop and ask a person, and say what you found". That's fine. Write it down anyway, because an agent that doesn't know it's allowed to stop will keep going.
Point it at the right sources
An agent with access to everything will use everything, including the draft doc from last year that nobody deleted. Tell it which sources are current and which to trust when they conflict. "Use the pricing page, not the sales deck" saves a lot of confused answers.
A brief is finished when a teammate who has never done the task could do it from the brief alone.
Keep it short enough to maintain
Long briefs rot. Someone changes a process, nobody updates paragraph eleven, and the agent follows the old rule for a month. Aim for a page. Put the stable parts (tone, who the customers are, what never to do) in a shared brief that every agent reads, and keep each task brief focused on the job itself.
Read the first ten runs
The brief isn't done when you save it. Read the first ten things the agent produces, closely. You'll find the gap within a day: a case you didn't mention, a word it read differently than you meant. Fix the brief, not the output, and the next hundred runs get better too.