Crafting an Agentic Workflow PRD

Introduction

Welcome to the first lesson of our module on Requirements Engineering for Agent Systems. In the previous module, we honed our skills in controlling and refining agent behavior through system instructions and failure analysis. That entire process, however, relies on a critical assumption: that we have a clear, agreed-upon definition of what "correct" behavior looks like. Without a North Star, our refinements are just shots in the dark.

This lesson is about defining that North Star. Our learning outcome is to write a product requirements document (PRD) for an agentic workflow that defines goals, constraints, inputs, and outputs. A PRD serves as the foundational "source of truth" that translates a business problem into a concrete engineering blueprint. It's the essential first step in moving from a vague idea to a buildable, valuable agentic system, and it forms the bedrock of a professional practice known as "spec-driven development."

Given your background, you are likely familiar with traditional PRDs and Software Requirements Specifications (SRSs). We will build on that foundation, focusing on the specific nuances and considerations required when designing systems powered by non-deterministic LLMs.

1. From "Vibe Coding" to Spec-Driven Development

In the early days of any new technology, there's a tendency toward exploratory, almost improvisational building—what some call "vibe coding." While useful for rapid prototyping, this approach is insufficient for creating reliable, scalable, and valuable client solutions. The professional standard in agentic AI is shifting toward spec-driven development, a methodical process that begins with a clear specification.

As the video highlights, the core problem that spec-driven development solves is a lack of alignment. For agentic systems, this is even more critical than in traditional software. An LLM's non-determinism and its capacity to "hallucinate" or drift from instructions mean that any ambiguity in the requirements will be amplified, leading to unreliable and unpredictable outcomes. A well-crafted PRD is our primary tool for minimizing this ambiguity.

2. The Anatomy of an Agentic Workflow PRD

A PRD for an agentic workflow serves a dual purpose, blending the strategic focus of a traditional PRD with the technical precision of an SRS.

• PRD Mindset ("The Why"): It must define the user needs, business goals, and success metrics. This ensures the agent is solving the right problem and delivering measurable value.
• SRS Mindset ("The What"): It must specify the functional requirements, data inputs, expected outputs, and operational constraints with enough detail for an engineering team (or even another agent) to build from.

The image below provides a great high-level template for a comprehensive AI PRD, blending business strategy with AI-specific considerations.

For our purposes as system architects, we will focus on the core technical components outlined in our learning outcome: Goals, Constraints, Inputs, and Outputs. Let's explore these using a practical case study.

3. Deconstructing the PRD: An E-commerce Case Study

We'll use an e-commerce customer support bot as a running example to make these components concrete.

A. Defining Goals

A goal is not a feature; it is a measurable outcome. For an agentic workflow, goals must be quantifiable to prove the system is working and delivering value.

Your PRD's "Goals" section should contain statements like:

• Automation Rate: Automate >70% of inbound customer queries related to returns, exchanges, and order status.
• Customer Satisfaction: Maintain a CSAT score of >4.5/5 for all interactions handled by the agent.
• Performance: Achieve a median (p50) response time of <1 second and a 95th percentile (p95) response time of <2.5 seconds.

B. Defining Constraints

Constraints are the "rules of the road." They define the boundaries within which the agent must operate. These can be business rules, legal requirements, or ethical guardrails.

Examples of constraints for our PRD include:

• Return Policy: Products can only be returned if purchased within the last 30 days and are in original condition.
• Refund Authority: The agent is authorized to automatically process refunds for items valued under $50. Any refunds $\ge$$50 require human manager approval.
• Scope Limitation: The agent must not attempt to answer questions outside the scope of returns, exchanges, and order status.
• Boundary: The agent must never commit secrets, access production databases directly, or modify CI/CD configurations.

C. Defining Inputs

Inputs are all the information and data sources the workflow needs to perform its task. The PRD should explicitly list these sources.

Your PRD's "Inputs" section should specify:

• User Input: The customer's query (e.g., "Where is my order?").
• Dynamic Context (Databases/APIs):
  • Access to the customer's order history via an internal API.
  • Access to the shipping carrier's tracking API.
• Static Context (Knowledge Base):
  • The company's official return and exchange policy documents.
  • Product information and category details (e.g., which items are non-returnable).

D. Defining Outputs

Outputs are the concrete, observable results of the workflow. This includes not only successful outcomes but also defined failure and escalation paths.

The "Outputs" section of the PRD should detail:

• Successful Resolution: A message to the user with their order status, a confirmation of their return, or a shipping label.
• Structured Action: A call to an internal API to initiate a refund process.
• Human Escalation: A ticket created in a support system (e.g., Zendesk) containing the full conversation history, flagged for immediate human review.

4. The Process: Crafting the PRD Collaboratively

A PRD is not created in a vacuum. The most effective approach is an iterative, conversational process that starts with a high-level goal and progressively adds detail. As we saw in the "Spec-Driven Development" video, you can even use an AI agent to facilitate this process.

This workflow—starting with a high-level objective, using an agent to probe for details and edge cases, and consolidating the answers into a formal document—is a powerful methodology you can use with clients to rapidly move from a problem statement to a buildable specification.

5. A Practical PRD Template for Agentic Workflows

To consolidate these concepts, here is a Markdown template for an agentic workflow PRD. It is synthesized from the best practices in the resources we've reviewed. You can use this as a starting point for your own client engagements.

# PRD: [Name of Agentic Workflow]

**Version:** 1.0
**Date:** YYYY-MM-DD
**Author:** [Your Name/Team]




## 1. Objective & Goals




### 1.1. High-Level Vision
*A concise, one-sentence description of what this workflow does and for whom.*
> **Example:** An automated agent workflow to handle Tier-1 e-commerce customer support queries regarding order status, returns, and exchanges.




### 1.2. Measurable Success Criteria (KPIs)
*Specific, quantifiable metrics that define success.*
- **Goal 1:** [Metric] of [Target]. (e.g., Automate >70% of in-scope queries).
- **Goal 2:** [Metric] of [Target]. (e.g., Maintain CSAT > 4.5/5).
- **Goal 3:** [Metric] of [Target]. (e.g., Achieve p95 latency < 2.5s).




## 2. User Stories & Scope




### 2.1. In-Scope Use Cases
- As a [User], I can [Action] so that [Benefit].
> **Example:** As a customer, I can ask "where is my order?" and receive a real-time status update so that I don't have to wait for a human agent.




### 2.2. Out-of-Scope Use Cases
*Explicitly state what the workflow will NOT do.*
- Handling customer complaints or highly emotional queries.
- Answering questions about product specifications.




## 3. Inputs




### 3.1. User-Provided Inputs
- Primary query format (e.g., natural language text via chat).




### 3.2. Data Sources & APIs
- **Knowledge Base:** [List of documents/sources, e.g., `returns_policy.pdf`].
- **Internal APIs:** [API endpoint and purpose, e.g., `GET /api/orders/{id}`].
- **External APIs:** [API and purpose, e.g., `FedEx Tracking API`].




## 4. Outputs




### 4.1. Successful Outputs
- **User-Facing:** [Description of response, e.g., formatted text with order details].
- **System Actions:** [Description of action, e.g., API call to `POST /api/refunds`].




### 4.2. Escalation & Failure Outputs
- **Trigger:** [Condition for escalation, e.g., 3 failed attempts, negative sentiment detected, or explicit user request].
- **Action:** [Escalation procedure, e.g., Create Zendesk ticket with `High Priority` tag and full conversation transcript].




## 5. Constraints & Boundaries




### 5.1. Business Rules
- [Rule 1]: (e.g., Refunds must be < $50).
- [Rule 2]: (e.g., Returns only valid within 30 days).




### 5.2. Technical & Safety Boundaries
- The workflow **must not** modify any code.
- The workflow **must not** process or store Personally Identifiable Information (PII) outside of designated systems.
- The workflow **must** adhere to the company's brand voice and tone guidelines.




## 6. Non-Functional Requirements

- **Performance:** [Latency, throughput requirements].
- **Reliability:** [Uptime, error rate targets].
- **Cost:** [Target cost per execution/month].
- **Security:** [Authentication, data handling requirements].

Conclusion

In this lesson, we established the critical role of the Product Requirements Document in professional agentic system design. It is the foundational artifact of spec-driven development that aligns business goals with engineering execution, providing the clarity needed to manage the inherent non-determinism of LLMs.

Key Takeaways:

• PRDs are the "Source of Truth": They prevent "vibe coding" and ensure everyone—including the AI—is building toward the same, clearly defined goal.
• Blend the "Why" and the "What": An effective agentic PRD combines the user-centric goals of a traditional PRD with the technical specifics of an SRS.
• Focus on the Core Components: A robust PRD for an agentic workflow must clearly define measurable Goals, operational Constraints, required Inputs, and expected Outputs (including escalations).
• The Process is Collaborative: Use an iterative, conversational approach—potentially assisted by an AI—to move from a high-level vision to a detailed, actionable specification.

Preview of the Next Lesson

We have now defined what the entire agentic workflow needs to accomplish. But a complex workflow is rarely handled by a single, monolithic agent. It's typically composed of a team of specialized agents.

In our next lesson, we will learn how to translate a PRD into an agent specification that defines each agent's role, tools, and boundaries. This is the next level of design detail, where we decompose the high-level workflow requirements into precise job descriptions for the individual agents who will execute the work.