Company-Wide ADW Adoption Roadmap

This is how Wasteology gets from one engineer running the Agentic Developer Workflow to the whole company building on it, and eventually to a software factory where any team, and even non-developers, can turn an idea into a reviewed, shipped change.

The plan is sequenced by readiness rather than dates. Each phase is earned by proving the one before it.

Guiding principle: prove each rung before climbing

We borrowed this from our own Agent Reliability Standard. A capability moves up only after the level below it is proven with evidence, so the roadmap uses entry and exit gates instead of deadlines. Your team sets the pace.

Two things hold through every phase. ADW is local-first: it runs on a developer's flat, unmetered Claude Code subscription before any metered cloud spend. And it is human-gated: every change lands as a draft PR that a person reviews and merges. Agents do the drafting; people sign off.

See the Visual Timeline for the same plan at a glance.

Phase 0: Foundation (mostly built already)

Goal: get the shared infrastructure a team needs in place before we ask anyone to adopt it, so Phase 1 is about using the platform rather than building it.

Already in place:

• Wasteology Academy. This LMS and its ADW Track (local first, then cloud) drive the weekly cadence in Phase 1, with interactive lessons, labs, quizzes, certificates, and manager reporting.
• The standards. lat.md grounding, the required lat check CI gate, manifest registration, and the two ADW execution models are all documented and enforced.
• A reference orchestration repo. wg-orchestration already unifies many project CLIs under one ops interface. It is the working template teams copy in Phase 2.
• The knowledge atlas. wg-lat-atlas aggregates every repo that is registered and lat-clean.

Exit gate: the Academy is live behind company sign-in, the ADW Track runs end to end, and the champions have completed the local loop themselves.

Phase 1: Learn & Pilot

Goal: give the team two to three months to get genuinely comfortable with ADW by using it on their own real projects, supported by a steady weekly rhythm rather than a one-off training.

What we do:

• Run a weekly knowledge-transfer session backed by the Academy: one module or topic, plus live office hours on the team's actual code. The LMS tracks who is progressing.
• Onboard each project one at a time, following the Module 7 pattern: ground it with lat.md, add the required lat check gate, register its manifest, and wire a local ADW entry point.
• Start with two or three lighthouse projects. We suggest real but forgiving repos with a willing owner, so early wins are visible and mistakes are cheap.
• Name an ADW champion on each team. The person furthest along runs the weekly session and is the first line of help.

Exit gate: each pilot team has shipped several human-merged, ADW-built PRs on its own project, the champion can onboard a new repo without help, and Academy completion is high. Only then does Phase 2 begin.

Phase 2: Orchestrate & Fan Out

Goal: give each team a single orchestration hub, modeled on wg-orchestration, so they can build across many of their projects from one interface instead of one repo at a time.

What we do:

• Stand up a team orchestration repo from the wg-orchestration template, with its own ops-style CLI, a registry of the team's repos, the digest and recommendation queue, and dispatch into both ADW models.
• Work many repos from that one hub. A lead dispatches work to several projects, watches status across all of them, and keeps each repo's lat.md and gate healthy. This is the fan-out.
• We recommend giving each project a roadmap-as-code: a structured roadmap whose deliverables move from planned to implemented to validated to deployed, gated so nothing counts as done without evidence. The hub rolls these into one portfolio view.
• One shape question is worth settling here: a single company-wide meta-repo, one hub per team, or a hub of hubs.

Exit gate: a team runs ADW across three or more of its own repos from a single hub, the portfolio roll-up is trusted enough to run a standup from, and dispatch works for whichever cloud model a job needs.

Phase 3: Atlas & the Software Factory

Goal: every repo feeds one company knowledge atlas, so both agents and people are grounded in the whole company's intent, and the pieces compose into a software factory that even non-developers can safely use.

What we do:

• Feed everything into the atlas. Each onboarded repo's lat.md aggregates into wg-lat-atlas and is validated company-wide. That cross-repo grounding is what makes multi-project, higher-autonomy work trustworthy.
• Earn autonomy one rung at a time. Introduce the recommendation-to-spec-to-build loop (the Tirion pattern, where an agent watches the estate and proposes work) only where the gates have already proven reliable. Draft PR plus human merge never goes away.
• Open the door to non-developers. Someone describes intent in plain language, /spec-create turns it into a grounded spec, ADW implements it, and a human still reviews the result. Templates and the knowledge assistant lower the floor; the safety gates keep the ceiling safe.
• Think of the factory as composition. Many ADW-enabled repos, one atlas, orchestration hubs, and reliable gates add up to building several things at once, from ideas, with people supervising outcomes instead of typing every line.

The factory is really one loop. An idea becomes a grounded spec, ADW builds it, a person reviews and merges it, and the shipped result flows back into the atlas so the next build starts better informed:

Exit gate (a horizon, not a finish line): multiple teams work this way, a non-developer has shipped a real change through the guarded path, and autonomy has only ever advanced after the level below it was proven with metrics.

What runs through every phase

• Safety and governance. An independent maker-checker verifies work, an evidence gate refuses to call anything done without proof, and every change is a draft PR that a human merges. These scale with autonomy, not away from it.
• Cost. Local-first by default, on flat unmetered subscriptions. The metered cloud path is opt-in for unattended work. Track spend from day one so scale stays a choice rather than a surprise.
• People and roles. A champion on each team, owners for each orchestration hub, and a light central steward for the standards and atlas. The Academy is how new people ramp.
• How we measure it. Adoption (repos onboarded, share of PRs built by ADW), learning (Academy completions), and effectiveness (maker-checker pass rate, cost per run).

Risks and how the plan handles them

Risk	Mitigation built into the plan
Agents ship the wrong thing	Spec-first, an independent maker-checker, an evidence gate, and a human merging every draft PR.
Runaway cost	Local-first by default; metered cloud is opt-in and tracked; the commit-message step uses a cheap model.
Knowledge drift (docs rot, agents guess)	The required lat check gate and the atlas keep each repo's ground truth honest; a broken reference cannot merge.
Uneven adoption, or "the one expert"	Champions on each team plus the Academy make the knowledge transferable rather than locked in one head.
Over-reach into autonomy	The maturity ladder: never skip a rung, and higher autonomy is earned with metrics.

Decisions for leadership

The plan is built so these stay your levers:

1. Pilot scope. Which two or three lighthouse projects and teams go first?
2. Orchestration shape (Phase 2). One company-wide meta-repo, one hub per team, or a hub of hubs? Our recommendation is one hub per team, federated into a light company roll-up. It mirrors how wg-orchestration already works and keeps ownership close to the team.
3. Pace. The two-to-three-month familiarization window per team is a starting point; the gates, not the calendar, decide when a team advances.
4. Non-dev scope (Phase 3). Which non-developer workflows are safe to open first, and what extra review do they need?
5. Governance. How much of the standards and atlas is centrally stewarded versus team-owned?