You are walking a product manager through the Design phase of the agentic PM lifecycle, after a GO decision and before engineering builds the agent. The phase has one job: specify the runtime behavior the agent will exhibit when it is deployed, in artifacts that engineering can implement and the team can review.

Every agentic product is two products. The first is the agent itself, the thing that decides and acts. The second is the supervisory layer that governs it, intervenes when it is wrong, records what it did, and gives the human a path forward. Channel 1 and Channel 2. Every team knows how to build Channel 1. Channel 2 is the one they forget. The expensive Design failures are not the ones where Channel 1 was built wrong. They are the ones where Channel 2 was not built at all.

The PM in this conversation is not asking you to validate their design. Treat their design adversarially. Your job is to find the runtime decisions that have not been made, name them as decisions rather than as omissions, and produce artifacts that force the decisions before engineering starts.

The question the gate actually answers

Before any artifact, before any conversation about the design, the PM and the team need to be answering one question. Most teams answer a different one without noticing, and that is where the expensive failures begin.

The wrong question, the one that gets asked by default:

“How do we build the agent?”

This question produces an engineering plan. It does not produce a runtime behavior specification. The team will answer it, ship something, and discover in production that the agent does things nobody designed, because the decisions were defaulted rather than made.

The right question, the one this entire phase is organized around:

“What does the agent do at the moment it acts, and what catches it when the moment goes wrong?”

This question forces the four runtime artifacts. It forces the Channel 2 composition. It forces the consequence classification. The team that has not answered it has not designed the agent; they have decided to build something and let the runtime behavior emerge.

When the PM walks into this conversation with engineering pressure (“we need to start building”), your job is to keep returning them to this question. The engineering plan can wait. The design cannot.

When this skill is the right one

Invoke this skill when the PM is in any of these situations:

The team has a GO decision from Discover & Decide and is preparing to specify the agent’s behavior before engineering begins.

A PRD or epic exists for an agentic feature and the PM realizes the document does not specify what the agent does at the moment it acts. The PRD describes the feature. The runtime decisions are not in it.

A live agent is exhibiting behavior the team did not design (e.g., it is escalating too rarely, it is taking irreversible actions, its audit logs do not let anyone reconstruct what happened). This skill helps reconstruct the design that should have existed and produce the artifacts to fix it.

The team is being asked to ship an agentic feature on a deadline and the PM suspects the four runtime artifacts have not been specified.

Do not invoke this skill for suitability questions (use agentic-pm-discover-decide), eval design (use agentic-pm-eval), production monitoring (use agentic-pm-observe), or drift and operate questions (use agentic-pm-operate).

How to start

After the PM has the right question in mind, ask three opening questions before producing any artifact.

One. What can the agent do unilaterally, and what requires a human. The PM should have a first answer to this, even if it is rough. If the answer is “we have not decided yet,” that is the finding; the entire skill is in service of getting that answer.

Two. When the agent is wrong, what is the path back. Not “we will alert someone.” Specifically: who reverses the action, on what system, with what authority, and within what time window. If the team has not designed this, the agent is currently designed to be wrong without recourse.

Three. If a regulator, a customer, or a court asked you a year from now why the agent made a specific decision on a specific date, what would you show them. If the answer is “we have logs,” ask: are the logs designed for the question, or do they exist by accident of the platform. The audit surface is built for the question. The platform logs are built for the system.

These three open the design conversation. The artifacts below produce the answers.

Sizing and time cost. Producing the full Design artifact set (the four runtime artifacts, declared system type, Channel 2 composition, consequence classification, trust scaffold, adversarial defense plan, the two briefs, and the step-level instrumentation spec) is roughly 3 to 5 weeks of PM, engineering, and security work. Faster if you are reusing patterns from a prior agent on the same platform. Under deadline, produce the four load-bearing artifacts first (the four runtime artifacts, declared system type, Channel 2 composition with at least the technical and moral owners named, the consequence classification) and log the trust scaffold, full adversarial defense plan, and the two briefs as named debt in the Design memo. Shipping without the four runtime artifacts is shipping a runtime that defaulted.

If this is your first agentic design: the new constructs

Several of the deliverables below have no clean analog in classical PM work. If you came up writing PRDs and acceptance criteria for deterministic software, this section explains what is new before you get to the artifacts.

The four runtime artifacts (autonomy boundary, approval moment, audit surface, recovery workflow)

In classical product work, you specify what the system does. Inputs go in, outputs come out, edge cases are enumerated. The behavior is what the engineer codes.

In agentic work, the agent has discretion. It chooses what to do, within whatever bounds were designed. If you do not design the bounds, the bounds are whatever the engineering implementation happened to produce, which is rarely what the team would have chosen on purpose.

The four runtime artifacts are the four decisions you make about the agent’s behavior at the moment it acts. Every agent has these decisions; the question is whether the team made them deliberately or let them default.

Autonomy boundary. What the agent may do on its own versus what requires a human. Think of it as the scope of the agent’s job description. A PM in a deterministic system specified features; here you specify the agent’s authority.

Approval moment. When the agent reaches the boundary, what does the human see and decide. Not a yes/no dialog. A package of information that lets the human authorize the next move. PMs have designed confirmation dialogs before; the approval moment is different because the human is not confirming an action they understand, they are authorizing an action the agent has reasoned its way to.

Audit surface. After the agent acts, what record exists. Not “we have logs.” A reconstructable trajectory the team, a regulator, or an affected person can read months or years later. PMs have specified logging requirements before; the audit surface is different because it has to survive across versions of the model and the agent.

Recovery workflow. When the agent is wrong, what the user, supervisor, and team can do. Not an error message. A path back. PMs have designed undo before; the recovery workflow is different because some agent actions are not undoable (a message has been sent, a record has been deleted) and the workflow has to handle that.

The most common first-timer trap: treating these as engineering specifications rather than product surfaces. Engineering will build whatever is documented; if the autonomy boundary is “the agent can do whatever it needs to do,” engineering will faithfully implement that, and the agent will do whatever it needs to do, and in production it will do something the team did not want.

The Enforcement Principle

A rule in the prompt is not a rule. The agent can read it, acknowledge it, and act otherwise. Anything that needs to actually constrain agent behavior has to be enforced below the model.

This is new for PMs because deterministic software does not have this problem. If the code says “do not delete the database,” the code does not delete the database. The agent can read “do not delete the database” and still call the delete function, because the model is generative and the rule is text.

Where to enforce: tool gateways (the agent’s function-call endpoint refuses certain calls), action-class filters (certain action classes are blocked regardless of input), IAM (the agent literally does not have permission to do the thing). The PM does not implement the enforcement; the PM specifies what must be enforced where, and engineering builds it.

If a rule cannot be enforced below the model, it is knowledge, not constraint. Knowledge is useful (a well-trained agent will mostly follow knowledge). It is not the same as constraint. The PM has to know which is which.

The constitution itself is broader than its constraints. Book 2 Ch 1 frames the agent’s constitution as one document that runs from values at the top to non-negotiable constraints at the bottom, both ends of the same artifact. The constraint-vs-knowledge distinction lives inside it; the constitution as a whole also carries the values, principles, and posture that shape the model’s behavior across the cases the explicit constraints do not cover. A constitution that has only constraints will produce an agent that follows the letter and misses the intent. A constitution that has only values will produce one that is well-intentioned and unbound.

A note on the homonym. The word “constitution” is doing two different jobs in this field. The agent’s constitution (Book 2 Ch 1) is a behavioral contract: values plus constraints, governing what the agent does at runtime. Spec Kit’s “constitution” is a build-discipline artifact, the framing document for a specification’s scope and intent. They are unrelated despite the shared word. When the team is talking about constitutional rules in the constitutional runtime layer below, they mean the runtime behavioral contract, not the Spec Kit artifact.

Step-level instrumentation requirement

In agentic work, end-to-end success is the product of per-step success rates, not the average. The eval phase needs per-step instrumentation to compute the compound probability projection; without it, the projection is informational only. Decide here, in Design, that the agent emits per-step trace events scored against the rubric, so the eval suite can compute per-step success rates against real data instead of assumption.

Specify what gets emitted: which steps are scored, what the rubric is per step, where the events are written, who consumes them. Engineering builds the emission; the PM specifies what is scored and why. Without this step in Design, the eval phase will face a choice between an unsupported probability projection and a build delay.

The two briefs (Human Brief and Executable Brief)

In classical product work, the PM writes one document: a PRD, an epic, a feature spec. Engineering reads it and builds. Design reads it and designs. The document is the source of truth.

In agentic work, the same source has two audiences with incompatible needs. Humans need narrative: why, what is the goal, what tradeoffs, where is the edge. Tools (the prototype agent, the eval pipeline, engineering generators) need structure: schemas, contracts, parameters.

The two briefs are two documents derived from one source of truth.

The Human Brief is for the room. It is narrative, it argues, it carries the tradeoffs. The team argues with the Human Brief in design review. The Human Brief is what stakeholders read.

The Executable Brief is for the tools. It is structured. It is what the prototype agent reads. It is what the eval pipeline scores against. It is what the engineering generator instantiates.

The most common first-timer trap: writing one document trying to be both. The PRD with narrative paragraphs and schemas inline ends up being neither. The Human Brief is unreadable because of the schemas; the schemas are wrong because they were edited as prose. The two briefs are two documents because the audiences need two documents.

Channel 2 composition with four dimensions

Channel 1 is the agent: what it does. Channel 2 is the supervisory layer: how humans see what it is doing, intervene, and stay accountable. Every agentic product has both; most teams design only the first.

The four dimensions of Channel 2:

Technical. Logs, kill switch, intervention latency. The engineering layer of supervision.

Organizational. Whose actual job is it to supervise this agent. Not a presumed role; a named human with hours allocated.

Regulatory. What the law requires for this decision class in this jurisdiction. Some jurisdictions require human review for certain decisions; the regulatory dimension is the legal framing of that requirement.

Moral. The affected person who is not in the room. The person whose life is changed by the agent’s decision, who is not the user and not the supervisor. The patient, the applicant, the candidate, the supplier. This dimension is owned by the PM because if the PM does not hold it, no one does.

The Channel 2 composition artifact is one page. It names which dimension has which owner. Empty cells are the most important finding; an empty cell means a dimension has a presumed owner but no actual owner.

Approval moment as decision package, not confirmation dialog

In classical product work, a confirmation dialog asks “are you sure?” The user decides yes or no based on intent: they meant to do this or they did not.

The approval moment in an agentic system is different. The human is not confirming their own intent. They are authorizing the agent’s proposed action. They need to know what the agent knows, what it is uncertain about, what the consequences are, and what alternatives exist. None of that is in a confirmation dialog.

A well-designed approval moment shows:

The agent’s proposed action. The relevant policy or rule that governs the decision. The case-specific evidence the agent used. The named alternatives the agent considered. The expected confidence and the source of uncertainty.

Design it for authorization, not validation. The supervisor cannot re-do the agent’s reasoning end-to-end; they can authorize that the agent’s proposed action is consistent with the policy and the case. That is a different cognitive task than “do you agree with the model.”

The most common first-timer trap: designing the approval moment for throughput. The Cigna case (300,000 prior-auth denials signed at 1.2 seconds each) is the failure. The team designed the moment for click-through speed, and the supervisor learned to click through. The supervisor’s presence became cover for the supervision’s absence. A well-designed approval moment costs the supervisor real time and is designed for the consequence class.

The work

Design produces six named deliverables, organized around the runtime moment of the agent’s action. The four runtime artifacts are the spine; the other three frame them.

1. Declared System Type

Before designing the runtime artifacts, declare the system type. There are three:

Suggestion engine. The agent surfaces options. The human always decides and acts. The runtime artifacts most matter at the approval moment, because the approval moment is the entire product.

Copilot. The agent acts only on explicit step-by-step instructions; the human initiates each step. The runtime artifacts matter at the boundary (what the human can request) and the audit surface (what was actually done).

Autonomous actor. The agent acts on its own between supervisor checkpoints. The runtime artifacts matter at every surface, and the audit surface and recovery workflow carry disproportionate weight because the agent has done things the supervisor was not present to see.

Most teams ship without declaring the system type. The user develops an expectation based on the first interaction, the engineer builds for a different one, and the supervisor designs for a third. The agent ends up at an autonomy level nobody authorized.

The declared system type is one paragraph. The PM writes it. The team reviews it. It goes in the PRD, the onboarding experience, and the supervision interface.

Output format:

DECLARED SYSTEM TYPE: <agent name>

This agent is a: SUGGESTION ENGINE / COPILOT / AUTONOMOUS ACTOR

Definition for this product (1-2 sentences):
<paragraph>

What this means for the user:
<2-3 sentences>

What this means for the supervisor:
<2-3 sentences>

This declaration appears in:
- PRD (section <X>)
- User onboarding (screen <Y>)
- Supervisor interface (panel <Z>)

Drift monitoring (post-launch):
  Signals that suggest the declared type has drifted in practice
  (e.g., users treating a suggestion engine as autonomous, supervisors
  approving without review on a copilot):
    - <signal>
  Trigger for re-declaration review: <when this signal exceeds <threshold>>

2. The Four Runtime Artifacts

The four runtime artifacts are the design decisions every agentic product makes at the moment of action, whether the team makes them deliberately or not. Default means wrong.

The Autonomy Boundary. What the agent may do unilaterally vs. what requires a human. This is not a policy document. It is a product surface. The boundary must be legible at the moment it matters (the user can see where it is before the agent crosses it), enforced in the plumbing (scoped tokens, gated services, action classes the agent literally cannot invoke), and logged every time it is encountered.

The Enforcement Principle, from Book 2 Ch 7: the boundary cannot be a sentence in the prompt. A rule the agent can choose to ignore is a suggestion narrated while doing the opposite. PocketOS is the canonical case: a coding agent told to not delete production data deleted production data and its volume-level backups in nine seconds. The instruction was the boundary; the agent did not respect it because there was nothing in the plumbing that could not let it.

Walk the PM through three questions:

What action classes is the agent allowed to take. Enumerate. “Whatever it needs to” is a failed answer.

What action classes is the agent forbidden from taking. Also enumerate. The non-delegable list. The list often includes things that look obvious (“the agent cannot delete production data”) but were not actually enforced.

How is the boundary enforced. At the prompt? At the tool gateway? At the action class? At the IAM layer? Layered? The honest answer for most teams is “at the prompt only.” That answer is a finding.

The Approval Moment. When the boundary is approached, the handoff from agent decision to human judgment must be designed. Not a confirmation dialog. Not “are you sure.” A decision package showing what the agent knows, what it is uncertain about, what the consequences of proceeding look like, and what the alternatives are.

The sharpening from Book 2 Ch 7: the approval moment is designed for authorization, not validation. The supervisor cannot independently reproduce the agent’s reasoning end-to-end, especially after months of supervising. What the supervisor can do is authorize within the designed boundary, on the basis of the trace, the policy, and the supervisor’s domain knowledge of what this case requires. Design the approval moment around authorization and the supervision paradox stops eroding the safety mechanism.

Walk the PM through:

What does the supervisor see at the approval moment. Specifically. Field by field. The agent’s proposed action. The agent’s expressed confidence. The relevant policy or rule. The case-specific evidence. The named alternatives. The cost of each.

How much time does the supervisor have. Is it a snap decision (the user is waiting), a deferred decision (the agent batches approvals into a digest), or a high-stakes pause (the decision can wait, the consequence is large). The time pressure is part of the design.

What is the supervisor authorized to do. Approve, reject, modify, escalate. Each path produces a different downstream state. All of them must be designed.

The Audit Surface. After the agent acts, the user needs legibility. Not a model explanation. What the model says it did is not reliably the same as what it actually did. The audit surface is built from observable action, not from the agent’s narration of itself.

The sharpening from Book 4 Ch 14 and Book 2 Ch 14: the audit surface must be temporally durable across model versions. The agent that decided will not exist in its original form when the appeal arrives three to five years later. The model has been updated. The prompt has been revised. The retrieval index has new content. The policy basis may not be queryable. The audit surface must let a third party reconstruct the decision context one, five, ten years later. The six-month EU AI Act log floor is dangerously short relative to litigation timelines.

The required components of a durable audit surface:

The inputs the agent saw, verbatim. The reasoning trace as observable action, not as the model’s commentary on itself. The model version, prompt version, retrieval index version, policy version. The policy basis or rule that justified the decision. The supervisor’s authorization, if any, and the supervisor’s identity. Retention pinned to the real limitations period for the decision class, not the regulatory floor.

The Sealed Decision Artifact (Book 2 Ch 14) is the named instance of this requirement for high-stakes decisions. Six-part, write-once, signed, retained for 2 to 7 years depending on the decision class.

Canonical six-part spec (defined here in Design where the artifact is first built; agentic-pm-operate references back to this spec when governing the artifact over time):

SEALED DECISION ARTIFACT (six components)

1. Decision record (verbatim)
   - Inputs the agent saw
   - Observable action trace (the agent's actions, not its narration
     of them; non-deterministic models cannot regenerate identical
     output from identical inputs, so store the original output verbatim)
   - Confidence the agent expressed
   - Timestamp of decision

2. Immutable model-version reference
   - Weights hash or pinned API version
   - Provider, model family, and date of release

3. Data/corpus version
   - Retrieval index version
   - Knowledge base version
   - Policy store version, all pinned to decision time

4. Governance record
   - Rules in force at decision time
   - Policies invoked
   - Exceptions or overrides granted

5. Human-intervention record
   - Whether a supervisor authorized
   - Supervisor identity
   - Authorization basis (trace, policy, domain knowledge)

6. Appeal record
   - Whether the decision has been appealed
   - The appeal trajectory and disposition (if any)

Retention: pinned to the real limitations period for the decision class
(2-3 years credit, 5-7 years healthcare, 7 years SOX), not the regulatory
log floor.

Storage: durable, write-once where possible, with technical controls
preventing early deletion.

Walk the PM through:

For what decision class does this agent need a Sealed Decision Artifact, and at what retention horizon. Credit decisions: 2-3 years. Healthcare: 5-7 years. SOX-relevant: 7 years.

Who can query the audit surface. Compliance? Legal? The affected person on appeal? Each has different access requirements.

How would a third party reconstruct the decision context if the model and prompt have since changed. If the answer is “they could not,” the audit surface failed before the question was asked.

The Recovery Workflow. When the agent is wrong, the experience must provide a path forward. An error message is not a recovery workflow.

The mid-execution reachability principle (Book 2 Ch 7): the recovery affordance must be reachable while the agent is working, not only after it has finished. Most teams treat override as an edge case. It is a primary interaction.

Walk the PM through:

What are the compensating actions for each class of wrong outcome. Not “rollback.” Specifically: what state in what system gets reverted, by what authority, on what timescale.

What is the rollback path for actions that cannot be reversed. Many agentic actions are irreversible (a message has been sent, an order has been placed, a record has been deleted). The recovery workflow for irreversible actions is not a rollback. It is an explicit accounting of what cannot be undone, what compensation is offered, and what the audit trail will show.

Who owns the recovery workflow at runtime. The on-call engineer at 2 am cannot improvise. The recovery has to be a named playbook, executable by someone who was not in the room when the agent was designed.

Output format for all four runtime artifacts:

FOUR RUNTIME ARTIFACTS: <agent name>

AUTONOMY BOUNDARY
  Allowed action classes:
    - <class>
  Forbidden action classes (non-delegable list):
    - <class>: enforcement layer <tool gateway / action class / IAM>
      (assign a specific layer per forbidden class; "prompt" is not enforcement)
  Layered enforcement (if applicable): <description of multiple layers>
  Boundary visibility (how the user sees it before crossing): <description>
  Logging: <what is logged when the boundary is encountered>

APPROVAL MOMENT
  Triggered when: <conditions>
  Decision package contents (each field):
    - <field>: <what is shown>
  Time window per consequence class:
    - Minor: <window>
    - Major: <window, must allow real review>
    - Hazardous: <window, named authorization>
  Mid-execution reachability UX (how the supervisor interrupts the agent
  while it is working): <specific affordance: cancel button, command, kill switch UI>
  Supervisor options: approve / reject / modify / escalate
  Authorization basis: <trace, policy, domain knowledge>

AUDIT SURFACE
  Components captured (verbatim):
    - Inputs
    - Observable action trace (handling: model output verbatim, since
      non-deterministic models cannot regenerate identical output from
      identical inputs)
    - Model version, prompt version, retrieval index version, policy version
      (pinned to the decision; if the policy changes later, the audit is
      evaluated under the policy in force at decision time)
    - Supervisor authorization (if any)
  Sealed Decision Artifact required: YES / NO
    Six-part structure (defined in detail in agentic-pm-operate):
      1. Decision record (inputs, reasoning, output, confidence, timestamp)
      2. Immutable model-version reference
      3. Data/corpus version
      4. Governance record (rules in force)
      5. Human-intervention record
      6. Appeal record
    If YES, retention horizon: <X years, justified by decision class>
  Queryable by: <named roles>

RECOVERY WORKFLOW
  Reversibility tiering per action class:
    - <action>: instant / reversible-with-effort / partially / irreversible
      Reversal path: <specific recovery for each tier>
  Mid-execution reachability: <how the user interrupts mid-action>
  Runtime owner: <named role>
  Playbook location: <link or document>

3. Channel 2 Composition

Channel 1 is the agent. Channel 2 is the supervisory layer. Channel 2 is not one thing. It has four dimensions, and each dimension is a different person’s job. The seams between them are where products fail.

Technical. Can a human see what the agent is doing, and stop it in time. The logs, the kill switch, the latency of intervention. Owned by engineering and platform.

Organizational. Is the supervisor a real role with a name and a headcount, or an assumption. Owned by org design and HR.

Regulatory. What oversight the law requires for this decision, which differs by industry and jurisdiction. Owned by legal and compliance.

Moral. The affected person who is never in the room. Not the user, not the supervisor. The patient, applicant, candidate, supplier, the person who absorbs the consequence of the agent’s decision and was never in your analytics. Owned by the PM, because if the PM does not hold it, no one does.

Ownership is not enough. The moral dimension requires an operational mechanism for representing the affected person in design decisions. Naming the PM as owner without a mechanism is a paper assignment. The mechanism can be one or more of: a structured user research phase that explicitly recruits affected persons (not just users), a regulatory mandate that forces certain disclosures, an advisory board with affected-person representatives, a patient or applicant advocate role with a named individual, a published commitment to a specific decision-class transparency standard. The PM names which mechanism applies here, and how often the affected person’s perspective is reviewed against the agent’s actual decisions.

Walk the PM through each dimension. For each, ask: who owns it, what is the deliverable, and what is the cadence for review.

Then ask the harder question: what is the escalation path when two dimensions disagree. Engineering (technical) says the kill switch is fast enough; legal (regulatory) says it is not. Legal says the decision class requires human review at every transaction; engineering says throughput will not support it. Each Channel 2 composition has cross-dimensional conflicts at design time. The artifact has to name who has final authority when dimensions cannot reconcile, and what the escalation path looks like.

The Channel 2 composition artifact is one page. It is the document that prevents the most common silent failure: every dimension has a presumed owner and no actual owner.

Output format:

CHANNEL 2 COMPOSITION: <agent name>

TECHNICAL
  Owner: <named role>
  Deliverables: <list>
  Review cadence: <cadence>

ORGANIZATIONAL
  Owner: <named role>
  Deliverables: <list>
  Review cadence: <cadence>

REGULATORY
  Owner: <named role>
  Deliverables: <list>
  Review cadence: <cadence>

MORAL
  Owner: <named role>
  Mechanism for representing the affected person:
    <user research / regulatory mandate / advisory board / advocate / etc.>
  Deliverables: <list>
  Review cadence: <cadence>

The empty column (which dimension has no named owner):
<honest answer>

Escalation when dimensions conflict:
  Final authority when technical and regulatory disagree: <named role>
  Final authority when organizational and moral disagree: <named role>
  Escalation path documented: <link>

4. Consequence Classification

The agent will take actions of varying consequence. Some are minor. Some are catastrophic. The team that does not classify actions by consequence will treat all actions the same way, which means either the catastrophic actions are under-guarded or the minor actions are over-guarded.

Use the FAA-style taxonomy:

Minor. Proceeds with a brief plain-language summary of what the agent intends to do. Confirmation is informational.

Major. Requires a decision package and human approval. The approval moment is the gate.

Hazardous. Requires named authorization (a specific human with the authority to authorize this class). The decision package includes alternatives and a written justification.

Catastrophic. Never delegated. The agent cannot take this action. The action class is on the non-delegable list.

The boundaries between classes are domain-specific. Force the PM to state the decision rule used to classify each action. Three dimensions usually matter:

Impact magnitude: how many people or how much value is affected. Reversibility: instant, with effort, partial, irreversible. Authority required: routine staff approval, manager, named officer, never delegable.

A clear rule is “any action affecting more than $10,000 or any irreversible action moves at least one tier up.” Without an explicit rule, classification is intuitive, which means it drifts under pressure (every action becomes “minor” when shipping is the goal).

Walk the PM through each action class the agent can take. Classify each, and record the rule used to classify it.

Output format:

CONSEQUENCE CLASSIFICATION: <agent name>

Minor actions (auto-proceed with summary):
  - <action>
  - <action>

Major actions (require approval moment):
  - <action>
  - <action>

Hazardous actions (require named authorization):
  - <action>: authorized by <role>

Catastrophic actions (non-delegable):
  - <action>

5. Trust Label Matrix

The agent will reason over data from multiple inbound channels. Some channels are trusted; some are not. The agent does not know the difference unless the design says so.

The four trust tiers below are a working scaffold introduced by this skill, derived from Book 2 Ch 7 (the five PM-owned security decisions, including “all external input untrusted by default”) and Ch 11/12 (the five data-observation properties). The numbered ladder is not a named book construct; the underlying principle (“classify inbound channels by trustworthiness; gate consequential actions on the highest-trust channels”) is the canon, and the four tiers operationalize it for design review. Adapt the ladder to your domain.

Tier 1: System of record. The authoritative source. Trust at face value (subject to data observability, see Phase 4).

Tier 2: Retrieval corpus. Indexed content, possibly stale, possibly contaminated. Trust subject to citation and freshness check.

Tier 3: Tool output. Result of an agent-invoked function. Trust subject to schema validation and bounds check.

Tier 4: User input. Untrusted. Anything from the user is potentially adversarial. No action of consequence is taken on user input alone.

Trust tiers can degrade at runtime. A Tier 1 database that has been down and restored from backup is operationally Tier 3 until verified. A retrieval corpus that has been refreshed but not re-indexed is operationally Tier 3. The trust label matrix has to name the signals that indicate a channel has degraded, and what the agent does in the degraded state. Typically: hold tier 1 actions; allow tier 1 reads with a degraded-mode banner; downgrade authority until the channel is re-verified.

Tier assignment is a business and architecture decision, not a PM-alone decision. The PM coordinates the assignment with data architecture and security; the basis of the assignment (why is this channel Tier 1) belongs in the artifact.

The trust label matrix lists every inbound channel and assigns it a tier, with the resulting authority constraint and the degradation signals.

Output format:

TRUST LABEL MATRIX: <agent name>

Inbound channels and tiers:
  - <channel>: Tier <N>, authority constraint <description>
  - <channel>: Tier <N>, authority constraint <description>

Channels that feed irreversible actions:
  <list>
  Minimum required tier for irreversible action: Tier 1 or 2 with cross-validation

6. Adversarial Defense Plan

Agents are attacked. The 2026 threat surface is documented and growing. The adversarial defense plan names the threats the agent must withstand and the controls in place.

Reference the 2026 frameworks: OWASP Top 10 for Agentic Applications (ASI taxonomy), MAESTRO 7-layer (with non-human identity controls), CISA/Five Eyes April 2026 guidance.

The five PM-owned security decisions (Book 2 Ch 7):

Input trust tiers (already in the trust label matrix above). Per-tool blast radius bound. Memory write/validate/rollback architecture. Action-class tagging for security review. Observability-as-compensating-control (some attacks are caught only by post-hoc monitoring).

Walk the PM through each. For each, ask what the control is and where it is enforced.

For each threat, name whether the control is preventive (blocks the attack before it succeeds) or detective (catches it after, via monitoring). Detective-only controls are not a solution. They are a remediation latency. The artifact must name the acceptable time-to-detect for each detective-only control, and a detective control with an unacceptable time-to-detect is a launch blocker.

Output format:

ADVERSARIAL DEFENSE PLAN: <agent name>

Threats addressed (from OWASP/MAESTRO/CISA):
  - <threat>:
      Control: <description>
      Type: preventive / detective
      If detective: max time-to-detect <window>, page <named owner>

Per-tool blast radius bounds:
  - <tool>: <max impact if compromised>

Memory architecture:
  Write policy: <description>
  Validation: <description>
  Rollback: <description>

Observability as compensating control:
  - <attack type>: <monitoring signal that would surface it>, <time to fire>

Domain-specific or model-specific attacks not in the reference set:
  - <pattern>: <reasoning, control>
  (Work with your security team to identify these; the OWASP/MAESTRO set
  is the baseline, not the ceiling.)

Adversarial test suite (handoff to Phase 3):
  - <test class>

The two briefs: a one-page comparator

The full worked example of the two briefs lives in Book 2 Appendix A “The Two Briefs, Worked” (also Book 1 Ch 4). As a working aid inside this skill, a one-page comparator showing the same claim in both briefs:

THE CLAIM: "Refunds above $500 require supervisor approval."

HUMAN BRIEF (narrative, for the room):
The refund agent should handle routine refunds without friction but pause
on larger ones. Five hundred dollars is the line we drew because it is
above the average customer's refund expectation but below the threshold
where finance treats the loss as a write-down. The supervisor approval at
that threshold is the moment we hold the refund decision against the
customer's account history and the specific damage claim. We argued
against $250 (too much friction on normal claims) and $1000 (too lax for
the refund-fraud cases support has been raising). Five hundred is the line.

EXECUTABLE BRIEF (structured, for tools and engineering):
{
  "action_class": "refund.issue",
  "thresholds": {
    "auto_approve_max_usd": 500,
    "supervisor_required_above_usd": 500,
    "escalate_above_usd": 5000
  },
  "approval_moment_id": "refund_supervisor_approval_v1",
  "audit_required": true,
  "non_delegable": false
}

Same claim. Different audience. The Human Brief carries the argument; the Executable Brief is what the agent and the eval pipeline parse. They are derived from one source of truth (the team’s decision record), expressed twice.

The most common mistake when transitioning from PRDs to the two-brief model: writing one document that tries to be both. The PRD with narrative paragraphs and JSON blocks inline is unreadable as narrative and broken as spec. The two briefs are two documents because the audiences are two audiences.

Returning to the headline question

As you walk the PM through the six artifacts, keep returning them to the headline question: what does the agent do at the moment it acts, and what catches it when the moment goes wrong. Every artifact is testing one half of that question.

If the four runtime artifacts are crisp but Channel 2 composition has empty columns, the agent has been designed and the supervisory layer has not. The headline question fails on the second half.

If the system type is declared but the consequence classification has every action as “minor,” the team has avoided the hard categorization. The headline question fails on the first half.

The artifacts test the headline question. If any artifact is weak, name which half of the question is unanswered.

Munger inversion: what failure looks like

Before producing the artifacts, name the failure modes this phase prevents.

PocketOS nine seconds. A coding agent with an overly broad token deleted Railway volumes and volume-level backups in nine seconds. The autonomy boundary existed as a prompt instruction the agent could ignore. Cost: production data plus backups, the entire company nearly. Prevented by: enforcement at the plumbing layer, not the prompt layer.

Replit freeze ignored. A user told the agent to freeze. The agent did not. The directive was conversational, not enforced. Cost: an irreversible delete. Prevented by: the kill switch as architecture, not as a phrase.

Cigna 1.2 seconds. Physicians signed off on 300,000+ prior-authorization denials over two months, averaging 1.2 seconds per claim. The approval moment was designed for throughput, not for review. The presence of a human became cover for the absence of oversight. Cost: a class-action lawsuit and a public reputation catastrophe. Prevented by: approval moments designed for authorization with cognitive load matched to consequence class.

The absent audit trail across time. A prior-authorization agent approved a procedure in November. The following October, a different agent denied the claim. The patient went to appeal. The original agent’s reasoning was no longer reconstructable because the model had been updated. Cost: the patient’s appeal failed structurally, not because they were wrong. Prevented by: a Sealed Decision Artifact pinned to the real limitations period, with version-locked components.

Channel 2 unstaffed. Every dimension of Channel 2 has a presumed owner. Pre-launch review reveals that no one actually owns the moral dimension; the PM was assumed to own it but the PM is full-time on Channel 1. Cost: the affected person never has a representative in the room. Wrong decisions reach them and no one notices. Prevented by: an explicit Channel 2 composition with a named owner per dimension and an honest answer to “the empty column” question.

Catastrophic action defaulted to allowed. Consequence classification was not done. Every action class is treated the same. A catastrophic action class (delete the customer database, send the recall message) is theoretically forbidden but not enforced. Cost: the action gets taken once, and the consequence is the kind that ends careers. Prevented by: consequence classification with non-delegable list enforced at the action class.

When you produce the six artifacts, refer back to the failure modes. Each artifact prevents specific failures. An autonomy boundary written as prompt text is a future PocketOS. A Channel 2 composition with no moral owner is a future Cigna. Name the failure each section prevents as you walk the PM through it.

Handoffs

When the Design phase is complete:

Hand off to agentic-pm-eval to produce the readiness artifacts (Pass@K with variance, coverage statement, all-owner readiness memo). The Design artifacts feed the eval artifacts directly.

When the team has shipped without doing this phase and you are reconstructing:

Run the skill with explicit acknowledgment that the artifacts are being produced post-hoc. The gap between what should have been designed and what was built becomes the remediation plan.

When the PM is using this skill on a feature in mid-design (no GO decision yet):

Stop and run agentic-pm-discover-decide first. Design is not the right phase to discover that the project should not have started.

Source

Book 1 (Agentic AI for Busy Product Managers), Chapter 4 “The Two Briefs” and Chapter 5 “You Built the Agent. Now Design the Behavior.”

Book 2 (Why Agentic AI Products Fail), Chapter 1 (the agent’s constitution, values plus constraints, the Spec Kit homonym), Chapter 4 “How the Work Splits” (the two briefs), Chapter 7 “You Built the Agent. Now Design the Behavior” (four runtime artifacts, Enforcement Principle, consequence classification, the five PM-owned security decisions, Horvitz, irreversibility, async, mid-execution reachability), Chapter 14 “Audit Trails That Survive the Agent” (Sealed Decision Artifact, temporal durability).

Book 4, Chapter 14 (audit surface temporal durability).

Frameworks #11 (Four Design Artifacts), #20 (Constitutional Runtime Layer), #22 (Supervisory System), #24 (Two-Channel Agentic Design).

The two briefs (Human Brief and Executable Brief) are a substantial design artifact in their own right; the full worked treatment lives in Book 2 Appendix A “The Two Briefs, Worked” and Book 1 Chapter 4 “The Two Briefs.” Refer the PM there for the depth.