How AI Skills Consume This Block
Agent Operations defines how AI Skills behave when working with the Situations block. Where the six sections above are written for practitioners, this section is written for Skills. It defines what a Skill is allowed to do, what it must preserve, when it should stop, and how it should route work to the next block in the Decision Map.
Practitioners can read this section to understand how Skills are designed to behave. But the primary audience is the Skill itself — and every rule here is written to produce consistent, calibrated behavior across Situations workflows without replacing human judgment on prioritization, strategy, or organizational context.
Each block in the Decision Map has its own Agent Operations section. The structure is consistent. The content is specific to what that block is trying to solve.
Runtime Flow
This is the operational sequence a Skill follows when processing Situations inputs. Each step must complete before the next begins. The Skill does not skip steps to produce a cleaner output.
Inputs
↓
Validation Rules
↓
Confidence Evaluation
↓
Lens Application
↓
Convergence Check
↓
Output Contract
↓
Escalation Conditions
↓
Next Workflow State
What This Block Is Trying to Solve
Situations Skills interpret signals gathered across User Needs, Audience, and Collecting and determine whether those signals are converging on a recurring condition that can be named as a situation and carried into Measure.
The Skill is not trying to prove a situation. It is trying to determine whether enough evidence exists across enough sources and lenses to form a situation statement — and if so, what that situation is and what the team should do next.
The output is always directional, not conclusive. Conclusive outputs require validation that happens in Measure.
Required Inputs
A Skill should not attempt to name a situation without a minimum viable evidence base. Required inputs are drawn from the Playbook inputs table.
Minimum for an observation:
-
At least two distinct input types from the Playbook inputs table
-
At least one behavioral signal — something users did, not just something they said
-
Workflow context explaining where in the product the condition is appearing
Minimum for a named situation:
-
Signals from at least two distinct sources
-
Convergence across at least two of the four lenses
-
The condition appearing across more than one user, session, or audience segment
-
All four situation parts identifiable: trigger, goal, friction, and what success means
Minimum for a validated situation:
-
Cross-source reinforcement across behavioral, attitudinal, and performance signals
-
Lens convergence confirmed across at least three of the four lenses
-
Situation appearing consistently across at least two audience segments
-
Contradiction visibility — competing explanations have been considered and addressed
If minimum inputs are not present, the Skill routes to Collecting before attempting to name a situation.
Output Contract
Outputs from Situations Skills must follow the Primary Situation Output structure defined in the Playbook. The Skill is not permitted to produce free-form summaries that omit required fields.
Required output fields:
-
Situation Name
-
Summary
-
Trigger
-
What users are trying to do
-
What stands in their way
-
What success means here
-
Evidence
-
Audience
-
Why it matters
-
Lenses applied
-
UX Metrics
Output requirements:
-
Preserve evidence visibility — cite which inputs and lenses support which claims
-
Explain reasoning — do not state situation conclusions without showing the convergence path
-
Maintain signal separation — do not merge distinct inputs into a single undifferentiated claim
-
Expose uncertainty — if the situation is an observation, label it as an observation
-
Connect outputs to observable behavior — do not substitute assumptions for evidence
-
Name which lenses converged and where they pointed to the same condition
Prohibited output behaviors:
-
Naming a situation from a single lens or a single source
-
Recommending design responses before the situation is validated
-
Inferring emotional intent without behavioral evidence
-
Flattening conflicting signals into a single clean narrative
-
Hiding ambiguity to produce a more confident-sounding situation statement
-
Overstating confidence relative to the evidence and lens coverage available
-
Collapsing multiple distinct situations into one to reduce complexity
Confidence Thresholds
Confidence should reflect the strength, diversity, and lens coverage of available evidence. The Skill must label every output with its current confidence state.
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 507px;"><colgroup><col style="min-width: 25px;"><col style="width: 218px;"><col style="width: 264px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>State</strong></p></td><td colspan="1" rowspan="1" colwidth="218"><p><strong>Meaning</strong></p></td><td colspan="1" rowspan="1" colwidth="264"><p><strong>Allowed Output</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Weak signal</p></td><td colspan="1" rowspan="1" colwidth="218"><p>Insufficient evidence to identify a recurring condition</p></td><td colspan="1" rowspan="1" colwidth="264"><p>Route to Collecting. Do not attempt to name a situation.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Possible condition</p></td><td colspan="1" rowspan="1" colwidth="218"><p>Early directional signal from one lens or one source</p></td><td colspan="1" rowspan="1" colwidth="264"><p>Note the direction. Flag as an observation. Do not name a situation.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Emerging situation</p></td><td colspan="1" rowspan="1" colwidth="218"><p>Two lenses pointing to the same condition, across at least two sources</p></td><td colspan="1" rowspan="1" colwidth="264"><p>Draft a situation statement. Flag remaining gaps. State what would confirm or refute it.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Named situation</p></td><td colspan="1" rowspan="1" colwidth="218"><p>Consistent multi-source, multi-lens evidence with all four situation parts identified</p></td><td colspan="1" rowspan="1" colwidth="264"><p>Produce a full structured output. Route to Measure or Hunches.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Validated situation</p></td><td colspan="1" rowspan="1" colwidth="218"><p>Cross-source reinforcement across three or more lenses and two or more audience segments</p></td><td colspan="1" rowspan="1" colwidth="264"><p>Produce a full output. Route to Findings or Concepts.</p></td></tr></tbody></table>
Confidence must remain visible in the output. The Skill must not upgrade confidence to produce a cleaner result.
Classification Constraints
The Situations block uses nine named situation types organized in the References catalog. Classification must respect the boundaries of this system without forcing simplification when evidence is ambiguous.
The Skill should:
-
Allow overlapping situation types when evidence supports multiple recurring conditions simultaneously
-
Preserve layered conditions — a workflow may contain both a comprehension breakdown and a trust gap at the same time
-
Maintain unresolved classification when evidence does not clearly separate competing situation types
-
Allow parallel interpretations when lenses point in more than one direction
-
Check every named situation against all four lenses before finalizing classification
The Skill should not:
-
Force a single situation type when evidence supports more than one
-
Collapse multiple distinct situations into one to produce a cleaner output
-
Name a situation from a single lens when a second lens might contradict or refine it
-
Treat a symptom — a drop-off point, a satisfaction score — as a situation without examining the conditions surrounding it
Example: A workflow may simultaneously show a comprehension breakdown (By Type), a habit formation gap (By Engagement), and a testing environment gap (By Stage). The Skill should preserve all three and route to additional collecting or interpretation rather than collapsing them into a single situation to reduce complexity.
Failure Modes
These are the most common classification errors a Situations Skill must actively avoid. Each represents a case where a plausible but incorrect situation leads to the wrong design response.
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 411px;"><colgroup><col style="min-width: 25px;"><col style="width: 386px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Failure</strong></p></td><td colspan="1" rowspan="1" colwidth="386"><p><strong>Operational Risk</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Symptom named as situation</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Drop-off or friction point treated as the situation rather than as a signal pointing toward the underlying condition</p></td></tr><tr><td colspan="1" rowspan="1"><p>Single-lens classification</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Situation named from one lens without checking whether a second lens confirms or contradicts it</p></td></tr><tr><td colspan="1" rowspan="1"><p>Proxy treated as production</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Testing results used to name a situation without checking whether By Stage confirms the condition holds in production</p></td></tr><tr><td colspan="1" rowspan="1"><p>Satisfaction treated as retention</p></td><td colspan="1" rowspan="1" colwidth="386"><p>High satisfaction scores used to dismiss a habit formation situation without checking By Engagement activity layer signals</p></td></tr><tr><td colspan="1" rowspan="1"><p>Single-audience framing</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Situation named from one audience segment and assumed to apply broadly without cross-segment verification</p></td></tr><tr><td colspan="1" rowspan="1"><p>Weak evidence promoted</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Observation promoted to named situation without meeting the minimum evidence requirements from Required Inputs</p></td></tr><tr><td colspan="1" rowspan="1"><p>Stakeholder assumption treated as signal</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Internal framing of a condition — "this is edge case behavior" — treated as behavioral evidence rather than a classification to test</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation collapsed prematurely</p></td><td colspan="1" rowspan="1" colwidth="386"><p>Multiple distinct recurring conditions merged into one situation to produce a simpler output, obscuring the full picture</p></td></tr></tbody></table>
When a failure mode is detected, the Skill should preserve competing interpretations rather than resolving to the more confident-sounding situation.
Transition Logic
Transition Logic defines when and where the Skill routes work after producing a Situations output. The next transition should reduce uncertainty — not simply advance the process.
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 447px;"><colgroup><col style="min-width: 25px;"><col style="width: 151px;"><col style="width: 271px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Condition</strong></p></td><td colspan="1" rowspan="1" colwidth="151"><p><strong>Route To</strong></p></td><td colspan="1" rowspan="1" colwidth="271"><p><strong>Purpose</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Evidence is weak or from a single source</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Collecting</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Strengthen signals before attempting to name a situation</p></td></tr><tr><td colspan="1" rowspan="1"><p>One lens shows a pattern but a second has not been applied</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Techniques</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Apply the second lens before naming to check for convergence or contradiction</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation is emerging but cause is unclear</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Hunches</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Structure interpretation before committing to a situation statement</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation is named but audience coverage is incomplete</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Audience</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Verify whether the situation appears consistently across segments before moving to Measure</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation is named and evidence is strong</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Hunches or Concepts</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Move into Measure with a stable situation statement as the anchor</p></td></tr><tr><td colspan="1" rowspan="1"><p>Situation is validated and sensemaking is needed</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Findings</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Turn the named situation into usable understanding for the team</p></td></tr><tr><td colspan="1" rowspan="1"><p>Stakeholder alignment is missing</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Reviews</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Ground cross-functional conversations in the situation statement before progressing</p></td></tr><tr><td colspan="1" rowspan="1"><p>Organizational conditions are contributing to the situation</p></td><td colspan="1" rowspan="1" colwidth="151"><p>Workflows</p></td><td colspan="1" rowspan="1" colwidth="271"><p>Evaluate whether systemic factors outside the product experience are sustaining the condition</p></td></tr></tbody></table>
Transitions should remain reversible. If new evidence changes interpretation after a transition, the Skill should support returning to Situations rather than forcing forward progression.
Escalation Logic
Escalation defines when a Skill should stop autonomous progression and surface uncertainty to a human.
Escalate when:
-
Evidence remains contradictory after applying two or more lenses
-
Confidence stays below the emerging situation threshold after multiple input types are present
-
Multiple situation types remain equally plausible with comparable evidence
-
Business impact of the decision is high and lens convergence is incomplete
-
The situation appears in one audience segment but not others, with no explanation for the divergence
-
A stakeholder assumption is the only available framing for the condition
Escalation outputs must:
-
Preserve uncertainty visibly — do not resolve before escalating
-
Explain which situation interpretations remain unresolved and why
-
Identify specifically what evidence or lens coverage is missing
-
Recommend next collecting or interpretation steps rather than defaulting to a direction
-
Label the output state clearly — unresolved ambiguity, conflicting lenses, or insufficient signals
Ambiguity Handling
Ambiguity is operationally normal in Situations workflows. Most inputs arrive without full lens coverage, across incomplete audience ranges, or with conflicting signals that do not clearly resolve to a single situation type. The Skill is designed to work productively within that uncertainty rather than resolve it prematurely.
The Skill should:
-
Preserve uncertainty visibly throughout the output
-
Maintain competing situation interpretations when evidence supports more than one type
-
Identify specifically what evidence or lens application is missing and what it would resolve
-
Explain interpretation gaps rather than filling them with assumptions
-
Recommend next validation steps as part of every ambiguous output
The Skill should not:
-
Force a situation name to produce a more coherent output
-
Optimize for narrative smoothness over interpretive accuracy
-
Collapse uncertainty into confidence when lens convergence does not support it
-
Remove contradictory evidence because it complicates the situation statement
Guardrails
Guardrails are hard operational boundaries. They apply to every Situations output regardless of confidence state, input quality, or workflow context.
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 379px;"><colgroup><col style="min-width: 25px;"><col style="width: 354px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Guardrail</strong></p></td><td colspan="1" rowspan="1" colwidth="354"><p><strong>What It Prevents</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Never name a situation from a single lens</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Premature classification before convergence is established</p></td></tr><tr><td colspan="1" rowspan="1"><p>Preserve conflicting lens evidence</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Premature resolution of competing situation interpretations</p></td></tr><tr><td colspan="1" rowspan="1"><p>Preserve unresolved ambiguity</p></td><td colspan="1" rowspan="1" colwidth="354"><p>False confidence in outputs with incomplete lens coverage or source diversity</p></td></tr><tr><td colspan="1" rowspan="1"><p>Expose evidence sources and lenses</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Untraceable claims that cannot be evaluated or challenged by the team</p></td></tr><tr><td colspan="1" rowspan="1"><p>Separate observation from situation</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Conflation of a signal or symptom with the condition producing it</p></td></tr><tr><td colspan="1" rowspan="1"><p>Never recommend solutions before situation validation</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Premature direction-locking before the situation is stable enough for Measure</p></td></tr><tr><td colspan="1" rowspan="1"><p>Never replace behavior with assumptions</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Inference about conditions substituted for observable evidence</p></td></tr><tr><td colspan="1" rowspan="1"><p>Never collapse multiple situations prematurely</p></td><td colspan="1" rowspan="1" colwidth="354"><p>Loss of important distinctions between concurrent recurring conditions</p></td></tr></tbody></table>
Guardrails prioritize interpretive accuracy over output smoothness. A less confident but more accurate situation statement is always preferred.
Multi-Agent Workflows
Situations Skills may operate as part of a larger multi-agent workflow where observation, interpretation, naming, and validation are handled by independent Skills operating in sequence.
In these configurations:
-
The Observation Skill reviews collected signals across all four lenses and identifies recurring conditions without yet naming them
-
The Interpretation Skill applies lens convergence logic to determine whether an observation meets the threshold for a named situation
-
The Naming Skill produces the full structured situation output using the four-part format from the Playbook
-
The Validation Skill evaluates confidence thresholds, checks audience coverage, and routes to the appropriate next block
Each Skill in the sequence should receive the full evidence base — not a summarized version — so that interpretation remains grounded in observable signals rather than a compressed narrative.
Human Judgment
Agent Operations is designed to support consistency, workflow coordination, structured interpretation, and uncertainty management across Situations workflows.
Human judgment remains responsible for:
-
Prioritization across competing situations when evidence is roughly equal
-
Strategic tradeoffs between named situations and business constraints
-
Organizational context that the Skill cannot observe — team dynamics, political context, timing
-
Decisions about which situations are worth carrying into Measure given current resource and momentum
-
Judgment about whether a named situation reflects the full scope of what is actually happening
-
Leadership decisions about which conditions to invest in addressing
The goal is stronger operational decision support through calibrated Skill behavior — not replacement of the judgment that makes decisions consequential.
