Most requests are not wrong. They are unverified.

Unverified is a state, not an accusation

The usual complaint about intake is that requests are badly written. Rewrite them more clearly, the thinking goes, and delivery will follow.

That is rarely the problem. Most requests are perfectly clear. What they lack is anything a reader can check. “Customers keep asking for this” — which customers, and where is that recorded? “Compliance requires it” — which clause? “The old system does this already” — does it?

A request is not ready because it reads well. It is ready because every claim in it can be traced to something.

Until then the request is not wrong. It is unverified, which is a different thing and a fixable one.

Three things every claim needs

A claim becomes usable when it carries three attachments:

• Origin — who asked for this, and what evidence sits behind it. A support ticket, a customer interview, a clause, a measured number.
• Spec — what exactly has to be true for this to be done. Not a description of the feature; a condition somebody can test.
• Path — which route this takes through the organisation, and who owns each step of it.

Miss the origin and nobody can defend the priority. Miss the spec and the team builds something defensible that nobody wanted. Miss the path and it waits, correctly written, for someone to notice it.

The whole route, in five minutes

This is the intake workflow end to end — a business request arriving, its claims reviewed against their sources, the requirements document it becomes, the approval it needs, and the backlog it finally turns into.

What the agent drafts, and what it will not decide

The PO Agent reads an incoming request and does the unglamorous part: it names what is missing, checks whether the same thing already exists somewhere in the backlog, reviews whether it fits the product at all, and drafts requirements and acceptance criteria from what it can actually support.

It also says how confident it is, and where it had to infer rather than read. That second part matters more than the first.

What it does not do is decide. It does not set the priority, it does not approve its own draft, and it does not commit anything to a team. A requirement it wrote carries no more authority than a requirement a graduate wrote — it still has to be read by somebody who owns the outcome.

The BRD is the agreement, not the paperwork

For anything larger than a small change, the useful artefact is a document people argue over before a team starts: objectives, scope and the exclusions that matter more than the scope, numbered requirements, acceptance criteria tied to those numbers, the journeys involved, what is in the first release and what is explicitly not.

Two things keep it honest. Assumptions and open decisions are written down as assumptions and open decisions, rather than quietly resolved in somebody’s favour. And when the source material changes underneath it, the document is flagged for re-approval instead of silently diverging from what was agreed.

It exports to Word, because the person who has to sign it off often does not live in your delivery tool.

Approval that means something

An approval is worth having only if it was possible to withhold it. That means named reviewers rather than a group inbox, the evidence attached to what they are approving, and the decision recorded against the person who made it.

It is a low bar, and it is the step most often skipped. The cost of skipping it arrives in month four, when nobody can say who agreed to the thing everyone is now unhappy with.

From story map to backlog, without losing the why

Breaking an agreed document into stories is where most of the reasoning normally evaporates. The story survives; the requirement it came from does not, and six weeks later somebody asks why a field is mandatory and nobody knows.

Keeping the requirement ID on the story fixes that for almost no effort. The acceptance criteria travel with it, so the test that proves it is already implied, and the trace runs both ways — from a story back to the claim that justified it, and from a claim forward to everything built because of it.

One deliberate gap: work drafted this way arrives unestimated. An agent can write a story. It cannot tell you what it will cost your team to build, and pretending otherwise is how a plan becomes fiction.

The loop closes at outcomes

The request asked for something. Months later the only question that matters is whether it worked, and most organisations cannot answer it because nothing recorded what “worked” would look like.

Set the measure at intake instead — a baseline, a target, and when you will look — and the loop closes on its own. The request that started everything gets an answer, and the next request from the same source arrives with a track record attached to it.

Features in this article

• Document SpacesDocuments with comments, approvals and version history, kept next to the stories they govern.
• Requirement to Code TraceabilityFollow a requirement to the code that shipped it, and recover requirements from code that exists.
• AI Agents for Every RoleSeventeen persona agents and 59 sub-agents, all reading the same delivery model.