The Redesign Playbook.

Goal: Activate Phase 2. Re-anchor on the Gate 1 decision. Introduce the allocation framework. Set the Week 3 meeting rhythm.

Agenda (90 min):

• 00:00–00:15 Gate 1 read-back · re-confirm outcomes, Conditional Go conditions (if any), scope.
• 00:15–00:40 Bottleneck recap · top 3–5 from Discovery, cost impact, acknowledged priority order.
• 00:40–01:10 Allocation framework primer · four categories, what each means, how the workshops run. Sprint Lead teaches. Workflow Owner listens.
• 01:10–01:25 Week 3 meeting calendar · confirm allocation workshop (Day 12), mid-week checkpoint (Day 15), all other holds.
• 01:25–01:30 Governance introduction · Governance Architect briefly introduces self and role.

Afternoon: Agent Engineer and Governance Architect onboard. Sprint Lead shares Workflow Audit, Baseline Metrics, Discovery Report, Fit Assessment via the shared drive. Agent Engineer begins reading. Governance Architect drafts the risk treatment sketch that will anchor Day 14.

Output: Kickoff memo, allocation worksheet opened, Agent Engineer onboarded, Governance Architect onboarded.

Goal: Categorise every step in the Workflow Audit into one of four allocation categories. This is the most consequential three hours of Redesign.

Method:

• Pre-read: Workflow Owner receives the allocation framework primer the night before. No live explanation at the workshop.
• Workshop flow: Sprint Lead facilitates. Agent Engineer challenges. Workflow Owner decides judgement-calls. Every step in the Workflow Audit is discussed once; assignment is captured live in the allocation matrix.
• Four categories: Fully Autonomous, Agent-Initiated Human-Approved, Human-Led Agent-Assisted, Human Only. See §05 for rigorous definitions.
• Ambiguity rule: When the category is ambiguous, default to the more human-inclusive option (Human-Led over Agent-Initiated, Agent-Initiated over Fully Autonomous). Redesign adds autonomy over time; it rarely removes it once shipped.

Output: Allocation matrix v0.5 with every step categorised, including a short rationale column. Controversial allocations flagged.

Red flags: Workflow Owner wants everything in Fully Autonomous — they are underweighting judgement. Workflow Owner wants everything in Human Only — they are defending status quo; the allocation has not been earned yet. Both patterns need facilitation — do not let either dominate.

Goal: Group allocated steps into named agents. Draft the agent roster — the list of discrete agents this sprint will build, with mission, ownership, and scope boundaries each.

Method:

• Grouping principle: Steps group into an agent when they share a trigger, operate on the same data domain, or handoff outputs between each other. A single agent owns a coherent sub-process — not a single step, and not the whole workflow.
• Scope boundaries: Each agent has a defined entry point, a defined exit condition, and an explicit statement of “what this agent does not do.” The negative scope is as important as the positive.
• Rule of 10: The roster should produce between 5 and 10 agents for a Standard Sprint. Fewer than 5 and the workflow was probably too narrow to need sprint-level investment. More than 10 and the sprint scope is wrong — go back and split the workflow.
• Naming: Agents have human-readable names, not identifiers. “Research Compiler,” not “agent-04”. Names show up in alerts, audit trails, and client conversations.

Output: Agent roster (name, mission, allocated steps, ownership, scope boundary) in the Redesign Blueprint’s Roster tab.

Red flags: An agent that spans more than 5 atomic steps is probably two agents. An agent whose mission requires narrating more than one sentence to explain is probably two agents. Split early.

Goal: Map the six Governance Wrapper components to every agent on the roster. This produces the first-pass wrapper design that Build will implement.

Method:

• Six components: Monitoring, Alerting, Audit Trail, Escalation, Override, Rollback. Each has a defined specification (see §07).
• Per-agent mapping: For each agent, the workshop answers: what do we monitor? What triggers an alert? How is activity audited? Who gets escalated to, and when? How does a human take over? What does a rollback look like?
• Spreadsheet-as-state-machine (USP-009): For agents that operate on a queue or state machine, the wrapper pattern always includes a spreadsheet with column-based approval gates. This is Studio’s standard — lightweight, inspectable, client-friendly, and compatible with any client stack.
• Technical Counterpart present: They sign off that the monitoring and audit mechanisms can live in the client’s infrastructure or a Studio-managed layer as appropriate.

Output: Governance Wrapper design v0.5 (one tab in the Redesign Blueprint with six columns per agent). Escalation tree drafted.

Goal: Show the allocation matrix and agent roster to the Workflow Owner. Surface disagreements before Week 4 locks them into the blueprint. Lock the roster at v1.0.

Agenda (90 min):

• 00:00–00:20 Allocation matrix walkthrough — every step, every category, rationale for controversial calls.
• 00:20–00:45 Agent roster — introduce each agent by name and mission.
• 00:45–01:10 Governance preview — Governance Architect presents the six-component design pattern, example for the highest-risk agent.
• 01:10–01:25 Integration preview — Agent Engineer describes data flow at high level.
• 01:25–01:30 Lock — Workflow Owner signs off on allocation and roster; changes after this point trigger re-plan.

Afternoon: Sprint Lead sends a Week 3 memo to Executive Sponsor: allocation summary, agent roster, governance preview, Gate 2 date confirmed.

Output: Allocation matrix v1.0 (locked), agent roster v1.0 (locked), Governance Wrapper design v0.5, Week 3 memo.

Red flags: Workflow Owner rewrites more than 20% of allocation at the checkpoint. Week 4 extends by 2 days; Gate 2 moves. Budget the slip in the Risk Register.

Goal: Draft one Agent Spec Sheet per agent on the roster. These are the contracts Build works against.

Method:

• Template: lighthouse-agent-spec-sheet.docx. Eight fields per agent: mission, trigger, inputs, decision rules, outputs, failure modes, success criteria, governance.
• One agent = one spec: Never combine two agents into one sheet. The spec is the build target — ambiguity here becomes bugs in Phase 3.
• Success criteria specificity: “Works correctly” is not a success criterion. “Produces WordPress draft within 15 minutes of trigger, with Yoast SEO metadata fully populated, in 95%+ of invocations measured over a 7-day rolling window” is a success criterion.
• Governance link: Every spec cross-references the Governance Wrapper design row for that agent. Monitoring and alerting are part of the contract, not an afterthought.

Output: Agent Spec Sheets v0.5, one per agent, stored in /02-redesign/specs/.

Goal: Draw the complete data flow: client systems, Studio-built agents, Governance Wrapper, human checkpoints, external services. Every arrow labeled.

Method:

• Nodes: Every system that produces or consumes data. Client CRM, client CMS, client spreadsheet, Studio-built agent, third-party API, human operator.
• Arrows: Every data flow. Include direction, payload type (link, structured, file), protocol (API, file drop, webhook, scheduled pull), and frequency.
• Trust boundaries: Annotate where data crosses trust boundaries (client-to-Studio, Studio-to-third-party). These become the security-review focus in Build.
• Technical Counterpart sign-off: They must confirm each integration is feasible given current client infrastructure. Infeasibilities get flagged in the Risk Register.

Output: Integration diagram (Figma, Miro, or Mermaid) committed to /02-redesign/integration/.

Goal: Build the Risk Register from v0 (Discovery-opened) to v1.0. Every known risk, scored, with a named treatment plan and owner.

Method:

• Tool: lighthouse-risk-register.xlsx. Ten pre-populated common risks; add engagement-specific risks on top.
• Scoring: 5×5 matrix — likelihood (1–5) × impact (1–5). Composite 15+ = critical; 8–14 = elevated; below 8 = standard.
• Treatment plans: Every critical and elevated risk has one of four treatments: avoid (redesign the agent to eliminate), mitigate (build a control), transfer (shift to client or third party), accept (name who signed the acceptance).
• Owners: Every risk has a named owner. Unassigned risks are unmanaged risks.

Output: Risk Register v1.0; critical risks summary slide for Gate 2.

Goal: Assemble the Redesign Blueprint — the single canonical artifact of Phase 2. Author the Gate 2 deck. Circulate both at T-24 hours.

Blueprint structure (tabs):

• Overview — workflow summary, agent count, allocation summary.
• Allocation matrix — every step, every category, rationale.
• Agent roster — name, mission, scope, ownership.
• Agent specs — link to the individual Agent Spec Sheets.
• Governance wrapper — six-component matrix.
• Integration map — link to the diagram.
• Risk register — link to v1.0.
• Build plan — Week 5–9 schedule preview, Friday demo sequence.

Gate 2 deck structure: 12 slides mirroring the Blueprint. Circulate to Executive Sponsor, Workflow Owner, Technical Counterpart 24 hours before Gate 2.

Goal: Present the Redesign Blueprint. Secure Approved / Approved with Changes / Rejected decision. Close Phase 2.

Agenda (120 min):

• 00:00–00:10 Re-anchor on Gate 1 outcomes.
• 00:10–00:25 Allocation summary — what moves to agent, what stays human, net shift.
• 00:25–00:50 Agent roster walkthrough — each agent named, described, scoped.
• 00:50–01:15 Governance Wrapper — six components, critical safeguards, escalation paths.
• 01:15–01:30 Integration & data flow — trust boundaries, security posture preview.
• 01:30–01:45 Risk Register — top 5 risks, treatments, acceptance asks.
• 01:45–01:55 Build plan & commercial — 5-week schedule, demo cadence, invoicing milestones.
• 01:55–02:00 Decision — Executive Sponsor, Workflow Owner, Technical Counterpart sign.

Output: Gate 2 decision captured in writing within 24 hours. Redesign Blueprint v1.0 locked. Build activates Monday.