Agent Flow Blueprint: a spec format for products that branch on conversation.

Why PRDs break for agents

A traditional PRD describes screens and user stories. Click this, see that. An agentic product does not work like that. A patient says something, the agent decides which flow it belongs to, hands off to a sub-agent, calls a tool, changes what the screen shows, and sometimes loops back because the answer was unclear.

Every one of those decisions needs a spec: what the step is for, when it is allowed to move on, what it calls, and what the user sees. And every one of them changes weekly as we learn from real conversations.

What we tried first

Three ways to spec an agent

Option A

PRDs and user stories

• −Describe screens, not branches
• −No place to say when a step may move on
• −Written once, stale by the next sprint

Didn’t fit

Option B

FigJam flows, long docs and sample scenarios

• +Familiar to everyone
• −Three artifacts to remake on every change
• −Drifted apart as flows changed

Retired

Option C

A living blueprint, built in Claude Code

• +One page per workflow: spec and tracker in one
• +Status, flags and bugs at the step level
• −Someone has to keep it current (product does)

In daily use

What I built

I built the Agent Flow Blueprint and Tracking System myself, in Claude Code. It treats each agent workflow as a living blueprint rather than a document: the flow, its steps and the rules between them sit in one place, and every step carries its own status, so the spec and the progress tracker are the same thing.

Anatomy of a living blueprint

stableflaggedin testing

The spec and the progress tracker are the same page.

1. Step Greet + identify
2. Router Understand the need
3. Sub-agent Symptom intake
4. Step Suggest specialty
5. Step Offer slots
6. Tool call Confirm + remind

Sub-agentSymptom intakeflagged

Goal

Ask follow-ups until the complaint is clear.

← Why this step exists

Moves on when

Chief complaint, duration and key negatives are captured.

← The exit rule AI engineers prompt against

Tool call

save_intake()

← What backend must persist

UI shown

Body-part picker

← What mobile renders at this stage

Status

Flagged

← What QA and leadership track

Today it holds 30+ agent workflows, with step-level flags, performance and bugs.

How the team uses it

One source of truth, six readers

Living PRDAgent Flow Blueprint

AI engineersDerive prompts and flow configuration from it.

MobileBuilds the dynamic UI against each flow’s stages.

BackendMaps what data each step needs to save.

QATests against it.

LeadershipCEO, CTO and head of engineering track progress and leave feedback.

ProductKeeps it current. That’s me and the team.

What changed

The bigger change is in how we talk. When someone says “the intake flow is broken”, we now point at a specific step, not at a long document.

Why it matters beyond Pranik

Every team building agents is going to hit this wall. The interesting product question is not only what the agent should do, but how a cross-functional team should describe, build and track what it does. This tool is our team’s answer, built with the same AI coding tools that are changing how products get made.