Writing a Handoff Brief an Agent Can Follow End to End

The practical unit is a check with four fields. Write them out for every meaningful requirement and the brief becomes executable.

1. Input. The exact source, filter and scope. Not "recent tickets" but the closed tickets in a named date range, from a named system, excluding a named set of test accounts. Guidance on agent task specifications calls this constraining scope, and notes that agents often have access to more context than the author intended (AgentCenter).
2. Output. The artifact, its format and its shape. "A Markdown table with four named columns, one row per ticket, summaries capped at one sentence" is testable. "A summary" is not.
3. Pass condition. The rule a reviewer or a script can apply without judgment. "Every row has a non-empty summary" passes or fails mechanically. "Tone is professional" does not.
4. Fail action. What happens when the pass condition is not met: retry once with the same inputs, escalate to a named person, or stop and report. Without this field the agent decides, and its decision will usually be to try harder in a way you did not authorize.

A worked example makes the difference concrete. Suppose the task is a weekly support digest.

The final row is the one most briefs omit, and it is the one that converts a hopeful instruction into a bounded process.

Stop conditions are the part of the brief that most resembles what engineers call a definition of done, except they apply to the loop rather than the artifact. A useful autonomy loop, as described in practitioner guidance on autonomous agents, interprets state, plans a step, validates permissions, executes, observes the result and then either continues, escalates on a blocker or returns a verified outcome (Promptessor). The brief supplies the escalation and completion rules that loop needs.

Write at least four classes of stop condition.

• Data missing or stale. If the source returns no rows, or the newest row is older than the freshness window you set, stop and report. Do not substitute a previous period silently. The acceptance-criteria guidance calls out exactly this case: an empty section should say so rather than be left blank or backfilled (AgentCenter).
• Check failure after retry. Allow one bounded retry, then escalate. Unbounded retries are how a small formatting problem turns into a long, expensive run.
• Budget exhaustion. Time, tokens, tool calls or money. Name the ceiling and the action on hitting it. Budgets and stopping conditions are listed among the standard containment controls for agents that choose their own intermediate steps (Promptessor).
• Scope violation attempt. If completing the task would require an action outside the declared tool set or authority level (writing to a production system, contacting a customer, deleting a record), stop and request approval instead of finding a workaround.

It helps to think of the brief as defining gates. Anthropic's workflow patterns describe adding programmatic checks on intermediate steps so the process stays on track (Anthropic engineering). A stop condition is the same idea expressed in prose: the agent checks its own state against a written gate and takes the specified branch.

One caution about over-specification. Long specs consume context and dilute attention, and practitioners recommend breaking large tasks into smaller ones rather than keeping everything in one large prompt (Addy Osmani). Stop conditions are worth their length because each one removes a decision. Decorative background is not.

Human delegation fails most often when the level of authority is never stated. The five-level model used in management training runs from "do as I say" through research and report, research and recommend, decide and inform, up to act independently, and its author notes that most delegation failures come from the delegator and delegate assuming different levels (Full Focus). Research on agent delegation makes the same point in more formal terms: delegation is not just task decomposition, it also transfers authority, responsibility and accountability, and requires clear specifications of roles and boundaries (arXiv).

For an agent brief, collapse the scale into three buckets that map onto tools and permissions, because that is what you can actually enforce.

The third row matters most. Practitioner guidance on agent oversight describes runtime supervisory systems that evaluate actions against policy and escalate when a proposed action crosses risk, financial or regulatory thresholds, rather than relying on input filters alone (Sweet Security). A sentence in the brief saying "do not delete anything" is a preference. A tool that cannot delete is a boundary. Write the brief to match the enforcement you have, and where the enforcement is missing, treat the action as approval-required until it exists.

Then be explicit about the default. When the brief is silent on an action, the agent should treat it as approval-required, not as permitted. State that in one line near the top: "If this brief does not authorize an action, it is not authorized."

The following skeleton covers the sections that do the work. It is deliberately short. Fill it in, then check that every requirement survives the two-interpretations test.

# Task
One sentence: what artifact, delivered where.

# Inputs
- Sources (named systems, exact paths or queries)
- Date range and timezone
- Exclusions (test accounts, internal tags, archived items)

# Output
- Format, structure, length limits
- File name and destination
- Naming and numbering conventions

# Acceptance checks
For each check: input, expected output, pass condition, fail action.
1. ...
2. ...

# Stop conditions
- Missing or stale data: [action]
- Check fails twice: [action]
- Budget ceiling: [time / calls / spend] then [action]
- Scope violation attempt: stop and request approval

# Authority
- Act alone: [list]
- Approval required: [list]
- Never: [list]
- Default for anything unlisted: approval required

# Reporting
- Where the run log goes
- What the final message must contain (status, counts, open questions)

Two fields are easy to skip and expensive to skip. The naming convention prevents a folder of near-duplicate files that nobody can audit. The final message format is what makes the run reviewable at a glance: status, counts against each acceptance check, and any open questions the agent could not resolve within its authority. The oversight literature is blunt that long action traces often fail to show why an agent changed strategy, so a summary written against your checks is more useful to a reviewer than a raw log (Data & Society).

If you are running many briefs across a team, the natural next step is a shared setup where briefs, checks and skill definitions live in one library and each person holds their own credentials, which is what Quanta for Teams provides.

Run this checklist on the draft. It takes about five minutes and catches most of what would otherwise become a failed run.

The single-interpretation test is the one that earns its place. Ambiguity that survives this check rarely announces itself as ambiguity; it appears as a phrase that felt precise when written and reads as a menu when executed. Agent failure analysis keeps landing on planning and specification errors as a leading cause, which is why the check belongs before the run, not after (arXiv).

A second, cheaper test: give the brief to a capable model in read-only mode and ask it to list every decision it would have to make on its own. Practitioners who write specs for coding agents recommend exactly this pattern, planning first with no write access, resolving ambiguities by questioning the author, and only then executing (Addy Osmani). The list of decisions the model returns is your remaining ambiguity, written down.

A perfect brief cannot rescue a task that should not be an agent at all. OpenAI's guidance on agent design recommends validating the use case first: agents pay off for complex judgment, unwieldy rule sets and heavy unstructured data, and a deterministic solution is the better answer when the workflow is well defined (OpenAI). If your acceptance checks are so complete that a script could apply them, consider whether a script should do the work and the agent should only draft.

When the task genuinely needs an agent, the brief is portable across models, and that is a feature. Write it once against explicit checks, run it against the model that fits the task, and compare the run logs against the same acceptance criteria. Routing several kinds of work (text, image, audio, embeddings) through one API key makes that comparison cheaper to run, which is the case for Quanta Inference.

The pattern that emerges is that a good brief looks less like a memo and more like a small test suite with a permissions section. That is more work up front than a colleague brief, and it is the only version of delegation an agent can complete end to end without you in the loop.