The concepts.
No filler.

Before the session is scheduled, the facilitator and the designated client lead confirm the participant list. Not everyone who wants to attend needs to attend. The question is: who can speak authoritatively to business intent, technical architecture, and governance constraints — and who has the authority to make decisions in the room?

The right room makes the session. The wrong room — missing the decision-maker, too many observers, no technical owner — surfaces in Phase 2 and stops progress.

The Pre-Session Brief is distributed to all participants before the session. It sets expectations: what the session will produce, what decisions will be made, and what each participant is expected to bring.

It is not a long document. Its purpose is to eliminate the first 20 minutes of any meeting — the part where people figure out why they're there. Every participant who reads it arrives knowing the stakes and their role.

Before the session opens, the facilitator confirms whether the client has completed the ARA. This is not a formality — it changes how Phase 2 runs.

If the ARA is complete, the Domain Coverage Check in Phase 2 takes roughly 10 minutes: it confirms what the ARA already found. If the ARA has not been completed, the facilitator runs the full domain review with the room — typically 20–30 minutes — before the Mission Statement is written.

The Domain Coverage Check is Step 1 — not because it is the most interesting step, but because it is the forcing function that prevents the rest of the session from scoping itself incorrectly. The Mission Statement cannot be written until the room agrees on what is in scope and what is not.

For each domain relevant to the engagement, the room assigns one of three statuses: In Scope, Out of Scope, or Unknown. Domains marked Unknown become Pink Stickies immediately — with a named owner — before the Mission Statement discussion begins.

Domains are scoped per engagement and vary by industry and organizational context. The example below reflects a public transit deployment — domains are adapted for each client.

Public Transit Example Domains: Operational Throughput · Real-Time Decision Support · Rider & Customer Experience · System & Vendor Coordination · Compliance & Audit Readiness · Knowledge & Institutional Memory · Capital Program Monitoring · Governance & Accountability

The Mission Statement is one sentence. It describes what the agent is built to accomplish and explicitly states what it is not authorized to do. Both halves are required. A Mission Statement without a constraint clause is not a Mission Statement — it is a description.

The room agrees on this sentence together. It does not belong to the technical team, and it does not belong to the business sponsor alone. It must survive being read by legal, audit, and leadership without a translator.

The Tool Inventory is a complete, named list of every system the agent is authorized to call. For each tool: the input contract, the expected output, rate limits, permission scope, and agreed fallback behavior if the call fails.

This is not a system architecture diagram. It is a decision list. Every tool earns its place in the room before Phase 3 begins. If a tool cannot be confirmed — contract unknown, permissions unclear, fallback undefined — it becomes a Pink Sticky with a named owner.

Before Phase 3 begins, the room establishes the outer edges of what the agent is permitted to do. These are not detailed guardrail tickets — those come out of the loop walk. This step sets the frame: the categories of constraint the room has agreed apply to this agent.

Example: Does the agent have any financial authorization limits? Can it modify records, or only read them? Are there categories of action that always require human approval, regardless of context?

These boundary agreements make the loop walk faster. When a guardrail question surfaces in Phase 3, the room already knows the outer limits — it is determining the exact threshold, not starting from first principles.

The Decision Loop is the core of Phase 3. The room walks the agent's logic step by step — not as an exercise, but as a series of binding decisions about what the agent is authorized to do at each point.

On a simple transaction, the loop may complete in a single pass and is typically a half-day engagement. On a complex agent — multi-step approvals, vendor coordination, tiered escalation — the loop runs multiple times, each pass building on the last. Multiple passes are the norm for production-grade agents and typically require a full day or more. The number of passes determines the appropriate workshop tier.

• 1 — Observe: Agent reads the trigger against its Mission Statement
• 2 — Decide: Autonomous action, gather more info, or escalate?
• 3 — Act: Named tool call with confirmed contract and fallback
• 4 — Guardrail Check: Result tested against agreed constraints
• 5 — Escalate or Continue: Human handoff or next step?
• 6 — Confirm: Did the action resolve correctly?
• 7 — Log Interaction: Audit trail — what happened and who owns it

The agent takes in whatever triggered it and interprets what is being asked, measured against its Mission Statement. The room agrees: what is the trigger? What does the agent see? What context does it have at the point of activation?

Ambiguity here — a trigger that could be interpreted multiple ways — surfaces as a Pink Sticky. The room decides what the agent should do when the input is unclear before it decides what the agent should do when the input is clear.

The agent determines what to do next. Three possible paths: act autonomously on what it knows; gather more information before acting; or escalate to a human because the situation exceeds its authorization.

The room agrees which path applies — and under what conditions each path is triggered. This is one of the most important decisions in the session. Autonomous action that should have escalated is where agentic systems cause real damage.

The room names the tool call. It confirms the input contract — exactly what the agent sends. It confirms the expected output — what a successful response looks like. And it agrees on the fallback behavior if the call fails: retry, escalate, or stop.

Every tool call earns its place before the room moves on. A tool that cannot be confirmed at this step becomes a Pink Sticky with a named owner. The loop does not continue past an unconfirmed call.

The agent tests the result of the action against the guardrails established in Phase 2. Did anything cross a threshold? Did the result fall outside what is permitted?

New guardrail requirements identified here are formalized immediately as Guardrail Definition Tickets — they are not deferred to the end of the session. Each ticket specifies the exact condition or threshold, the owner (co-signed by Product Owner and Tech Lead), and the resolution deadline.

If a guardrail was triggered in Step 4, the agent stops. It hands off to a named human owner, with full context of everything it did up to that point. The room agrees: who receives the handoff? What do they receive? In what form?

If no guardrail was triggered, the loop continues. The room defines the condition that distinguishes these two outcomes — not the general principle, but the specific threshold that applies to this agent, this action, this scenario.

The room defines what a successful outcome looks like: what the agent checks, what constitutes completion, and what sends it back around the loop if the result is ambiguous.

This step closes the loop — or sends it back. The distinction matters: a loop that returns to Step 1 is not a failure; it is the agent working as designed. But the room must agree in advance on what triggers a return, or the agent will run indefinitely on an unresolvable condition.

The room confirms what is recorded at this step — what data, what decisions, what outcomes — and who owns the log. This is not a formality. It is the audit trail that governance, compliance, and leadership will need when they ask what the agent did and why.

The Domain Coverage Map records which Agentic Opportunity domains are In Scope, Out of Scope, or Unknown for the current engagement. Domains are scoped per engagement and adapted to the client's industry and organizational context — they are not a fixed universal list. It is produced in Phase 2, Step 1 — before the Mission Statement is written.

If the ARA has been completed, this step confirms the ARA findings. If not, it is the first structured domain assessment for this engagement.

The Mission Layer Document captures three required elements: (1) the Mission Statement — one sentence describing what the agent is built to accomplish and what it is not; (2) the Tool Inventory — every system the agent can access, with input/output contracts, rate limits, permissions, and failure handling confirmed; and (3) the Guardrail Definitions — the explicit conditions and thresholds that constrain the agent's autonomy.

The business sponsor signs this document in Phase 4. That signature authorizes engineering to begin. If this document cannot be completed in the session, the agent is not ready to be built — the problem is alignment, not engineering.

The Pink Sticky Register captures everything the room surfaces but cannot resolve in the session. Organized by five gap categories:

• Data Gap — missing or incomplete data the agent needs
• Logic Gap — undefined decision rules
• Ownership Gap — no named accountable party for an agent action
• Guardrail Gap — missing or undefined constraint on agent autonomy
• Escalation Gap — no defined process for human handoff

Each entry carries an owner, a deadline, and a resolution status. Open items carry forward after Phase 4 with named owners and resolution deadlines.

Guardrail Definition Tickets are raised immediately when the loop walk surfaces a constraint — not deferred to the end of the session. Each ticket specifies: the guardrail name; the exact condition, value threshold, or trigger it governs; the owner (co-signed by both Product Owner and Tech Lead); and the resolution deadline.

Example: "The agent cannot issue a service credit over $250 without human approval."

The Agent Brief is the one-page executive output produced at the close of every ASDW session. It contains: the agreed Mission Statement; a plain-English list of what the agent does autonomously; what the agent will never do; named escalation triggers with a role or team as owner; all open Pink Stickies with owners and deadlines; and the Crossing Status verdict.

The Crossing Status replaces vague workshop summaries with a defensible, documented position. Three states:

The ARA is the recommended starting point for most organizations. Three structured conversations, less than three hours total. Outputs: Opportunity Stack, Readiness Brief, and Debrief — plus a Crossing Status verdict for the highest-priority agentic opportunity.

The Alignment Sprint covers Phase 2 only. The room completes all four alignment steps and produces a Mission Statement, Tool Inventory, and draft Guardrail Boundaries. The Decision Loop walk does not begin at this tier.

Appropriate when the agent design is straightforward and the primary need is documented, signed alignment before engineering begins — not a full loop mapping exercise.

The full pre-board alignment plus one complete walk of the Decision Loop — happy path, all seven steps, one scenario end to end. Every tool call named, every guardrail checked, every escalation trigger defined.

Requires a completed Opportunity Stack as prerequisite. Appropriate for well-scoped, single-scenario agents. A single loop pass is typically a half-day commitment.

Full pre-board alignment, the happy path loop walk, plus exception scenarios and at least one adversarial pass. Multiple loop passes are the norm at this tier — plan for a full day.

Multiple agents, each walked through their own Decision Loop. A cross-agent governance session maps shared tool calls and conflicting guardrails across the full ecosystem. Output is a program-level Agent Brief covering the agent portfolio, not a single agent.

Appropriate for organizations deploying multiple coordinated agents where cross-agent authorization boundaries and shared tool governance are in scope.

In a standard Wire Walk, the Ghost Gap lives in the handoff between what the business approved and what engineering built. In an agentic deployment, the stakes are higher: the agent will act on the gap, autonomously, thousands of times, before anyone notices.

Agentic Ghost Gaps fall into five named categories — Data, Logic, Ownership, Guardrail, and Escalation — each captured in the Pink Sticky Register during the session.

The Mission Statement anchors every ASDW session. It is one sentence, agreed by the full room, that defines what the agent is built to accomplish and what it is explicitly not authorized to do. A Mission Statement without a constraint clause is a description — not a governance document.

Formula: "The [Agent Name] agent is designed to [achieve this outcome] for [this trigger], by [these tools], without human involvement unless [these conditions are met]."

Guardrails define the edges of autonomous behavior. Three categories:

• Capability Limits — what tools and systems the agent is permitted to call
• Value Thresholds — monetary or operational limits that require human escalation before proceeding
• Escalation Triggers — named conditions that stop autonomous action and hand off to a specific human owner

Guardrail Boundaries are set in Phase 2, Step 4. Specific Guardrail Definition Tickets are raised throughout Phase 3 as the loop walk surfaces exact thresholds.

The Decision Loop is what makes the ASDW structurally different from a standard Wire Walk. A standard walk follows a linear transaction. An agent does not — it reasons, decides, acts, checks its own work, and loops. That cycle may run dozens of times per interaction.

Observe → Decide → Act → Guardrail Check → Escalate or Continue → Confirm → Log

Each step is a binding decision made in the room. The loop walk is not a diagram exercise. It is a governance exercise — every step produces an agreed position on what the agent is authorized to do at that point.

In a standard Wire Walk, a Pink Sticky captures any unknown or risk — and becomes part of the risk register after the session. In the ASDW, Pink Stickies are organized into five named gap types that reflect the specific failure modes of agentic systems:

• Data Gap — missing or incomplete data the agent needs to act
• Logic Gap — undefined decision rules the agent will need to resolve
• Ownership Gap — no named accountable party for an agent action or outcome
• Guardrail Gap — missing or undefined constraint on agent autonomy
• Escalation Gap — no defined process for human handoff when the agent stops

The Crossing Status replaces vague workshop summaries with a documented, defensible position on whether the agent is ready to be built. Three states:

• 🟢 SAFE — Mission and guardrails resolved. Engineering may begin.
• 🟡 CAUTION — Open Pink Stickies in progress. Named owners and deadlines confirmed.
• 🔴 HALT — Mission or guardrails unresolved. Engineering must not begin.

The Agent Brief is the one-page executive output of every ASDW session. It contains the agreed Mission Statement, a plain-English description of what the agent does autonomously, what it will never do, named escalation triggers with owners, all open Pink Stickies with owners and deadlines, and the Crossing Status verdict.

Who reads it: The CRO, legal counsel, the audit team, and any executive who will be accountable for what the agent does in production. It must be readable by all of them without a translator.

The Mission Layer Document captures three elements in a single signed artifact: the Mission Statement, the Tool Inventory (every system the agent can access, with confirmed contracts and failure handling), and the Guardrail Definitions.

The business sponsor signs in Phase 4. That signature is the authorization for engineering to begin. The document then travels to the AI Governance lane during build, where it closes the compliance sign-off gap that typically stalls agentic projects at the gate.

The Four Lanes structure every Walk The Wire session. In an agentic deployment, the lanes are the same — but what moves through them is different.

• The Sky — Customer or system intent. The goal the agent receives.
• The Glass — The interface layer. For agents, this is often an API surface, a dashboard, or a human-agent handoff point.
• The Wire — Tool calls. Every API the agent invokes, with confirmed contracts and failure handling.
• Bedrock — Systems of record. Where the agent reads and writes. Constraints here are non-negotiable.