Write an agent brief your team can use

An agent brief should let an operator, developer, and reviewer describe the same job. It does not need to predict every technical detail. It does need to state what starts the work, what information may be used, what result is expected, and where the agent must stop. If those decisions are missing, the implementation team will make them indirectly through prompts and code.

Write the first version before selecting a model. Use a single page if the task is small, with examples attached separately. The brief should be easy to revise after observing real cases. Its purpose is to make decisions visible and testable, not to create a long specification that nobody reads when the workflow behaves unexpectedly.

Start with the operator and the task

Name the person or role responsible for the workflow. Then describe the task in one sentence: prepare a reviewable supplier meeting brief from the current project record and approved notes. That sentence is more useful than build an intelligent assistant for procurement. It identifies a deliverable and suggests a boundary. The brief can then explain what a reviewer does with the result.

State the problem in terms of work. Perhaps employees repeatedly assemble the same information before calls. Perhaps requests arrive in inconsistent language and need classification. Avoid writing a promise such as eliminate manual effort. A brief should define what the team intends to test, while the pilot determines whether the result is worth using.

Define the trigger and required inputs

Write exactly what begins a run. A person may click a button on a record, submit a form, or place a document in a designated folder. Specify the identifiers needed to find the right context. If a supplier meeting brief requires a project ID and meeting date, say what happens when either is missing. Do not assume the model should guess a record from a similar name.

For each input, record its source and freshness requirement. The current project record might be authoritative for the owner, while an approved agenda is authoritative for the meeting purpose. Notes from an earlier meeting might provide background but not override a newly confirmed date. These distinctions help the developer design retrieval and help the reviewer understand why a statement appears in the result.

Describe the output as a contract

List the required sections or fields. In the meeting example, that could be purpose, participants, open decisions, supporting links, and unresolved questions. State which fields may be empty and how uncertainty should appear. Give a short example of an acceptable result. A structured output can still contain poor information, so the brief should define meaning as well as shape.

Include one unacceptable example. A brief that invents a participant, treats an old target date as confirmed, or omits a known disagreement should fail even if the prose sounds polished. This negative example makes the review standard easier to share. It also prevents formatting quality from becoming a substitute for factual quality during the demo.

Separate tools from permission

List each action the workflow needs, with its purpose and permitted scope. Reading a project record, searching approved notes, saving a draft, and sending a message are different actions. A tool being technically available does not mean the agent should use it for every request. The brief should identify which actions are allowed automatically, require approval, or are outside the task.

Anthropic's tool-design article discusses clear descriptions and useful tool responses. In your brief, make the business meaning equally clear. A tool named update record should not leave everyone guessing which fields can change. Describe the intended operation narrowly enough that an engineer can implement an enforceable boundary around it.

Write the stop conditions

A stop condition is an event that changes the path. Examples include an unknown project identifier, conflicting source documents, an unavailable service, or a request to contact someone outside the approved workflow. For each condition, state the expected result. The system might ask for missing information, place the case in a review queue, or end the run with a truthful explanation.

Avoid a catch-all instruction to use judgment for every exception. That simply moves unresolved policy into the model. If the team cannot decide what should happen, name an owner for the decision and leave the action restricted until it is resolved. The brief can contain open questions, provided they are visible and do not silently become permissions during implementation.

Specify the human decision

If approval is required, say who approves what. The reviewer needs the proposed action, relevant evidence, and unresolved issues. They also need a meaningful choice: approve, edit, reject, or request more information. Decide whether an edited result requires another check and whether approval expires when the underlying record changes. These details prevent a vague human-in-the-loop label from hiding an incomplete process.

LangGraph's interrupt documentation provides an implementation example for pausing and resuming work. The brief should describe the experience independently of that mechanism. A person should understand what is waiting and why, even if the technical team later chooses a different framework or queue system.

Add a worked example

For a fictional supplier meeting, the trigger is a coordinator requesting a brief for project R-17. The inputs include the current project record, the approved agenda, and the last two meeting notes. The output is a saved internal draft with source links. The workflow may read those sources and create the draft, but it may not invite participants, change dates, or email the supplier.

One note says delivery was expected on Friday, while the current project record lists Monday. The required behavior is to use the current record for the date and flag the disagreement for the coordinator. If the project record cannot be retrieved, the workflow should leave the date unresolved. This example gives the developer a concrete test and the operator a recognizable situation to review.

Include operating limits

Specify a reasonable maximum run duration, tool-call budget, and retry approach for the pilot. These are project choices to measure and adjust, not universal numbers. State where a failed run appears and who is responsible for investigating it. A workflow that can keep trying indefinitely is difficult to operate, and an error that exists only in a developer console may never reach the task owner.

Record what information is retained and why. The team may need the input identifier, source versions, output, approval decision, and relevant error details. Avoid retaining unnecessary sensitive content simply because a tracing tool makes it easy. Access to operational records should match the team's actual responsibilities, and retention choices should be reviewed against the organization's policies.

End with acceptance and ownership

Attach a small set of test cases and a reviewer for each kind of judgment. Define how the team will decide whether the pilot is useful, including correction effort and exception handling. Record who may change the instructions or connected tools after launch. A clear change owner helps keep a small improvement from quietly becoming a different workflow.

The next step is to put one recent task through the brief with the people who perform it. Read the input, describe the desired output, and follow every exception to a named person or explicit result. Wherever the group disagrees, revise the brief. That conversation is part of the build, and it is usually cheaper before the disagreement has been embedded in software.