AI Product Management series
For twenty years the artifact was the PRD. You wrote it, handed it to engineering, watched it get decomposed into an epic, and the team built it. That model worked because the hard part was building. With agentic AI, the hard part is no longer building. A coding agent will produce a working prototype of almost anything you can describe in an afternoon. The hard part is deciding what the agent should do, where its authority stops, and how the people around it will know when it is wrong.
So the artifact splits in two. And the most common way good agent projects go wrong is that the second document gets written and the first never does.
This post is about both documents and the discipline of writing them in the right order.
The decision and the build are different documents
Call them the Human Brief and the Executable Brief.
The Human Brief is the document a room argues with. It is the PRD's successor, written in prose: the business case, the go/no-go, the cost model, where the boundary sits and why. Its audience is the executive sponsor, finance, engineering, design, and the domain expert. Its purpose is to decide whether to build at all, before anyone writes code.
The Executable Brief is the document a system acts on. It is the epic's successor, written as numbered, testable requirements: the behavior, the supervisory experience, and the governance, precise enough to generate a working prototype this week and seed a backlog next. Its audience is the prototype, the coding agent, and the team.
You derive the second from the first. The decision comes before the specification, always, and skipping the Human Brief is how a team ends up six months into building something nobody ever decided was worth building.
What both briefs share
Here is the part that is easy to get wrong. The temptation is to put the agent in one document and the supervision in the other. That is exactly how the supervision ends up unbuilt.
Both briefs carry both channels: Channel 1, the agent and what it does, and Channel 2, the system that supervises it. The split between the two briefs is by audience and purpose, decide versus build, not by channel.
In the Human Brief, the supervisory layer appears as a decision the room owns: where the boundary sits, what it costs to fund the oversight honestly, who is accountable for a wrong outcome. In the Executable Brief, the same supervisory layer appears as buildable requirements: the autonomy boundary, the approval experience, the audit surface, the eval set. The supervision gets built because it was written into the spec as a requirement, not because someone remembered it at the end.
The Human Brief: the document you argue with
A Human Brief contains, in prose a room can debate:
The problem and the opportunity. What is costing money or going wrong today, in one honest paragraph, including the size.
What you are building, and what you are deliberately not. The intended behavior in plain terms, and the adjacent thing it must not become, which is usually the failure mode of the obvious version. "Resolve refunds automatically" must not quietly become "approve refunds the company should have questioned."
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. The in-window defective item was always going to be refunded; the agent earns nothing there. It earns its place on the request just outside the window where the customer is right on the merits, the high-value account near churn, the amount ten times the others on an account that smells like fraud.
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 finance partner will press on, and the place where the trap lives: the model's token cost per decision is a few cents, far below a human's time, and that is not the real cost. The real cost is the architecture multiplier, orchestration, integrations, the audit pipeline, eval maintenance, plus the human reviewing every escalated case. The break-even is not "agent cheaper than human per task." It is "fully loaded cost, including supervising the escalated minority, below the cost of humans reviewing all of it, with the wrongful-action risk priced in." If the only way the math works is by under-funding the human review, the answer is no.
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. You are choosing, explicitly, which kind of wrong is tolerable and which is never tolerable even once. That asymmetry is what the room should argue about.
Accountability and how you will know. Who owns a wrong outcome, named before launch, not in the incident review by pointing at whoever is nearest. And the instruments that will signal drift 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, which for most agents is "share resolved without a human." An agent that resolves everything has almost certainly approved things it should have questioned.
The open questions the room still owes. The business decisions not yet made, each flagged in the open. A question named here is one the room knows it must answer. A question left out is one that gets answered by default, in code, by whoever ships first.
The Executable Brief: the document a system acts on
The Executable Brief takes three disciplines from spec-driven development tooling (GitHub's Spec Kit is the clearest current instance) and adds the part those tools do not give you.
Requirements are numbered and written as testable statements, not prose, so each can be checked off rather than interpreted. Every place the spec is silent gets an explicit clarification marker rather than a quiet assumption, because that marker is the difference between a gap you decided to leave and a gap the coding agent fills for you with whatever the simplest path suggests. And the behavior is graded against acceptance scenarios in given/when/then form a machine can run.
The structure is borrowed. The supervisory content, the Channel 2 requirements, is the part this brief exists to add.
It contains the system type (suggestion engine, copilot, or autonomous actor, because each carries a different accountability model); an outcome spec stated as a target over a distribution of cases, not a pass/fail story; the behavior as numbered functional requirements (FR-1, FR-2 ...); acceptance scenarios including the hard ones; the supervisory experience, what the human sees and does at the approval moment; the governance as numbered requirements (GR-1, GR-2 ...) covering the autonomy boundary, audit surface, and recovery workflow; measured success criteria stated as numbers over the distribution; the eval set with the endorsed outcome for each case; and the gate the spec must pass before it proceeds.
One functional requirement is worth seeing, because it is the whole point of the exercise. For a refund agent: When the customer's stated reason conflicts with the order record, the resolution is unresolved and flagged for clarification: trust the record, trust the customer, or escalate. The coding agent must not pick for us. That conflict is a real decision with real exposure. Leaving it unmarked is how it gets decided silently, in code, by whoever takes the simplest path.
And one governance requirement that names the non-negotiable: The boundary must be enforced in the execution path before the action fires, not logged after. A boundary that lives in the prompt is a suggestion. A boundary in the payment path is a control.
Why not just write a user story?
A working PM will object that this is a lot of apparatus for what used to be a user story and an acceptance criterion. The comparison is the whole argument.
The old way writes the refund behavior as a story. As a customer, when I request a refund for a defective item, the agent issues the refund, so that I am made whole without waiting. It is clean. It would pass grooming in any backlog in the world. And it is the wrong primitive, because it describes the case that was never hard. What the story cannot say is what the agent should do with the request just outside the window, or the churning customer worth more than the refund, or the amount that smells like fraud. Those are the cases the agent is actually judged on, and the story has no field for any of them.
The reason is structural. The user story works because ordinary software is deterministic: one correct output, and a test that runs once and passes is a real answer. None of that holds for an agent's judgment. The output is a distribution. "Correct" is a judgment, not a binary. A test that passes once tells you little, because the next run may differ.
So the work-unit for the agent's behavior shifts from the user story to an outcome-centric spec: the outcome you want, the bounds the agent must stay inside, and the eval set that grades whether it got there, including what acceptable failure looks like. A deterministic spec says do X then Y. An outcome-centric spec says achieve this outcome, within these bounds, and here is how we will know.
The user story is not dead. The deterministic shell around the agent, the orchestration, the integrations, the screens the user clicks, is still ordinary software and still gets ordinary stories. What resists the story is the probabilistic core, the agent's judgment itself. The signal to watch for: when you find yourself writing an acceptance criterion for an agent's judgment and it reads as pass/fail, that is the deterministic tool on the probabilistic core, and the case you are not writing down is usually the one that reaches the person the agent affects.
The operating model in one breath
Decide in the Human Brief. Specify in the Executable Brief. Build the agent inside the boundary the brief set. Watch it for as long as it runs. Everything downstream, the runtime design, the evals, the production observation, is the brief's requirements made real, and after launch the supervisory track keeps running while the rest winds down.
Two documents, in order. Write the second one without the first, and you have built something well that nobody decided to build.
Bluesky
