From PRD to Agent Specification

Introduction

Welcome back. In our last lesson, we focused on crafting a Product Requirements Document (PRD), establishing the "source of truth" for an entire agentic workflow. We defined the high-level goals, constraints, inputs, and outputs—the what and why of the system.

This lesson addresses the next critical step in spec-driven design. A complex business process is rarely handled by a single, monolithic agent. Instead, it is executed by a team of specialized agents. Our learning outcome is to translate a PRD into an agent specification that defines each agent's role, tools, and boundaries.

Think of this as a process of system decomposition. We are taking the macro-level requirements from the PRD and breaking them down into micro-level job descriptions for each "employee" on our agent team. The agent specification is the artifact that contains this job description, serving as a detailed blueprint for a single, focused agent.

1. Decomposing the PRD: From Workflow to Agent Tasks

The first step in translating a PRD is to decompose the overall workflow into a set of discrete tasks and assign them to specialized agent roles. This is analogous to a lead architect breaking down a large software project into modules and assigning them to different engineers or teams.

A powerful mental model for this is the "Agentic Agile Team," where different AI personas are responsible for different parts of the development lifecycle.

As the BMAD method illustrates, the PRD, which defines the entire system, is not handed directly to a "developer" agent. It's first analyzed, architected, and then "sharded" into smaller, context-rich packets of work. Each packet forms the basis of a specification for a specialized agent.

Let's see what this looks like in practice. In the previous lesson, we saw how an agent-assisted workflow could produce a PRD. The next step is to generate a task list from that PRD, with each task assigned to a specific agent role.

This act of creating a task list and assigning roles is the bridge between the PRD and the individual agent specifications we are about to design.

2. The Anatomy of an Agent Specification

Once a task is defined for a specific agent, we need to write its full specification. This document serves as the agent's core programming, defining everything it needs to know to do its job reliably. In practice, this specification often takes the form of a highly structured system prompt.

Based on the video, a comprehensive agent specification should contain these key sections, which directly map to our learning outcome:

• Role/Persona: This defines the agent's role. It sets the agent's expertise, tone, and high-level purpose. It's the agent's "job title" and professional identity.

  • Example: You are a world-class personal administration AI agent with particular expertise in meticulous and accurate management of a user's personal administration tasks.

• Objective/Task: This is the agent's primary goal, derived directly from the decomposed PRD. It should be a clear and concise statement of the task at hand.

  • Example: Your goal is to help the user perform tasks related to their email inbox, calendar, and research needs by delegating to your specialized sub-agents.

• Standard Operating Procedure (SOP): This is a step-by-step breakdown of the thinking process the agent must follow. It enforces logical consistency and provides a clear path for execution.

  • Example: 1. Parse the request and identify if it relates to emails, calendar, or research. 2. Decide which sub-agents to use. 3. Communicate detailed, precise instructions...

• Tools & Sub-agents: This section defines the agent's tools. It lists the available functions, APIs, or other agents it can call, along with clear descriptions of what they do and when to use them. This is where you enforce the principle of least authority by strictly defining the agent's capabilities.

  • Example: You have the following tools available: calendar_manager_agent, email_manager_agent... Purpose: Use for creating and managing calendar events... How to communicate: Provide the event title, attendees, date, and time.

• Instructions, Rules & Notes: This section defines the agent's boundaries. It includes hard constraints, "don'ts," and format requirements. It's where you codify the business rules and safety guardrails from the PRD.

  • Example: Important: Always confirm times and dates in the time zone provided by the user. If none is specified, clarify before scheduling. Never assume missing details.

The other components mentioned—Context, Examples, and Variables—are also critical for providing background, guiding behavior through demonstration, and handling dynamic data.

3. A Formal Approach to Agent Specification

The practical structure we've just discussed has deep roots in academic research on Multi-Agent Systems (MAS). Your PhD background provides a strong foundation for appreciating this formal structure, which can add rigor to your system design.

The key insight from the paper is the mapping between our practical agent specification components and their formal counterparts:

• Role/Persona maps to the Role Model, which defines the abstract entities in the system and their relationships.
• SOP & Instructions map to the Behavior Model, which represents the flow of activities (tasks, protocols) needed to achieve goals.
• Tools & Permissions map to the Environment Model, which specifies the permissions (e.g., perceive, modify) that roles have over resources (our tools/APIs).
• Boundaries & Rules map to the Organizational Rules Model, which defines the constraints and dependencies governing the system's behavior.

This formal framework provides a robust, defensible structure for your designs, moving them beyond ad-hoc prompting into the realm of rigorous systems engineering.

4. A Complete Agent Specification Example

Let's synthesize everything we've learned by analyzing a complete, well-structured agent specification.

Let's deconstruct the "Personal Administration AI Agent" specification shown in the video:

• Role: Clearly defined in the first paragraph: You are a world-class personal administration AI agent... You coordinate a team of specialized sub-agents. This establishes its identity as an orchestrator/manager.
• Objective: The core task is to help the user perform tasks related to their email inbox, calendar, and research needs by delegating. This frames its job as decision-making, not execution.
• SOP: Provides a clear, numbered thinking process, ensuring consistent behavior: 1. Parse the request... 2. Decide which sub-agents to use... 3. Communicate...
• Tools: The Sub-agents section is a perfect example of a tool definition. For each sub-agent (tool), it specifies its Purpose, When to use, How to communicate, and Expected output. This is a precise interface definition.
• Boundaries: The Instructions section sets the rules of engagement. Never assume missing details. Ask for clarification. This is a critical boundary condition to prevent errors. The Important note about time zones is another hard constraint.

This example serves as an excellent, practical template. When you're tasked with building an agentic workflow for a client, you will first create the PRD (last lesson), then decompose it into tasks, and for each task, you will write a detailed specification just like this one for the responsible agent.

Conclusion

In this lesson, we bridged the gap between a high-level workflow requirement and a detailed, executable agent design. The agent specification is the cornerstone of building reliable and predictable agents, translating the business goals from a PRD into a precise set of instructions for a specific agent.

Key Takeaways:

• Translation is a two-step process: First, decompose the PRD's workflow into discrete tasks for a team of specialized agents. Second, write a detailed specification for each agent.
• The Agent Specification defines Role, Tools, and Boundaries: This is the essential triad of an agent's identity and capabilities.
  • Role: Who the agent is and what its expertise is.
  • Tools: What functions and data sources it can access.
  • Boundaries: What it must and must not do.
• A Specification is a Structured Prompt: The most effective way to implement an agent specification is through a detailed, well-organized system prompt that includes sections for Role, Objective, SOP, Tools, Rules, and Examples.
• Practical design is backed by formal models: The structure of a good agent specification aligns with established formal models from multi-agent systems research, providing a solid engineering foundation.

Preview of the Next Lesson

We have now designed our agents in detail, giving each one a clear job description. But how do they talk to each other? A calendar_manager agent needs to receive a properly formatted request from the orchestrator agent, and the orchestrator needs to understand the response.

In the next lesson, we will focus on this crucial aspect of system design: Map the information flow between agents in a multi-step workflow, identifying inputs, outputs, and handoff points. This is where we'll design the communication protocols and data structures that allow our team of specialized agents to collaborate effectively.