Hey hey,
Quick gut check. You know how to write a solid PRD. You define scope cleanly, make trade-offs without drama, and ship on time.
That muscle memory works great for features.
Then you touch AI agents, and everything feels off. The usual “add a button,” “add a rule,” “add a state” thinking breaks. Output quality varies. The agent loops or stalls.
And eventually someone asks, “What exactly did we ship?”
That happens because feature-first thinking does not work for agents. With AI agents, you are shipping decision logic, workflows, and failure modes.
Let’s fix that.
You will learn what agents are, why a normal PM toolkit isn’t enough, and a Monday-morning process to map agent decision flows that work.
I will also give you a simple framework for when to use a deterministic workflow versus a true agent and how to avoid the classic AI pitfalls.
Let’s go!
What’s an AI Agent?
When people say “AI agent,” they usually mean more than simple automation, but not everything called an agent actually is one. Think of AI systems in three levels.
Level 1: LLMs (ChatGPT, Claude, Gemini) are great at turning an input into an output. You ask. They answer. That’s it.
Level 2: AI workflows add steps and tools. “When the user asks about a meeting, look in Google Calendar first, then reply.” Deterministic path (you decide the path.)
Level 3: AI agents replace you as the decision maker in the workflow. They reason about the goal, choose which tools to call, act, observe results, and iterate. You do not handhold each step.
You will frequently hear these two terms at all levels:
RAG (retrieval-augmented generation): The model retrieves information from documents or APIs before generating an output. This is a retrieval step, not a strategy. RAG is a common workflow pattern used by both workflows and agents.
ReAct: Reason + Act. This is the standard agent loop: reason, take action using tools, observe the result, and repeat until done.
A workflow is an SOP you wrote for an intern.
An agent is a junior hire who reads the SOP, decides which steps apply, asks questions when things are unclear, and adapts to the situation.
Why Does Feature-First PM Thinking Fail with Agents?
That’s because features describe surfaces, not decisions.
Features tell the user where to click. Agents need to know what to do next.
Features take fixed paths. Agents need conditional logic that adapts mid-flight.
Features optimize interaction. Agents optimize outcomes.
I learned this the hard way. I specced “Summarize customer emails” as a neat “Generate Summary” button. We shipped it. It worked… sometimes.
But the real job-to-be-done was a decision tree:
Is this email a bug, a feature request, or spam?
Should we reply, escalate, or close?
What info is missing? Where do we fetch it?
What’s the outcome we want? Time saved? Resolution rate?
Once we mapped the decisions and the tools, the agent delivered value. And that’s because the workflow finally matched the work.
So, think in workflows and decision trees.
Here’s the mental shift. Design the flow first, not the feature. For example:
Define the goal: “Resolve customer issue in under 5 minutes with a confident, correct answer.”
Map decisions: “When do we search docs vs. escalate vs. ask clarifying questions?”
Choose tools: “Which API answers what? What context should the agent retrieve?”
Add guardrails: “When to fail safe? When to ask a human? What are the stop conditions?”
In AI agent product management, you are not writing a feature spec. Instead, you are drafting a playbook that the agent can follow and adapt.
The Agent Stack (use this as your blueprint)
This is the stack I put into every agent PRD:
1) Goal and success criteria
A PRD defines the outcome the agent owns and what success looks like.
It specifies target metrics such as success rate, cost per task, average number of iterations, and the percentage of cases handed off to humans.
2) Inputs and context
The PRD describes how user intent reaches the agent, whether through free text, structured forms, or system triggers.
It also documents what memory and context the agent can access, such as documents or CRM data, and how fresh or reliable that context is.
3) Decision tree (the backbone)
The PRD also includes decision paths that map intent to actions, such as routing billing issues to invoice checks and payment status verification.
All this before drafting a response. It also includes clear “ask-before-act” branches for actions that carry risk or irreversible consequences.
4) Tools and permissions
The PRD lists all external tools and APIs the agent is allowed to call.
It defines permission scopes, rate limits, and whether the agent has read-only or write access in sandbox or production environments.
5) Reasoning loop
The PRD defines the rules of the agent’s reasoning cycle, including the maximum number of iterations and stopping conditions.
It explains when the agent should re-prompt itself, request clarification, or critique its own output before proceeding to the next step.
6) Safety and guardrails
The PRD clearly mentions the boundaries, such as refusing refunds above a certain amount or sending customer emails without human approval.
It also includes hallucination controls, such as mandatory source citations and confidence boundaries before taking action.
7) Observability
The PRD requires detailed logs for inputs, outputs, reasoning steps, and tool calls. It ensures replayability, so failures or unexpected behaviors can be audited later.
8) UX surface
The PRD defines when the agent should expose its thinking versus work silently. It also explains how the agent asks clarifying questions in a way that minimizes friction and user annoyance.
9) Evaluation harness
The PRD specifies how the agent will be tested using golden tasks, offline evaluations, and shadow mode comparisons. It includes automatic scoring mechanisms and alerts to detect performance drift over time.
10) Human-in-the-loop
The PRD identifies where humans can intervene in the agent’s workflow and under what conditions. It also defines feedback loops that allow human input to improve the agent’s behavior continuously.
Workflow or agent, which should you build?
Most teams jump straight to building an agent because it sounds more advanced.
That is usually the wrong starting point. Before you choose between a workflow and a true agent, use this simple litmus test.
Choose a deterministic workflow if:
The path is well-known and stable (file conversion, invoice parsing)
The cost of a wrong decision is high
You can list steps cleanly with minimal branching
Latency needs are strict and predictable
Choose an agent if:
The goal is open-ended (“prepare me for tomorrow’s customer meeting”)
You can’t predict the exact sequence of steps
The agent must decide among multiple tools based on context
Iteration and self-critique improve outcomes meaningfully
To start in the middle ground, you can start with a workflow, then give the agent limited decision rights in narrow branches.
Treat autonomy like permissions, granted gradually, with monitoring.
For example, let’s build a workflow and agent for customer support triage. The goal is to help customers get correct answers fast, without escalating every issue to a human.
Workflow version (rule-based)
The system follows a fixed script.
It classifies the ticket as billing, product, or account.
It fetches the matching help document.
It drafts a reply using that document.
It sends the response.
This works when problems are repetitive and low risk.
If the document is outdated or the customer’s case is unusual, the workflow still responds, even if the answer is wrong.
Agent version (decision-based)
The system decides what to do at each step.
It reads the ticket and decides whether it understands the problem or wants more information. Then, it chooses the next action:
Search the documentation if the issue looks standard.
Run a diagnostic if something looks broken.
Ask a clarifying question if the request is unclear.
It assembles an answer with citations to the source it used.
It evaluates risk:
If the customer is high value or money is involved, it escalates.
If confidence is high and risk is low, it resolves automatically.
If the situation feels unclear, the agent stops and asks for help instead of guessing.
The workflow follows instructions. The agent makes decisions. Workflows are faster and safer for simple cases. Agents are better when judgment, context, and risk matter.
That is the difference you choose when you decide what to build.
How to design your agent like a PM in 10 steps?
Pick one high-value job to be done. Start with a single, narrow problem that has a measurable impact, such as reducing first response time in customer support by 50%.
Define the outcome. State what success looks like in operational terms. For example, the agent resolves Tier-2 support issues with less than 5% escalation error.
Draft the decision tree before writing any code. Map the logic using simple IF–THEN branches covering intent detection, tool selection, escalation paths, and stop conditions. Keep it rough.
Assign tools to each decision point. List which tools the agent can use at each step, such as RAG docs, CRM, billing APIs, or Slack, and define whether access is read-only or write-enabled.
Add explicit guardrails. Define hard rules, such as asking for human review if confidence drops below 0.7, or requiring approval if the estimated financial impact exceeds $100.
Define the reasoning loop. Set limits on how the agent thinks and acts, such as a max of four tool calls per task and a compulsory self-critique step that checks sources and intent clarity.
Instrument the system end-to-end. Log every input, reasoning step, tool call, and outcome, because unobservable agents cannot be debugged or improved.
Build an evaluation harness. Create a fixed set of 30 golden tasks and score the agent on task success, tool precision, iterations, cost, and latency, running these tests on a regular schedule.
Launch in shadow mode first. Let the agent generate responses while humans still handle the final output, and compare results to identify gaps and tighten logic.
Increase autonomy in controlled stages. Enable auto-resolution only for low-risk cases first, and expand the agent’s authority gradually as performance metrics remain stable.
Common pitfalls (and how to dodge them)
Building the UI first. Teams often design screens before they understand how the agent thinks. This locks in the wrong abstractions.Fix: Define the decision tree and tool permissions before designing a single pixel.
“Just add RAG,” thinking. Retrieval is treated as a silver bullet instead of a controlled step in the flow. This leads to confident but wrong answers.Fix: Treat RAG as a retrieval operation. Specify what is retrieved, when retrieval happens, and how results are validated.
Prompt rot. Prompts grow organically, drift over time, and quietly break behavior. No one knows which change caused what.Fix: Centralize, version, and test prompts. Manage prompts with the same discipline as code.
No stop conditions. Agents keep looping because “completion” was never clearly defined. More thinking does not mean better outcomes.Fix: Set hard limits on iterations and tool calls, and explicitly define what “good enough” means.
Missing human-in-the-loop design. Humans are added reactively after something goes wrong. Overrides feel clunky and slow.Fix: Decide upfront where human approval is required, and make it easy for humans to override and provide feedback.
No offline evaluation. Agents are judged only in production, where failures are expensive and noisy.Fix: Use golden tasks and benchmark runs, and track performance drift on a regular cadence.
Too much autonomy too early. Agents are trusted before they have earned it, leading to avoidable mistakes.Fix: Treat autonomy as permission. Expand it only when metrics consistently hold.
How to measure agent success?
I think about agents like hiring a junior PM.
You give them a goal, constraints, and tools.
You set guardrails and a playbook.
You watch the first few cycles closely.
You expand the scope as they earn trust.
That’s AI feature development pm in a sentence. And it’s why AI agent product management forces you to think operationally, not cosmetically.
Build the playbook. Later, build the buttons.
Then, track these five metrics from day one:
Task success rate. The percentage of tasks completed correctly without human fixes.
Human handoff rate. The percentage of tasks escalated to humans, along with clear reasons for escalation.
Tool call accuracy. How often does the agent select the correct tool at the right moment?
Cost per resolved task. The total cost of tokens, API usage, and compute per successful outcome.
Latency. Both time to first output and time to final resolution.
Iteration count per task. High iteration counts usually mean unclear decision trees or weak prompts.
But what about safety and hallucinations?
Safety is a core product requirement. Ask for citations for factual claims, and force the agent to confirm when sources are missing.
Gate sensitive actions like refunds, outbound emails, or data writes behind human approval or a secondary critique step.
Sanitize inputs and remove PII unless it is strictly necessary for task completion. Log every input, decision, and action.
Make all runs replayable for audits.
If this feels heavy, that is the point.
Agents can act. Systems that can act can also cause damage. Your job is to make correct actions easy and incorrect actions impossible.
In a Nutshell
Agents are just models, tools, and decisions working together in a loop. Features change what users see. Workflows decide what happens.
Start with simple, rule-based flows. Add autonomy only where it clearly helps. Increase freedom slowly, based on results.
Measure everything from day one.
If you cannot see what the agent is doing, you cannot fix it. Your real job is teaching the system how to make good decisions. Build for outcomes.
That’s it for today!— Sid