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. 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.
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.
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.
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.