The first product brief for an agentic workflow
The ten decisions that turn a broad agent idea into a buildable and testable internal product.
Most weak AI builds do not fail because the model was incapable. They fail because the instruction concealed a dozen product decisions inside a paragraph.
“Build an agent that helps employees find answers and route requests” sounds like a reasonable starting point. It is not yet a product brief.
What counts as an answer? Which sources are approved? When is routing automatic? What happens when a request belongs to two categories? Who sees sensitive fields? Does the system make a decision or prepare one? What observable behavior would tell us the build is correct?
An AI coding agent can produce something quickly from the original sentence. The speed makes the missing decisions more—not less—important.
Consider a fictional People-team request: “I took a course. Can I be reimbursed?” A first build should not improvise an answer from whatever document it finds. It should collect the course details and receipt, consult the current approved learning policy, show the relevant passage, flag anything missing or conflicting, and prepare the request for the designated reviewer. The reviewer—not the agent—decides whether to approve it. That is a small product with an observable result.
A product brief is a decision document
For an agentic workflow, the first brief needs ten sections.
1. The user promise
One sentence that says who can do what, under which boundary. For example: “An employee can submit an internal request and receive a sourced next-step recommendation for human review.”
The final four words matter. They prevent “recommendation” from quietly becoming “decision.”
2. The user and the owner
The user experiences the product. The owner is accountable for its operation. They may be different people. Name both.
3. The trigger and happy path
Describe the event that starts the workflow and the sequence through a useful result. Keep it end to end. A complete narrow path teaches more than five disconnected features.
4. Required inputs
Define fields, formats, allowed values, sensitive information, and what happens when something is missing. “Ask a follow-up question” is a feature and needs acceptance conditions.
5. Structured outputs
Do not begin with a beautiful paragraph. Define the output contract: classification, evidence rows, recommendation, confidence, conflict, reviewer action, and source identifiers.
Structure makes evaluation possible.
6. Business rules
Write what is deterministic. A request above a threshold may always require a certain approver. A missing required field always blocks submission. Do not ask a model to improvise rules the organization has already decided.
7. Human decisions
Identify who can approve, revise, reject, or escalate. Show what evidence they receive and how their disposition is recorded.
8. Edge cases and prohibited behavior
Include incomplete, contradictory, duplicated, sensitive, out-of-scope, and malicious inputs. State what the product must never do.
9. Acceptance fixtures
Write five synthetic cases before the build. For each one, describe the expected observable behavior. Include at least one case the system should refuse or escalate.
10. Non-goals
Name what this version will not solve. Non-goals are not an apology. They protect the first useful product from becoming an untestable platform ambition.
The transfer test
A good brief passes a simple test: a capable builder can implement it without inventing the organization’s policy, and a reviewer can decide whether it works without relying on taste.
That standard changes how leaders work with AI coding agents. The leader is not required to know every framework or write every line. They are required to make the product decisions legible.
The brief becomes context that persists across prompts. Acceptance fixtures become a test set. Non-goals resist drift. Human decisions remain visible. The agent can move faster because the organization has stopped outsourcing ambiguity to it.
For the fictional learning request, a reviewer should be able to test at least these cases before launch:
- A complete request with a current policy source: show the cited passage and prepare a review-ready summary; do not approve payment.
- A missing receipt: ask for it and leave the request incomplete.
- Two approved sources that disagree: show both citations and route the conflict to a policy owner.
- A request outside the published policy: mark it for human review rather than inventing an exception.
- A sensitive personal detail: keep it out of the generated summary unless the reviewer needs it.
These cases do more for a builder than “make the agent accurate.” They name what correct behavior looks like when the path is easy, incomplete, contradictory, or sensitive.
Try this this week
Take the AI build your team is discussing. Write the user promise, structured output, three business rules, two human decisions, five test cases, and three non-goals.
If the exercise feels difficult, the difficulty was already present. The brief simply made it visible early enough to resolve.
The Internal Product Leader Lab uses this brief to direct a complete build: an Internal Request and Knowledge Hub that accepts a request, uses approved evidence, prepares a cited recommendation, records human disposition, and can be operated by a named owner.