Agent Operations

How AI Skills Consume This Block

Agent Operations defines how AI Skills behave when working with the User Needs 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 User Needs 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 User Needs inputs. Each step must complete before the next begins. The Skill does not skip steps to produce a cleaner output.

Validation Rules

↓

Confidence Evaluation

↓

Classification Constraints

↓

Routing Logic

↓

Output Contract

↓

Escalation Conditions

↓

Next Workflow State

What This Block Is Trying to Solve

User Needs Skills interpret scattered observations — interviews, analytics, support tickets, workflow observations, stakeholder assumptions — and organize them into structured need outputs that can orient the rest of Define.

The Skill is not trying to prove a need. It is trying to determine whether enough evidence exists to form a Hunch, and if so, which need that Hunch points toward and what the team should do next.

The output is always directional, not conclusive. Conclusive outputs require validation that happens in later blocks.

Required Inputs

A Skill should not attempt to classify a user need without a minimum viable evidence base. Required inputs are drawn from the Playbook inputs table.

Minimum for a Hunch:

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 friction is appearing

Minimum for an emerging need:

Three or more distinct input types
Repeated behavioral evidence across more than one user or session
At least one measurable signal — analytics, UX metric, or performance data

Minimum for a validated pattern:

Cross-source reinforcement across behavioral, attitudinal, and performance signals
Measurable recurrence over time
Contradiction visibility — competing explanations have been considered and addressed

If minimum inputs are not present, the Skill routes to Collecting before attempting classification.

Output Contract

Outputs from User Needs Skills must follow the Primary User Need Output structure defined in the Playbook. The Skill is not permitted to produce free-form summaries that omit required fields.

Required output fields:

Category (Five Layers)
User Need (one of the 20 needs)
Summary
Evidence
User Behaviors
User Roadblocks
Why It Matters
Why It Fails
Suggestions
UX Metrics

Output requirements:

Preserve evidence visibility — cite which inputs support which claims
Explain reasoning — do not state conclusions without showing the signal path
Maintain signal separation — do not merge distinct inputs into a single undifferentiated claim
Expose uncertainty — if the need is a Hunch, label it as a Hunch
Connect outputs to observable behavior — do not substitute assumptions for evidence

Prohibited output behaviors:

Recommending solutions before the Hunch is validated
Inferring emotional intent without behavioral evidence
Flattening conflicting signals into a single clean narrative
Hiding ambiguity to produce a more confident-sounding output
Overstating confidence relative to the evidence available
Collapsing multiple distinct needs into one category unnecessarily

Confidence Thresholds

Confidence should reflect the strength, diversity, and consistency 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: 550px;"><colgroup><col style="min-width: 25px;"><col style="width: 259px;"><col style="width: 266px;"></colgroup><tbody><tr><td colspan="1" rowspan="1">State</td><td colspan="1" rowspan="1" colwidth="259">Meaning</td><td colspan="1" rowspan="1" colwidth="266">Allowed Output</td></tr><tr><td colspan="1" rowspan="1">Weak signal</td><td colspan="1" rowspan="1" colwidth="259">Insufficient evidence to form a direction</td><td colspan="1" rowspan="1" colwidth="266">Route to Collecting. Do not classify.</td></tr><tr><td colspan="1" rowspan="1">Possible pattern</td><td colspan="1" rowspan="1" colwidth="259">Early directional signal from one or two inputs</td><td colspan="1" rowspan="1" colwidth="266">Note the direction. Flag as speculative.</td></tr><tr><td colspan="1" rowspan="1">Hunch</td><td colspan="1" rowspan="1" colwidth="259">Repeated but incomplete evidence across two or more input types</td><td colspan="1" rowspan="1" colwidth="266">Form a Hunch. Name the need. State what would confirm or refute it.</td></tr><tr><td colspan="1" rowspan="1">Emerging need</td><td colspan="1" rowspan="1" colwidth="259">Consistent multi-source evidence with behavioral grounding</td><td colspan="1" rowspan="1" colwidth="266">Produce a structured output. Flag remaining gaps.</td></tr><tr><td colspan="1" rowspan="1">Recurring signal</td><td colspan="1" rowspan="1" colwidth="259">Measurable recurring behavior across sessions or users</td><td colspan="1" rowspan="1" colwidth="266">Produce a full output. Route to Signals or Metrics.</td></tr><tr><td colspan="1" rowspan="1">Validated pattern</td><td colspan="1" rowspan="1" colwidth="259">Cross-source reinforcement with measurable recurrence</td><td colspan="1" rowspan="1" colwidth="266">Produce a full output. Route to Experiments or Reviews.</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 User Needs block contains 20 needs organized across five layers. Classification must respect the boundaries of this system without forcing simplification when evidence is ambiguous.

The Skill should:

Allow overlapping needs when evidence supports multiple conditions simultaneously
Preserve layered friction — a workflow may contain Basics, Trust, and Personal needs at the same time
Maintain unresolved classification when evidence does not clearly separate competing needs
Allow parallel interpretations when signals point in more than one direction

The Skill should not:

Force a single need classification when evidence supports more than one
Collapse multiple needs into one category to produce a cleaner output
Assume a higher-layer need when a lower-layer need may still be unresolved
Skip the Five Layers sequence without evidence that foundational needs are already met

Example: A workflow may simultaneously contain Insightful friction, Reliable hesitation, and Efficient breakdowns. The Skill should preserve all three and route to Collecting or Patterns to clarify which need is most foundational before prioritizing.

Failure Modes

These are the most common classification errors a User Needs Skill must actively avoid. Each represents a situation where a plausible but incorrect need leads to a wrong intervention.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 410px;"><colgroup><col style="min-width: 25px;"><col style="width: 385px;"></colgroup><tbody><tr><td colspan="1" rowspan="1">Failure</td><td colspan="1" rowspan="1" colwidth="385">Operational Risk</td></tr><tr><td colspan="1" rowspan="1">Desirable mistaken for Useful</td><td colspan="1" rowspan="1" colwidth="385">Visual redesign applied instead of comprehension improvement</td></tr><tr><td colspan="1" rowspan="1">Efficient mistaken for Reliable</td><td colspan="1" rowspan="1" colwidth="385">Workflow acceleration applied instead of trust repair</td></tr><tr><td colspan="1" rowspan="1">Engaging mistaken for Useful</td><td colspan="1" rowspan="1" colwidth="385">Interaction polish applied instead of task completion improvement</td></tr><tr><td colspan="1" rowspan="1">Engagement mistaken for success</td><td colspan="1" rowspan="1" colwidth="385">Friction hidden behind activity metrics</td></tr><tr><td colspan="1" rowspan="1">Satisfaction mistaken for comprehension</td><td colspan="1" rowspan="1" colwidth="385">Users feel positive but remain confused about what to do</td></tr><tr><td colspan="1" rowspan="1">Recent signals over-weighted</td><td colspan="1" rowspan="1" colwidth="385">Temporary patterns treated as systemic needs</td></tr><tr><td colspan="1" rowspan="1">Weak evidence treated as validation</td><td colspan="1" rowspan="1" colwidth="385">Hunch promoted to validated need without cross-source reinforcement</td></tr><tr><td colspan="1" rowspan="1">Stakeholder assumption treated as signal</td><td colspan="1" rowspan="1" colwidth="385">Internal opinion included as behavioral evidence</td></tr></tbody></table>

When a failure mode is detected, the Skill should preserve competing explanations rather than resolving to the more confident-sounding interpretation.

Transition Logic

Transition Logic defines when and where the Skill routes work after producing a User Needs output. The next transition should reduce uncertainty — not simply advance the process.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 410px;"><colgroup><col style="min-width: 25px;"><col style="width: 120px;"><col style="width: 265px;"></colgroup><tbody><tr><td colspan="1" rowspan="1">Condition</td><td colspan="1" rowspan="1" colwidth="120">Route To</td><td colspan="1" rowspan="1" colwidth="265">Purpose</td></tr><tr><td colspan="1" rowspan="1">Evidence is weak or from a single source</td><td colspan="1" rowspan="1" colwidth="120">Collecting</td><td colspan="1" rowspan="1" colwidth="265">Strengthen signals before forming a Hunch</td></tr><tr><td colspan="1" rowspan="1">Hunch is formed but cause is unclear</td><td colspan="1" rowspan="1" colwidth="120">Hunches</td><td colspan="1" rowspan="1" colwidth="265">Structure interpretation before moving to outputs</td></tr><tr><td colspan="1" rowspan="1">Repeated measurable friction is visible</td><td colspan="1" rowspan="1" colwidth="120">Signals</td><td colspan="1" rowspan="1" colwidth="265">Operationalize patterns for continuous tracking</td></tr><tr><td colspan="1" rowspan="1">Conflicting interpretations remain unresolved</td><td colspan="1" rowspan="1" colwidth="120">Patterns</td><td colspan="1" rowspan="1" colwidth="265">Clarify classification before committing to a need</td></tr><tr><td colspan="1" rowspan="1">Need is validated and improvement needs measuring</td><td colspan="1" rowspan="1" colwidth="120">Metrics</td><td colspan="1" rowspan="1" colwidth="265">Define what success looks like before experimenting</td></tr><tr><td colspan="1" rowspan="1">Need is validated and direction exists</td><td colspan="1" rowspan="1" colwidth="120">Experiments</td><td colspan="1" rowspan="1" colwidth="265">Reduce directional risk before scaling</td></tr><tr><td colspan="1" rowspan="1">Stakeholder alignment is missing</td><td colspan="1" rowspan="1" colwidth="120">Reviews</td><td colspan="1" rowspan="1" colwidth="265">Ground cross-functional conversations in evidence</td></tr></tbody></table>

Transitions should remain reversible. If new evidence changes interpretation after a transition, the Skill should support returning to User Needs 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 Collecting
Confidence stays below Hunch threshold after two or more input types are present
Multiple need interpretations remain equally plausible
Business impact of the decision is high and evidence quality is weak
Signal diversity is insufficient to distinguish between competing needs
A stakeholder assumption is the only available input

Escalation outputs must:

Preserve uncertainty visibly — do not resolve before escalating
Explain which interpretations remain unresolved and why
Identify specifically what evidence is missing
Recommend next Collecting steps rather than defaulting to a direction
Label the output state clearly — unresolved ambiguity, conflicting evidence, or insufficient signals

Ambiguity Handling

Ambiguity is operationally normal in User Needs workflows. Most inputs arrive incomplete, partially conflicting, or insufficiently diverse to support confident classification. 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 explanations when evidence supports more than one need
Identify specifically what evidence 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 resolution to produce a more coherent output
Optimize for narrative smoothness over interpretive accuracy
Collapse uncertainty into confidence when evidence does not support it
Remove contradictory evidence because it complicates the output

Guardrails

Guardrails are hard operational boundaries. They apply to every User Needs output regardless of confidence state, input quality, or workflow context.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 365px;"><colgroup><col style="min-width: 25px;"><col style="width: 340px;"></colgroup><tbody><tr><td colspan="1" rowspan="1">Guardrail</td><td colspan="1" rowspan="1" colwidth="340">What It Prevents</td></tr><tr><td colspan="1" rowspan="1">Preserve conflicting evidence</td><td colspan="1" rowspan="1" colwidth="340">Premature resolution of competing need interpretations</td></tr><tr><td colspan="1" rowspan="1">Preserve unresolved ambiguity</td><td colspan="1" rowspan="1" colwidth="340">False confidence in outputs with incomplete evidence</td></tr><tr><td colspan="1" rowspan="1">Expose evidence sources</td><td colspan="1" rowspan="1" colwidth="340">Untraceable claims that cannot be evaluated or challenged</td></tr><tr><td colspan="1" rowspan="1">Maintain classification visibility</td><td colspan="1" rowspan="1" colwidth="340">Hidden assumptions about which need is driving behavior</td></tr><tr><td colspan="1" rowspan="1">Separate observation from interpretation</td><td colspan="1" rowspan="1" colwidth="340">Conflation of what users did with what they felt or intended</td></tr><tr><td colspan="1" rowspan="1">Never recommend solutions before Hunch validation</td><td colspan="1" rowspan="1" colwidth="340">Premature direction-locking before Define is complete</td></tr><tr><td colspan="1" rowspan="1">Never replace behavior with assumptions</td><td colspan="1" rowspan="1" colwidth="340">Inference substituted for observable evidence</td></tr><tr><td colspan="1" rowspan="1">Never collapse the Five Layers prematurely</td><td colspan="1" rowspan="1" colwidth="340">Skipping foundational needs to address higher-layer experiences</td></tr></tbody></table>

Guardrails prioritize interpretive accuracy over output smoothness. A less confident but more accurate output is always preferred.

Multi-Agent Workflows

User Needs Skills may operate as part of a larger multi-agent workflow where interpretation, synthesis, validation, and prioritization are handled by independent Skills operating in sequence.

In these configurations:

The Interpretation Skill classifies signals against the Five Layers and 20 needs
The Synthesis Skill organizes multiple emerging needs into a structured output using the Playbook format
The Validation Skill evaluates confidence thresholds and routes to the appropriate next block
The Prioritization Skill applies the Multiple User Needs logic from the Playbook to determine which need is most foundational

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 User Needs workflows.

Human judgment remains responsible for:

Prioritization across competing needs when evidence is roughly equal
Strategic tradeoffs between user needs and business constraints
Organizational context that the Skill cannot observe
Business consequences of acting on a validated need
Leadership decisions about which workflows to invest in
Awareness of team dynamics, timing, and political context that affects what is actionable

The goal is stronger operational decision support through calibrated Skill behavior — not replacement of the judgment that makes decisions consequential.

Glare Tools

Contribute to Glare

Identify where decision quality breaks down

The Glare Design Assessment helps teams spot weak validation, stakeholder friction, alignment gaps, and assumptions that scale without measurable learning—so you have a clearer starting point for improvement.

About 5 minutes · Team-based · Diagnostic snapshot you can act on

Take the Design Assessment