Every decision in a Lighthouse Sprint is governed by seven operating constraints. These aren't aspirations — they're hard rules. If a sprint activity violates any of them, the activity gets redesigned or removed.

The Lighthouse Sprint is a fixed-scope, time-boxed engagement with four sequential stages. Each stage ends with a quality gate — a go/no-go decision that must be passed before the next stage begins. After Stage 4, the engagement extends into Lighthouse Watch — the productized continuous service that maintains the system, updates governance, and ships one improvement per month drawn from the pattern library.

The Sprint ends at Gate 4 with a working production system. What happens next is the part most consultancies leave unsolved. Foundation models drop every 8–12 weeks; eval suites drift; governance ages; the pattern library sharpens with every subsequent engagement. Without a structural mechanism to absorb that churn, the system you signed off on this quarter starts to look different from the system you've got next quarter — and the people closest to the system aren't always the ones who notice first.

Lighthouse Watch is that mechanism. It is part of the Lighthouse architecture, not an add-on. Every Sprint contract proposes Watch as the default next step in Week 8; about 70% of clients sign Watch · Standard within 30 days of Sprint closeout. The lead engineer who shipped the Sprint is the lead engineer who runs the Watch — no learning-curve gap.

Every Lighthouse Sprint has six defined roles — three from Studio, three from the client. Role clarity eliminates ambiguity about who owns decisions, who does the work, and who signs off at each gate.

Discovery is the foundation. We map the current workflow end-to-end, stopwatch every step, quantify bottlenecks, and determine whether this workflow is a fit for agentic redesign. If it isn't, we say so — and the engagement ends cleanly at Gate 1.

Redesign is where we architect the new workflow. Not optimization of the old one — a fundamentally new workflow where agents carry the operational load and humans supervise from above the loop.

Every task in the workflow is classified into one of four categories:

Build is the longest stage. We construct the agents, wire integrations, deploy the governance wrapper, and push to production. Weekly sprint cadence with demos every Friday.

Handoff is where Studio proves the system works and proves the client can run it independently. If either condition fails, Handoff isn't complete.

The Governance Wrapper is not an add-on — it's a core component shipped with every Lighthouse Sprint. Six components, all required, all production-grade.

The Pattern Library is Studio's compounding asset. Every engagement extracts reusable agent components — patterns that can be adapted and deployed in future sprints. The library currently holds 18 patterns across four Umbra Group properties: 14 production-tested from Indietheka (each with a traceable incident receipt), plus 4 from Radiohead Community, Transit, and Orbit at various stages of development.

14 patterns extracted from the first Lighthouse Sprint. The original 4 were designed during the sprint; the remaining 10 emerged from production incidents and were codified as reusable rules. Full detail with incident receipts in §12.8.

Patterns from other Umbra Group properties at various stages of development. These will be enriched with incident receipts as each property’s agents mature in production.

Four patterns extracted from migrating Indietheka's 16-agent fleet to durable infrastructure (Q1 2026) and building Atlas — the studio-level orchestrator — on top (Q2 2026). All four are in production at Indietheka and packaged as @umbra/* for cross-property reuse.

A pattern library that only ships with new Sprints is a static asset. Watch is what makes it compounding. Every Watch month, the lead engineer reviews the most recent library additions and proposes one as the next month's +1 improvement — deployed into the client's existing system, eval-gated before promotion. After 12 months on Watch, a client's system has accumulated 12 deployed pattern updates that they didn't commission individually.

The reverse channel matters too: every +1 delivered surfaces a candidate pattern back into the library. Three matching +1's across clients = the pattern moves from candidate to canonical. Watch is therefore both a distribution channel (library → client) and a research instrument (client signal → library) — the mechanism that keeps engagement #N priced below engagement #1 because the pattern shelf is deeper.

Studio engagements are fixed-fee and outcome-tied. The client knows the cost upfront. If the measurable outcome doesn't beat the baseline, the pricing structure reflects that.

After the Sprint ships, the system extends into Lighthouse Watch: monthly cadence, three tiers, 12-month minimum on Standard and Pro. Default offer at Sprint closeout is Watch · Standard. About 70% of Sprint clients sign within 30 days. Sales sheet · contract template.

Every Lighthouse Sprint produces standardized deliverables using these templates. Templates ensure consistency across engagements and reduce the Sprint Lead's prep time.

The Indietheka editorial pipeline was the first Lighthouse Sprint — applied internally to Umbra Group's own newsroom in Q4 2025. This section shows how the framework's templates were applied to a real engagement — a concrete reference for future sprints. Industry: digital media. Workflow: editorial content pipeline. Duration: 8 weeks. Sprint outcome: 7× throughput, 90% fewer human hours, 16 agents, 14 reusable patterns. Six-month update: the fleet has moved off Cowork sessions onto durable infrastructure — 26 workflows running 24/7, a Slack feedback loop for post-publish corrections, an operational dashboard, Atlas running as a studio-level orchestrator above the fleet, and eight patterns externalized as @umbra/* packages. Zero missed publish days across the cutover. It is also the engagement profile the major foundation labs began publicly hiring for in Mexico City in May 2026 — Studio has been running it since Q4 2025.

The Workflow Audit captured 12 discrete steps in the editorial pipeline. Key findings from the stopwatch exercise:

The initial redesign classified all 12 workflow steps into four allocation categories. As the system matured in production, four additional agents emerged — expanding the fleet from 6 to 16 and pushing automation coverage across the full editorial lifecycle: RSS → discovery → writing → SEO → publishing → distribution → analytics → calendar planning.

Original 6 agents/automations — designed in Week 3–4 and deployed by Week 7:

10 agents added in production — each born from gaps discovered after the original 6 went live:

Sixteen agents/automations in production, evolved iteratively from the original 6. Each agent’s design was informed by incidents from previous agents — Long-Form Editorial Pipeline’ endpoint-only writes came from Multi-Channel Distribution’s cell-drift bugs; the Pre-Publish Verification Protocol grew organically from 0 to 9 check groups as errors were caught and codified.

Supporting production infrastructure — not agents themselves, but shared systems the agents depend on:

The original plan called for a linear 3-week deployment (AGT-01/02 in Week 5, AGT-03/04 in Week 6, AGT-05/06 in Week 7). In practice, the system evolved iteratively — each agent’s design was shaped by production incidents from its predecessors. The ten additional agents (AGT-07 through AGT-16) were not in the initial scope; they emerged from gaps revealed only after the core pipeline was running live.

Baseline vs. current production comparison. Initial metrics were captured at Week 8 handoff (6 agents); current figures reflect the mature 16-agent system with SEO, discovery, proposals, and the weekly feedback loop operational.

14 patterns extracted from the Indietheka sprint — the original 4 updated with production detail, plus 10 new patterns each born from a real incident with a traceable receipt. Documentation standard for each: inputs/outputs, dependencies, governance needs, incident receipt, and adaptation notes for other client contexts.

Updated originals (USP-001–004)

New patterns (USP-005–014) — each traceable to a production incident:

Atlas was added in Q2 2026 — six months after Sprint closeout — when the editor needed a single touch-point above the fleet rather than per-agent dashboards. Atlas reads the entire migrated fleet, classifies editorial feedback in Slack, commits corrections back to the repo, dispatches non-deterministic work to Cowork sessions, and runs a morning brief against everything below it. Not part of the original Sprint scope — an extension built using the same patterns the Sprint extracted, which is the proof the library compounds.