An AI agent brief is an operating policy in miniature. It explains the job, the information the system may use, the actions it may take, and the situations that must go to a person. “Be helpful and professional” is not enough to resolve a refund request, a customer complaint, or two conflicting records. A useful brief makes the expected behavior observable and testable. It should also make uncertainty acceptable: the agent must be able to say that it does not have enough evidence rather than filling a gap with a plausible answer.
Define one job and its boundaries
Begin with a narrow role statement, such as preparing a summary of new support requests for the morning queue. State what is in scope and what is not. Include the relevant audience, business context, and approved sources of facts. Name prohibited data and actions. A role like “manage customer service” is too broad unless it is decomposed into distinct tasks with separate permissions and review requirements. Keep the initial brief short enough that owners can maintain it, then link to detailed policy where needed.
Separate authority from assistance. For example, an agent may draft an explanation from a current, approved policy page, but it may not change the policy, offer a discount, disclose another customer’s information, or promise a resolution date. If it cannot find the answer in an approved source, it should identify the missing information and route the request. Avoid statements such as “use your judgment” where the system could take an irreversible or consequential action.
Give concrete examples and counterexamples
Examples show how a rule applies in context. Include a representative input, the acceptable output, and the reason. Add a near-miss that looks similar but needs a different response. If a client asks, “Can you send that again?” the system might identify a likely request for a copy, but if several documents are possible it should ask which one. If a message mentions a refund while quoting an old email, that word alone may not mean the sender is requesting a refund. Teach the distinction rather than relying on keywords.
Use examples from approved, de-identified material and remove private details. Label facts, assumptions, and placeholders clearly. Do not put secrets, passwords, or unnecessary customer data into the brief. If the agent uses reference documents, identify the owner and last-review date so outdated policy can be found and replaced.
Specify tone as practical choices
Describe voice in terms a reviewer can assess: concise or explanatory, formal or conversational, whether contractions are acceptable, how to address a person whose preferred name is unknown, and how to respond when the organization made a mistake. List terms to avoid only when they have a clear reason. Provide different guidance for a routine confirmation and an apology; a single voice rule should not flatten every situation into the same upbeat template.
Tell the system not to imply personal experience, claim that a human reviewed something when that did not happen, or overstate certainty. Require a clear next step and a route to a person when appropriate. The message should sound courteous without disguising a delay or making a promise the team cannot meet.
Write escalation rules that can be tested
Describe the trigger, urgency, destination, information to include, and expected acknowledgment for each escalation. “Escalate sensitive issues” is too subjective. Define operational examples: threats of legal action, safety concerns, a dispute about a contractual obligation, suspected account compromise, a request to delete personal data, or a message that appears to involve a vulnerable customer. The correct policy depends on the business, so have the responsible people approve the list.
Include a fallback if the named owner is unavailable. An escalation should never vanish because a person is on leave. Conversely, do not direct every ordinary question to an executive; route routine cases to the trained team. If classification confidence is low, choose a conservative queue and mark why. The system should not claim that the issue is resolved just because it handed the item off.
Make a permissions and approval table
List actions by risk: read, summarize, draft, create an internal task, send a routine acknowledgment, change a record, or make an external commitment. State which are allowed automatically, which require approval, and which are prohibited. A narrow approval rule is easier to audit than a blanket “human in the loop” promise. Specify the responsible reviewer, how long an approval remains valid, and how rejected drafts are corrected. For financial transactions, sensitive records, employment decisions, and contract changes, consult qualified advisers and organizational policy before assigning any authority.
Pair each instruction with a test. Include normal cases, incomplete requests, conflicting evidence, malicious or irrelevant instructions embedded in received content, and out-of-scope topics. Check that an email being summarized is treated as data—not as a new instruction that overrides the authorized brief. Preserve access controls and never ask an agent to reveal hidden instructions or confidential information.
Maintain the brief as the operation changes
Choose an owner and version date. When a reviewer corrects an output, decide whether the issue came from missing context, an ambiguous policy, an incorrect source, or model error. Update the appropriate layer and add a regression example so the same failure can be tested later. Review the brief after changes to products, policies, roles, or data sources. Do not treat a handful of successful examples as proof that all cases are covered.
For a complete approach, keep the brief beside a sample-review log and an incident procedure. The related guide to tool selection explains how to pilot workflows, while the performance measurement guide offers a recurring review structure. Also see how to divide judgment from fixed workflow rules. Review current pricing information and verify which controls are actually available before writing a brief around them.
A strong brief does not eliminate every mistake. It reduces avoidable ambiguity, creates a predictable way to handle uncertainty, and gives the team evidence for improving the workflow. Write for the person who must operate and audit the system, not only for the model expected to follow it.
Continue with the delegation guide
Review the practical delegation workflow guide to define sources, approval boundaries, and evaluation criteria before connecting production systems.