A business owner explains what they want the agent to do. Twenty minutes later, the scope feels clear enough to start building. Six weeks later, the agent works — but keeps producing outputs the team has to correct. The conversation that defined the workflow was not a brief. It was a description. A brief is the document that makes an agent reliable, and writing one takes longer than most people expect.
The conversation that defined the workflow was not a brief. It was a description. The two produce very different agents.
What a brief actually is (and what it isn't)
Most people approach briefing an agent the way they approach writing a prompt: describe what the agent should do, give some examples, and see what comes out.
That approach produces an agent that performs well on inputs resembling the examples. It fails on inputs that don't.
A brief is not a prompt. It is a specification of a business process — the document that defines a workflow precisely enough that a new employee with no context could follow it correctly on day one. Writing it is a process-documentation exercise, not a prompt-writing exercise.
This distinction matters because a vague brief and a vague prompt produce different failure modes. A vague prompt produces inconsistent outputs. A vague brief produces an agent that handles expected cases correctly and fails on everything else — which, in a real business with real input variation, is a large number of cases. IBM's Systems Sciences Institute has documented that requirements-level errors discovered in production cost 10 to 100 times more to correct than errors found at the requirements phase — a ratio that applies directly to agent briefs, where each gap in specification becomes a correction the team makes repeatedly against live outputs.[¹]
The five questions every brief must answer
A brief is not instructions for the agent. It is a specification of a business process — trigger, inputs, output format, acceptable exceptions, and escalation path. Writing it reveals every gap in how the business currently handles the task.
A complete brief answers five questions. If any one of them is missing, the brief is incomplete.
1. What triggers the agent? A specific, observable event that starts the workflow. Not "when a lead needs following up" — "when a lead's last activity date is more than five business days ago and their status is Proposal Sent." The trigger must be testable: either it fires or it doesn't.
2. What does the agent receive? The exact inputs available at the moment the agent runs. Field names, data types, which fields may be empty, which are always populated. An agent cannot use information it was not given. Every missing input is a gap that surfaces in production.
3. What does the agent produce? The specific output, in a specific format. Not "a follow-up email" — a follow-up email with these fields, this tone, this maximum length, this subject line structure. The output definition is the success criterion.
4. What are the acceptable exceptions? Every workflow has cases that fall outside the main path. The brief names them explicitly: which inputs trigger a different output, which cases get routed differently, which situations require a human decision. "It depends" is not an exception rule.
5. What happens when the agent can't decide? The escalation path. A specific action for inputs that don't match any defined case. Not "the agent will handle it appropriately" — a named step. Flag for review. Send to a queue. Reply with a holding message. The escalation path is what keeps the agent from producing wrong outputs on edge cases.
The table below shows what each brief component requires, using a lead follow-up workflow as a reference example.
| Brief component | What it specifies | Example — lead follow-up workflow |
|---|---|---|
| Trigger | The observable event that starts the workflow | Lead status = "Proposal Sent" AND last activity date > 5 business days ago |
| Inputs | Exact data fields available when the agent runs | contact_name, company_name, proposal_value, last_reply_date, account_manager |
| Output | The specific deliverable, format, and length | Follow-up email: subject line format, max 150 words, first-person from account manager |
| Exception rules | Named cases that follow a different path | "Do not contact" tag → skip; proposal_value > $50k → route to founder for manual send |
| Escalation path | The defined action when no rule matches | Flag for manual review; add to "Needs attention" CRM queue with a 2-hour review SLA |
What happens when a brief is incomplete
Most implementation failures are briefing failures. The agent delivered exactly what it was given.
An incomplete brief produces a specific failure pattern. The agent works for the first two weeks. The inputs it receives during that period happen to match the cases it was briefed for. The team sees correct outputs and assumes the implementation is solid.
Then a case arrives that the brief didn't cover. The agent produces something that looks like an output but isn't right. The team corrects it and moves on. Another edge case arrives. Another correction. Over a month, the team spends more time reviewing the agent's work than they would have spent doing the task themselves.
This is not a failure of the technology. The agent did exactly what it was told. The brief told it how to handle the common case and left everything else undefined. The agent handled the common case. When the uncommon case arrived, it produced the closest match it could find.
Every correction the team makes after launch is a line of the brief that was never written.
How to write a brief before you know what to put in it
Most businesses don't have their processes documented well enough to write a complete brief from memory. The brief has to be discovered.
The fastest method is to shadow the task. Sit with the person who currently does the workflow and observe twenty real instances. Do not describe the workflow in the abstract — watch it run on actual inputs and produce actual outputs.
For each instance, record: what triggered it, what information was available, what decision was made, what was produced, and whether any exception was handled. After twenty instances, the common case is clear. Exceptions that appeared in those twenty instances become the explicit exception rules. Cases that didn't appear but could — ones the person doing the task can describe from experience — go into the escalation path.
A shadowing session produces a draft brief. The draft is then tested against five real inputs that weren't part of the session. Every gap that appears in that test is a missing line in the brief.
Choose the right person to shadow
The person who currently does the task, not the person who explains it best. The explainer knows the ideal case. The doer knows what actually happens.
Observe 20 real instances, not examples
Watch the workflow run on actual inputs with actual outputs. Described examples reflect what the person thinks they do. Observed instances reflect what they actually do — including the variations they do not consciously notice.
Record the same five fields for each instance
What triggered it, what information was available, what decision was made, what was produced, and whether any exception was handled. Consistent recording across 20 instances reveals patterns that a description never would.
Identify the common path
After 20 instances, the main path — trigger, inputs, output — is clear from the pattern. This becomes the brief's primary case.
Extract exception rules from real cases
Exceptions that appeared in the 20 instances are named explicitly in the brief. Each one specifies the condition and the different path it triggers. "When X, do Y instead" — not "handle appropriately."
Write the escalation path for everything else
Cases that did not appear but could — ones the doer can describe from experience — go into the escalation path with a specific action. The escalation path is the brief's definition of "I don't know" — and it cannot be left undefined.
Test the draft against five new real inputs
Five inputs not in the original session. Any gap that appears is a missing line. Fix it before the build starts, not after.
The most common briefing mistakes
Most briefing gaps are not obvious when the brief is being written — they show up in production, after the build is complete, as correction work that seems like an agent problem. The table below maps each pattern to its production consequence.
| Mistake | What it looks like in the brief | What it produces in production |
|---|---|---|
| Description instead of trigger | "When a lead needs following up" | Agent triggers inconsistently; different runs produce different results |
| General inputs instead of field names | "The CRM information about the contact" | Agent fails on records with missing fields; errors are unpredictable |
| Output category instead of format | "A follow-up email" | Output format varies every run; team edits every output before sending |
| No exception rules | Brief covers the main path only | Agent applies the main-path logic to minority cases; wrong outputs compound each month |
| No escalation path | "The agent will handle it" | Undefined inputs produce confident-looking outputs that are quietly wrong |
| Brief written from ideal-case data | All examples use complete, well-structured records | Agent fails on any record with missing, inconsistent, or unusual data |
Each row in this table is a line of the brief that was never written. Each one becomes a post-launch correction that the team absorbs as overhead.
How the brief becomes the implementation
A complete brief is not preparation for the implementation. It is the implementation.
The five questions in the brief correspond directly to the five components of an agent system: trigger logic, input schema, output template, conditional routing, and fallback handling. A builder who receives a complete brief does not need a long discovery process. The brief tells them what to build.
Writing a complete brief for a five-step workflow commonly takes two to three hours — including the shadowing session. Building the agent from a complete brief often takes less time than that.
The brief is where the quality of every implementation is decided. Every hour spent completing it before the build starts is an hour not spent correcting outputs after launch.
How to validate a brief before the build starts
A brief feels complete when it is being written. The gaps do not appear until the brief is tested against inputs it was not written for. Two validation steps catch most of them before the build.
The new hire test. Print the brief and hand it to someone with no knowledge of the workflow — a colleague in a different function, a team member from a different department. Ask them to describe what they would do for a real input. If they ask a question the brief does not answer, that question is a missing line. If they describe doing something different from what the workflow actually requires, the brief has an ambiguity that the agent will resolve incorrectly.
The exception walk. Take five real inputs from the last 30 days that required an unusual decision — the cases the team remembers because they were outside the standard path. Run each one through the brief: does the brief specify what the agent should do? If the answer is "handle appropriately" or "use judgment," that input will produce a wrong output in production.
A brief that passes both tests is not guaranteed to be complete — there are always edge cases that do not surface until the agent is live. But a brief that fails either test will produce corrections starting in week three. The goal is not a perfect brief. The goal is a brief that has been tested against real inputs by someone other than the person who wrote it, before it becomes the implementation.
A brief that is revised twice before the build starts will produce fewer post-launch corrections than a brief that is revised zero times. The revision cost before the build is measured in hours. The correction cost after the agent goes live — and the team absorbs it as background overhead — is measured in weeks, not days.
Frequently asked questions
What is an AI agent brief?
An agent brief is a specification of a business process — trigger, inputs, output format, acceptable exceptions, and escalation path. A brief is not a prompt. A brief is precise enough that a new employee with no context could follow the workflow correctly on day one. Writing it is a process-documentation exercise, not a prompt-writing exercise.
What five questions must an agent brief answer?
Every brief must answer: what triggers the agent, what inputs the agent receives, what the agent produces, what the acceptable exceptions are, and what the agent does when it cannot decide. A brief missing any one of these is incomplete — and each gap becomes an edge case that produces a wrong output in production.
What happens when an agent brief is incomplete?
The agent works correctly for the first two weeks on inputs that match the cases it was briefed for. Then edge cases arrive. Each one the brief did not cover produces an output the team has to correct. Over a month, the correction work often exceeds what manual handling would have cost. Every correction after launch is a line of the brief that was never written.
How do you write a brief if the process is not documented?
Shadow the task: observe the person who currently does the workflow across twenty real instances. For each instance, record the trigger, available inputs, decision made, output produced, and any exception handled. After twenty instances, the common case is clear. Edge cases that appeared in those instances become explicit exception rules. Cases that could appear but did not go into the escalation path.
Notes
- IBM Systems Sciences Institute. "Relative Cost of Fixing Defects." Referenced widely in software engineering literature as the "Rule of Ten" — each phase of development multiplies the cost of correcting a requirements error found at that phase. Original context: Barry Boehm, Software Engineering Economics, Prentice Hall, 1981.