Back Matter

Appendix A: The Two Briefs, Worked

The operating model said the brief becomes two documents. This appendix gives you both as templates you can adapt, and then fills each one in for a single agent so the pattern is concrete rather than abstract. The agent is the refund agent the book has followed throughout. The templates are the reusable part; the refund example is one instance, and your own will differ in every specific while keeping the same shape.

Read the two briefs and the first thing to notice is what they share. Both carry Channel 1, the agent and what it does, and Channel 2, the layer that supervises it. The dual brief is not a division of the two channels into two documents; that is the mistake. The division is by audience and purpose. The Human Brief is the executive document, the successor to the PRD: the business case, the go/no-go decision, the cost model, the strategic intent, and the boundaries, written as prose a room of people argues with before anyone builds. The Executable Brief is the build document, the successor to the epic: the experience, the behavior, and the governance, structured so it can do two jobs at once, drive a vibe-coded prototype this week and seed a detailed backlog. You do not put a break-even model in front of a coding agent, and you do not ask a finance partner to sign off on an eval set. So you write both, and you derive the second from the first.

Watch for the supervisory layer in both. In the Human Brief it appears as a decision a room has to make: where the boundary sits, what it costs to fund the oversight properly, who is accountable. In the Executable Brief it appears as buildable requirements: the autonomy boundary, the approval experience, the audit surface, the eval set, rendered as things an engineer and a coding agent will construct. That is the whole thesis in one artifact. The supervision gets built because it was written into the spec, not assumed into the backlog.

Brief 1: The Human (Executive) Brief

Audience: the executive sponsor, finance, engineering, design, the domain expert. Purpose: to decide whether to build, where the boundaries sit, and whether the economics work, before anyone writes code. This is the document you argue with.

Template

A Human Brief should contain, in prose a room can debate:

The problem and the opportunity. What is costing money or going wrong today, and what the agent would change. One paragraph, honest about the size.
What we are building, and what we are deliberately not. The intended behavior in plain terms, and the adjacent thing it must not become (the known failure mode of the obvious version).
The cases that decide whether it is worth building. The hard cases the agent must handle well, not the easy ones that were never the problem. If the agent only handles the easy cases, the business case is weak.
The business case and the go/no-go. The suitability tests, the cost model with real numbers, and an explicit decision gate. This is the section a sponsor and a finance partner actually argue with.
Where the boundary sits, and why. The autonomy limit and the escalation triggers, stated as a deliberate choice with its risk named. This is the Channel 2 decision the room owns.
Accountability and how we will know. Who owns a wrong outcome, and the instruments that will tell us the agent is drifting before the loss shows up.
What success looks like, and what it does not. The real definition of done, written to exclude the seductive wrong metric (usually “share resolved without a human”).
The open questions the room still owes. The business decisions not yet made, each flagged in the open rather than assumed, the same `[NEEDS CLARIFICATION]` discipline the Executable Brief uses, carried up to the human side. A question marked here is a question the room knows it has to answer; a question left out is one that gets answered by default, in code, by whoever ships first.

Worked example: the refund agent

The problem and the opportunity. Refund requests are a high-volume, low-margin support cost. Most are simple: a defective item inside the return window, a customer plainly owed their money. A human reading these adds latency and cost and rarely changes the outcome. The opportunity is to resolve the clear cases at machine speed and reserve human attention for the cases that need judgment. The risk is that “resolve refunds automatically” quietly becomes “approve refunds the company should have questioned,” invisible until it shows up in the margin or the fraud report.

What we are building, and what we are deliberately not. We are building an agent that resolves refund requests in a way a senior support lead would endorse on review. We are not building an agent that maximizes approvals or optimizes only for customer satisfaction; both refund cases that should have been escalated, and the cost lands later and elsewhere. The agent favors customer trust on small, clear amounts and human judgment on large or anomalous ones.

The cases that decide whether it is worth building. The defective item inside the window was always going to be refunded; the agent’s value is not there. The agent earns its place on the cases the old workflow handled badly: the request just outside the window where the customer is right on the merits; the non-defective item where the customer is a high-value account about to churn, worth more than the refund; the request ten times the typical amount on an account whose pattern smells like fraud.

The business case and the go/no-go. Run the four suitability tests: refund handling repeats at volume (yes), the tool use is bounded (read records, write a refund, escalate, yes), consequences are recoverable within a clawback window (mostly, which sets the boundary), and the output is measurable and trusted (only with the eval set and the instruments below). Then the cost model, and this is the part a finance partner will press, so do it without flinching. (Figures below are an illustrative composite, stamped to mid-2026; your own numbers replace them.) The model’s token cost per refund decision is a few cents, trivially below the loaded cost of a human agent’s time. That comparison is the trap. The real cost is the architecture multiplier, the orchestration, the integrations, the audit pipeline, the eval maintenance, plus the supervision the boundary requires: a human reviewing every escalated case at a real per-review cost. For this agent the multiplier is roughly ten times the bare token cost: a single refund decision re-enters the model about eight times (classify the request, pull and read the order, weigh the account history, check the policy, run the fraud signal, draft the decision, format the audit record, produce the escalation package when it escalates), each pass carrying a few thousand tokens of context. So a decision whose bare model cost is a couple of cents has a real compute cost closer to twenty, and that is before a human touches it. The exact figure is illustrative and will move; the method is the durable part. Count the model re-entries and the context each one carries, and you have your multiplier, which is the number that actually decides the case, not the sticker price per token. Suppose the agent resolves 70 percent of requests autonomously and escalates 30. The 70 percent cost cents each. The 30 percent still cost a human review, so the agent does not remove that cost, it concentrates the human on the cases where judgment actually pays. The break-even is not “agent cheaper than human per task”; it is “the fully loaded cost, including the supervision of the escalated minority, below the cost of humans reviewing all of it, with the wrongful-refund risk priced in.” For this agent, at this escalation rate, it clears, but only because the escalation rate is low enough that the supervised minority is truly a minority. Go/no-go gate: build it if the suitability tests pass and the loaded cost including supervision beats the all-human baseline. If the only way the math works is by under-funding the human review of the escalated cases, the answer is no, because that is the Cigna failure waiting to happen.

Where the boundary sits, and why. The agent may resolve refunds on its own up to a dollar limit we set deliberately, because that single number decides how much trust we extend and how much exposure we accept. Above the limit, outside the window, or when a fraud signal fires, the agent routes to a human. We are choosing, explicitly, that a wrong escalation (a borderline case sent to a person who did not strictly need it) is acceptable, and a wrong autonomous refund on a fraud-pattern case is not tolerable even once. That asymmetry is the judgment the room should argue about, because the limit and the triggers are where this product’s risk lives.

Accountability and how we will know. A refund the agent should not have issued is the company’s loss and the support organization’s responsibility; we name the human who owns that before launch, because a team that cannot answer “who is accountable” answers it in the moment by blaming whoever is nearest. We will know the agent is drifting by watching the gap between completion and genuine task success, the rate of refunds later clawed back, and the override pattern on escalations.

What success looks like, and what it does not. Success is not the share of refunds resolved without a human; an agent that resolves everything has almost certainly approved things it should have questioned. Success is that the resolved cases would survive a manager’s review, the escalated cases truly needed a human, and the rare wrong case was a tolerable wrong, not a never-ship one.

The open questions the room still owes. Three decisions are not made yet, and naming them is the point, because each one will otherwise be made silently by whoever ships first. `[NEEDS CLARIFICATION: the dollar limit, who sets it, finance or product, and against what loss tolerance?]` That number is the whole risk posture and it does not belong to engineering. `[NEEDS CLARIFICATION: when the customer’s account is high-value and near churn, does retention authority override the refund limit, and whose budget absorbs it?]` That is a cross-functional call between support and the revenue owner, not a default the agent should pick. `[NEEDS CLARIFICATION: who is the named accountable owner for a wrongful autonomous refund, before launch, not after the first one?]` Left unmarked, it gets answered in the incident review by pointing at whoever is nearest. The marked question is the room admitting what it has not yet decided; that admission is what the Executable Brief cannot manufacture and what this brief exists to force.

Brief 2: The Executable Brief

Audience: the prototype, the coding agent, and the backlog. Purpose: to specify the experience, the behavior, and the governance precisely enough to (a) generate a working prototype this week and (b) seed a buildable backlog, with the supervisory layer written in as requirements. Derived from the Human Brief; where that one argues, this one specifies.

The shape below is deliberately close to the spec-driven development tooling now in the field, GitHub’s Spec Kit the clearest 2026 instance, and borrows three of its disciplines on purpose. First, requirements are numbered and written as testable statements, not prose, so each one can be checked off rather than interpreted. Second, every place the spec is silent gets an explicit `[NEEDS CLARIFICATION]` marker rather than a quiet assumption, because the marker is the difference between a gap you decided to leave and a gap the coding agent will fill for you with whatever the simplest path suggests. Third, the behavior is graded against acceptance scenarios in a given / when / then form a machine can run, not a paragraph a human nods along to. The structure is borrowed; the supervisory content, the Channel 2 requirements, is the part those tools do not give you and the part this brief exists to add.

Template

An Executable Brief should contain, structured for a system to act on:

System type. Which of the three this is (suggestion engine / copilot / autonomous actor), because each has a different accountability model.
Outcome spec. The outcome the behavior is graded against, stated as a target over a distribution of cases, not a pass/fail story.
Behavior (Channel 1), as numbered requirements. Inputs, available actions, tool and data scope, written as testable lines (FR-1, FR-2, …) each phrased as something the system must do, with any unspecified detail flagged `[NEEDS CLARIFICATION]` rather than assumed.
Acceptance scenarios. The behavior target expressed as runnable cases in given / when / then form, including the hard ones, so “it works” has a definition a system can check instead of a reviewer’s impression.
Experience (the supervisory UX). What the human supervising the agent sees and does: the approval moment, the decision package, the surfaces that make oversight real rather than nominal.
Governance (Channel 2), as numbered requirements. The autonomy boundary, the audit surface, the recovery workflow, and the instruments, each a buildable, checkable line (GR-1, GR-2, …), not a principle.
Success criteria, measured. The outcomes that say the agent is working, stated as numbers over the distribution (SC-1, SC-2, …) and technology-agnostic, so they survive a change of model or framework.
Eval set / golden dataset. The curated cases with the endorsed outcome for each, including the hard ones and the never-ship failures.
The gate it must pass. The non-negotiables checked before the spec proceeds to build, the Channel 2 analog of Spec Kit’s constitution check: the boundary is enforced in the execution path not the prompt, the audit record is reconstructable, the kill switch is reachable. A spec that violates one of these does not proceed, however good the behavior looks.
Release gate. The two halves (Channel 1 ready and Channel 2 ready) that together set the launch autonomy level.
For the prototype / for the backlog. What to generate this week to test the bet, and how the requirements decompose into buildable work.

Worked example: the refund agent

System type. Autonomous actor within a bounded authority; copilot (human-approval) above the boundary.

Outcome spec. Resolve refund requests such that a senior support lead would endorse the resolution on review. Resolve clear low-amount cases autonomously at or above the agreed rate; escalate high-amount, out-of-policy, or anomalous cases; never autonomously approve a case carrying a fraud signal.

Behavior (Channel 1), as numbered requirements. Inputs: refund request (order ID, amount, reason, customer ID, account history, return-window status, fraud signal). Then the requirements, each one a line you can check off:

FR-1. The agent MUST issue a refund, deny with a stated reason, request missing information, or escalate with a decision package, and MUST take exactly one of these on each request.
FR-2. The agent MUST read order records, account history, and the fraud signal, and MUST NOT read records for any other customer.
FR-3. The agent MUST be able to write a refund up to the autonomy boundary and MUST NOT take any action outside the refund domain.
FR-4. The agent MUST write an audit record for every resolution, including the ones it escalates.
FR-5. On a request carrying a fraud signal, the agent MUST escalate and MUST NOT issue a refund autonomously, with no exception.
FR-6. When the customer’s stated reason conflicts with the order record, the agent MUST `[NEEDS CLARIFICATION: trust the record, trust the customer, or escalate? unresolved, and the coding agent must not pick for us]`.

The `[NEEDS CLARIFICATION]` line in FR-6 is the point of the whole exercise. That conflict is a real decision with real exposure, and leaving it unmarked is how it gets decided silently, in code, by whoever takes the simplest path. Marked, it is a question the room still owes an answer to before this ships.

Acceptance scenarios. The behavior target, written so a system can run it rather than a reviewer nod at it:

Given an in-window defective item under the boundary, when the agent processes it, then it issues the refund autonomously and writes the audit record.
Given a request ten times the typical amount with a fraud signal, when the agent processes it, then it escalates and issues no refund. A single autonomous approval here fails the eval.
Given a request just outside the return window from a customer right on the merits, when the agent processes it, then it escalates with a recommendation, not an auto-denial.

Experience (the supervisory UX). For every escalation, the human sees a decision package, not a raw request: what the agent knows, what it is uncertain about, the consequence of each option, and its recommendation, with the policy and evidence attached. The human approves, modifies, or denies in one place, and the decision and who made it are recorded. The experience target is that a competent reviewer can exercise real judgment in the time the queue actually allows; if the volume makes that impossible, the boundary is wrong, not the interface. The supervisory surface also exposes the agent’s confidence so the reviewer can tell a sure case from a marginal one.

Governance (Channel 2), as numbered requirements. The supervisory layer, each line buildable and checkable:

GR-1. Auto-resolve refunds ≤ [LIMIT, set with finance]; route to a human if the amount exceeds LIMIT, the request is outside the return window, or a fraud signal is present. The boundary MUST be enforced in the execution path before the action fires, not logged after.
GR-2. Every resolution MUST write an immutable audit record, request, amount, policy applied, evidence, agent and prompt version, and the human authorization where one occurred, reconstructable by a stranger later.
GR-3. A reversal path MUST exist: clawback within the window, escalated approval to reverse after it. Rollback time is a measured instrument.
GR-4. The supervisory surface MUST produce five instruments, or it was not designed: the task-success-versus-completion gap, the unintended-action rate, override frequency on escalations, clawback rate, and rollback time.

Success criteria, measured. Technology-agnostic, stated over the distribution so they survive a model swap:

SC-1. At least the agreed share of requests resolved autonomously, with manager-review endorsement on a sampled audit at or above target.
SC-2. Zero autonomous approvals on fraud-set cases. Not “low.” Zero.
SC-3. Clawback rate on autonomous refunds below the funded threshold, measured monthly, with the trend flat or falling.

The gate it must pass. Before this spec proceeds to build, three non-negotiables, the Channel 2 constitution check: the boundary in GR-1 is enforced in the payment path and not in the prompt; the audit record in GR-2 reconstructs a decision for someone who was not there; the kill switch is reachable in one step. A spec that fails any of these does not advance to the backlog, no matter how well the behavior scores, because a good Channel 1 on a missing Channel 2 is exactly the failure this book is about.

Eval set / golden dataset. A curated set of refund requests, each paired with the outcome a senior support lead endorsed, including the hard cases: the in-window defective item (autonomous refund, the floor case); the just-out-of-window customer right on the merits (escalate with recommendation); the non-defective item, high-value account near churn (escalate, do not auto-deny); the ten-times-typical amount with a fraud signal (escalate, never auto-approve, a single autonomous approval here fails the eval). Acceptable failure: a wrong escalation is tolerable and expected; a wrong autonomous refund on a fraud-set case is a never-ship failure.

Release gate. Channel 1 ready: resolves the eval set at the agreed rate, no fraud-set auto-approvals. Channel 2 ready: boundary enforced pre-action, escalation package and approval path live, audit record writing, kill switch reachable, the five instruments producing. The launch autonomy level is set by both halves, not by Channel 1 alone.

For the prototype / for the backlog. This week: generate the loop, request in → boundary check → resolve or escalate → audit write, against the eval set, to learn whether the boundary and triggers are set right. The prototype is for deciding, not shipping. For the backlog: each governance requirement is a buildable line, boundary enforcement, decision-package UI, audit pipeline, clawback workflow, each instrument, plus the deterministic shell (screens, integrations, order-system reads) which still gets ordinary user stories. The agent’s behavior gets the outcome spec and eval set; the shell gets the stories. Both are in the backlog; only one is new.

Notice that the brief is read by two different builders, and the same line means different work to each. Take a requirement the refund agent also carries: the agent must not read the customer’s stored payment details, only the order and the refund amount. The coding agent vibing the MVP implements that as an instruction and a narrow tool scope, honored as far as the agent cooperates, enough to test the flow. The engineers building the production system implement the same line as architecture: a data-access layer that returns the order and amount and never exposes the payment record, so the agent cannot read what it is not handed, whether it tries to or not. One requirement, an instruction in the thing that proves the bet and an enforced structure in the thing that ships. That hardening, from a sentence the agent follows to a boundary it cannot cross, is the enforcement principle applied to the brief itself, and it is why the Executable Brief is written for the architect as much as for the agent.

Two documents, one agent, both channels in each, and a template under each you can lift and adapt. The Human Brief is where the team decides whether to build and where the boundaries are; the Executable Brief is where that decision becomes experience, behavior, and governance a prototype and a backlog can build, with the supervision written in as requirements so it is constructed rather than assumed. This is the artifact the operating model produces, and it is where the new job concentrates: not in the agent, which is becoming cheap to generate, but in the brief that decides what the agent is allowed to do and how the people around it will know when it is wrong. The refund agent is one example. The shape is the part to keep.

The Agent This Book Was Written With Appendix B: The Field Manual