The agentic use case is a job description

We have sat in enough rooms where "agentic AI" was proposed to notice which proposals survive contact with a chief financial officer. It is never the one that opens with the model. It is the one that opens with a job title.

The format is simple enough to fit on a slide, and we now insist on it before any agent is built for a customer. Four boxes: the person, their problems, the agentic flow, the business impact. Each box has a discipline.

The person

Not "the business". Not "the service function". A named role, described by what they actually do on a Tuesday: the claim approver, who validates dealer submissions by matching invoices, service reports, warranty policy and check sheets across several systems, by hand. The description has to be recognisable to someone who does the job. If it is not, the use case is a technology looking for a problem, and the rest of the slide is fiction.

Starting with the person also fixes the scope. An agent for the claim approver is not an agent for the whole claims department; it does that person's reconciliation. That is what makes it buildable in weeks rather than a programme.

The problems

Three or four, in the person's own vocabulary, and each one has to be a problem today, not a hypothetical. "Manual checks across invoices and check sheets." "Slow processing." "Approvals that differ between approvers, so dealers complain." "Cash blocked in claims nobody has opened." The test of a good problem is that the person nods. The test of a bad one is that it needs explaining.

The problems box is also where the honest scope of AI appears. Some of these problems are retrieval problems: the information exists, it is just in four places. Some are arithmetic: the rule is known, applying it is tedious. Some are judgement: this claim is unusual and someone has to decide. Sorting the problems that way, before anyone talks about a model, tells you which parts of the flow can run alone and which cannot.

The flow

Five steps, in order, each one a verb. The dealer submits a claim. The agent detects it. Validation runs against policy, eligibility and consistency. The agent proposes a decision with its evidence. A person approves or rejects, and the dealer is notified.

The discipline in this box is to say, for each step, whether it is computed or generated and whether a human is in it. Detecting a new claim is a trigger. Validation against policy is arithmetic — deterministic, repeatable, auditable, and the same for every claim, which is what fixes the "inconsistent approvals" problem. Proposing a decision with reasons is where the model earns its place: reading the evidence and writing the explanation a person can check. And the approve step is a human, on the trigger, because money moves.

That last line is what gets the proposal approved. A flow that ends with "the agent approves the claim" fails in the room, and it should. A flow that ends with "the agent puts a validated claim with its evidence in the approver's queue, and clean claims can be approved in bulk" describes something the finance team can sign. We have written about where we draw that line and why it is not timidity: deterministic signals, AI delivery is what makes the numbers checkable and the conversation about them natural.

The impact

Four lines, each traceable to one problem. "Approver capacity goes to exceptions" answers the manual checks. "Decisions are consistent because the rules are written down" answers the dealer complaints. "Faster reimbursement" answers the blocked cash. Impact that does not trace to a stated problem is a wish, and it is the first thing a sceptic will strike out.

We also keep numbers off this box until there is a measurement behind them. A claimed percentage without a baseline damages the credibility of everything else on the slide; a qualitative impact that is obviously true does not. Measure after the first month and put the number in then.

Why the format works

Because it makes the three hard conversations happen in the right order. The person box forces the question "who is this for?" before anyone is invested. The problems box forces "is this real?" The flow box forces "where does the agent stop?" — the question every governance review will ask, answered before the review. And the impact box forces "what will we measure?", which is the question that turns a pilot into a programme.

It also travels. The same four boxes describe a service outreach executive whose maintenance leads are scattered across logs, a parts manager reordering from a spreadsheet, a key account manager scanning tender portals by hand. We have written up the use cases xMatix runs today in exactly this form, partly so customers can hold them against their own operation, and partly because writing them that way is how we check ourselves: if a use case will not fit the four boxes honestly, it is not ready to be claimed.