P0 Frame: how to decide if an AI agent is worth building

In this lesson you'll learn:

• how to turn a vague request into a pain register line a sceptic can check;
• the three-question test for whether a job needs a model at all;
• how to size the value honestly and set autonomy one action at a time.

Sound familiar?#

• The requirement arrived as "make it smarter" or "we need an AI assistant".
• The business case says "significantly faster", and nobody has a number.
• Three executives have spent two weeks arguing about how much "the assistant" should be allowed to do.

Each of those is a P0 decision that has not been made yet. They get made anyway, later, in code, by whoever wires the first tool.

What is P0 Frame?#

P0 is the first phase of the agentic PDLC, and it happens before anyone designs anything. It is numbered zero because it is the phase most teams skip, and the number makes skipping it visible.

The product manager is accountable for it. The solution architect brings the evidence: requirements from the people who will live with the system, and the constraints that rule designs out. DevOps sets up the account, the cost tags and the budget alarm, because some of what an agentic system needs bills for existing, not for use.

P0 ends when the pain is a measurement and the AI-fit verdict is recorded.

P0, step by step#

Step 1 · Turn the vibe into a measurement#

Requests arrive as vibes. A vibe cannot be sized, prioritised or handed to a machine, so the first job is to turn it into one line with four facts: who has the pain, how often, what it costs today, and the evidence. At SkyWays, the fictional airline this manual follows, "make rebooking smarter" became, after two days:

Disrupted passengers wait an average of 38 minutes for a rebooking decision; 240 cases a day; 11% are codeshare, which no simple rule can handle; measured cost $9.40 a case.

That line survived to the steering committee on day 90, because every later artefact pointed back at it. If nobody will name a number, write unknown, with an owner and a date, never a guess dressed up as a finding.

Step 2 · Decide whether it is AI at all#

Three questions settle it, asked in order of cost, as in the diagram above. Is it a genuine judgement call: would two competent people differ? If not, it is a rule, and a rule done by a model is slower, dearer and less correct than code. Is there enough volume to be worth a probabilistic system? If not, a person is cheaper. Is a wrong answer recoverable? If not, a person stays in the loop.

Expect two or three of your top five requests to come back as rules. That is the healthy result. At SkyWays the answers were yes, 240 a day, and partly (a proposed rebooking can be withdrawn, a cash refund cannot), so the verdict was agentic, with a gate on refunds.

Step 3 · Size the value, net of running and checking it#

Value is arithmetic, not adjectives. The honest version subtracts what it costs to run (the tokens) and what it costs to check, which is the term most business cases leave out:

A value line is finished when finance can change one assumption and watch the answer move. Re-run it at your target volume before you promise it: the saving scales with volume, but the review load does not fall on its own.

Step 4 · Set autonomy one action at a time#

"How much should the assistant do?" cannot be answered, because the assistant does several things with very different consequences. Ask it per action, and let the answer follow what a mistake costs and whether it can be undone, never what the model is capable of.

At SkyWays the two-week argument ended in twenty minutes once it was recast as four actions:

Nobody had to lose, because nobody had been arguing about the same thing.

Step 5 · Write down what crosses into P1#

P0 hands P1 a short brief: the pain register, the AI-fit record with the rejected alternatives, the value line, the autonomy decision per action, and the architect's typed constraints. This hand-off is soft: a missing number can cross as a placeholder with an owner and a date, but a missing decision cannot, because P1 will make it by accident. What crosses each hand-off.

Where you'll use it#

• Before any budget conversation, so the number in the room is derived rather than hoped for.
• Whenever leadership says "agent-first": the AI-fit record is how you serve that strategy honestly, with evidence for every no.
• On small changes too. A new action added to an existing agent needs its own autonomy decision, even when nothing else about P0 changes.

Why it matters#

When Gartner forecast that over 40% of agentic AI projects will be cancelled by 2027, unclear business value was one of its three causes. P0 is where that cause is removed. It is also the cheapest phase to get right: every decision here costs a document to change, and the same decision made later costs a rewrite.

Key takeaways#

1. P0 turns a request into a measured pain: who, how often, what it costs, and the evidence.
2. Three questions decide whether a job needs a model at all: judgement, volume, recoverability.
3. Value is net of running and checking, and autonomy is set per action from what a mistake costs.

FAQ#

How do you know whether a problem needs AI?#

Ask three questions in order. Is it a genuine judgement call, where competent people would differ? Is there enough volume to justify a probabilistic system? Is a wrong answer recoverable? A "no" to the first means a rule in code; a "no" to the second means a person is cheaper; a "no" to the third means a person stays in the loop.

How do you calculate the ROI of an AI agent?#

Start from the measured pain: cases times minutes saved times the cost of a minute, minus the running cost per case, minus the review load (the share of cases a person checks, times the minutes each check takes). Most business cases omit the last term, which is why the second cycle then looks like a regression.

What are AI autonomy levels?#

A way of deciding how much an agent may do on its own, set per action rather than for the whole system. This manual uses five bands, from read-only (R1) through reversible and hard-to-reverse actions to money (R4, a named approver) and irreversible changes (R5, never delegated). The band belongs to the tool, not to the model.

Who owns P0 Frame?#

The product manager is accountable. The solution architect supplies requirements and constraints, DevOps sets up the account and the cost baseline, and the sponsor needs to see the value line before any budget is agreed.

Apply it in your role#

Across the enterprise. Run P0 as the portfolio funnel. Every candidate gets an AI-fit record, most come back as rules, and the rejected list is published so that teams stop re-proposing the same agents.

The ten-minute workflow. The fastest AI-fit test is to make a model argue against the agent:

For each candidate below, argue as hard as you can that it does NOT need a model: that a rule, a
lookup or a person does it better. Apply three tests: is there a genuine judgement call, is the volume
high enough, is a wrong answer recoverable? Mark each "rule", "person", "assisted" or "agentic", and
say which test decided it. Candidates: <list>

Sources and credits#