A handoff brief answers a practical question: what should happen when the work moves from software to a person, or from a person to software? A prompt alone rarely answers it. The prompt may describe the desired output while leaving access, approval, and failure handling to whoever happens to be implementing the workflow.
The brief should be short enough for an operator to use and precise enough for a builder to test. Start with one handoff. If the document tries to describe every possible future automation, the useful boundaries disappear into generalities. The aim is to make the next action clear when the ordinary path works and when it does not.
This guide uses an illustrative internal purchasing workflow. An agent prepares a summary of a supplier’s request for the purchasing coordinator. It may read selected records and draft a response, but the coordinator decides what to send. Adapt the structure to your own work rather than copying the example’s permissions.
State the job and the finish line
Write the job in one sentence: prepare a reviewable summary of a supplier’s order-status question using the current order record. Then write the finish line separately: the coordinator has the source message, the relevant record reference, a draft answer, and a visible list of unresolved questions.
That finish line is more useful than saying the task is complete when a response has been generated. Generation is an internal event. The person receiving the handoff needs enough context to make a decision. If the output exists but cannot be connected to the original request, the handoff is incomplete.
Include the recipient by role and identify a backup route. A person’s name may be useful in a small pilot, but the process should survive an absence. If the usual coordinator is unavailable, say whether the work waits, goes to a team queue, or is reassigned by a manager.
List the allowed inputs
Name the source systems and the particular records the workflow may read. Avoid broad phrases such as all relevant company information. For the purchasing example, the inputs could be the incoming supplier message, the referenced order, and a current internal delivery note. The agent should not search unrelated client files just because it has access to them.
For each input, define what makes it current and what to do when it is missing. Two order records with similar identifiers should trigger a clarification rather than a guess. A delivery note from last month may be useful background, but it should not silently become today’s commitment. These rules belong in the brief because they shape both implementation and review.
Separate reading, drafting, and acting
Permissions become clearer when described as verbs. The workflow may read an order record, draft an internal reply, and attach a reference to the review queue. It may not edit the order, promise a delivery date, send a message externally, or change the person responsible for the account. Each allowed action should have a reason tied to the job.
Microsoft’s role-management guidance discusses least privilege in its identity environment. The corresponding brief-writing habit is to request only the access required for the particular handoff. Actual enforcement belongs in the system’s permissions, not solely in a paragraph telling the agent to behave.
If a later version needs an additional action, treat that as a change to the brief. Review its consequences, update the tests, and obtain the appropriate internal approval. Expanding a tool’s access to solve a minor inconvenience can quietly change the nature of the workflow.
Describe the review screen in ordinary language
The coordinator should see the original question, the proposed answer, and the supporting record together. Uncertain details should be easy to find. Do not make the reviewer open several technical logs to discover that a lookup failed. A polished paragraph with missing evidence is harder to review than a plain draft that states its gaps.
Specify the available decisions. The coordinator might approve the draft for manual sending, edit it, reject it, or ask for another lookup. Record the decision and any important correction. Those corrections can become future test cases, but they should not automatically change the system’s instructions without review.
Write the escalation rules as recognizable situations
Use examples the operator will recognize. A supplier disputes an invoice. The order reference matches more than one record. The message asks for a change in payment details. The source system cannot be reached. Each situation should have a named destination and a short explanation of what information accompanies the escalation.
Anthropic’s agent design guidance discusses systems that use feedback and stopping conditions as they work. In a handoff brief, the practical question is when the software should stop attempting progress and involve a person. Set that point deliberately. Repeated attempts can produce duplicate work or make the original problem harder to diagnose.
Include a compact example brief
For this example, the trigger is a supplier question received in the designated intake queue. The purpose is to prepare an internal order-status draft. Permitted inputs are the message, the matching order, and the current delivery note. Permitted outputs are a draft, source references, and a list of missing facts. The coordinator remains responsible for external communication.
Completion requires a unique order match and a draft that distinguishes confirmed information from unresolved details. If the match is ambiguous, the workflow stops and asks the coordinator to identify the order. If a source lookup fails, it records the failure and leaves the request in the review queue. It never marks the supplier’s question answered solely because a draft exists.
The fallback is the existing manual process. The coordinator can pause the workflow and continue from the original message. The process owner reviews changes to permissions, source fields, and escalation rules. This brief gives the builder enough structure to produce specific checks while leaving implementation choices open.
Test the brief with an awkward case
Take a message that combines an ordinary order question with a request to change bank details. Ask two people to apply the brief independently. If one would send the message to the coordinator and the other would let the agent continue, the escalation rule needs clearer wording. The disagreement is useful evidence about the document.
Also try a missing attachment, a duplicated request, and an unavailable source system. A handoff brief is incomplete if it only describes the happy path. You do not need an exhaustive catalogue of every possible failure, but you do need a default response that preserves the work and gives a person a sensible next step.
Keep the brief connected to change
Put a version and an owner on the document. Record why a significant rule changed, especially when the change expands access or alters the completion condition. Link the brief to the cases used in the agent test set. That connection helps a future maintainer understand which behavior the tests are meant to protect.
Review the brief when the real process changes, not only when the software changes. A new supplier policy, a different approval role, or a revised source system can make an old instruction wrong. The document earns its place by staying useful to the operator who receives the next handoff, including the one nobody expected during the demonstration.