Fleets & Adoption: From One Repo to the Org

By the end of this chapter you can take the Repo Assistant from one repo to a governed, multi-repo fleet — installing shared workflows across many repositories, coordinating cross-repo work, rolling out safely, and following an enterprise adoption playbook. This is the top of the maturity arc the book has climbed since page one.

Everything targets gh aw v0.81.6. The assistant that triaged one issue in Chapter 2 becomes an org-wide capability, run from a single source of truth.

Something “qualitatively different becomes possible” when agentic workflows move beyond a single repository: they can “coordinate or scale across dozens of repositories simultaneously” — rolling out changes org-wide, assessing code quality across hundreds of repos, or “aggregat[ing] issue tracking into a single control plane” (Using at Scale). A fleet isn't just many copies of one workflow; it's a managed practice.

This is the arc the whole book has followed: the Individual (one workflow), the Team (safe, reviewed, patterned), and now the Organization (a fleet at scale). Each level reused everything below it — the fleet is just Parts I and II, governed and multiplied.

Distribution has “two complementary layers” (Using at Scale).

1. Install and update (developer-facing)

Use gh aw add (or gh aw add-wizard) to “install a workflow from another repository, and gh aw update to pull in upstream changes while preserving local edits.” A workflow installed this way records where it came from in its source: field. The recommended org structure is a central agentic-workflows repository as “the source of truth,” with workflows “versioned with exact tags (@v1.2.0)” or SHA pins.

2. Coordinate across repos (the dispatcher pattern)

For work that spans repositories, two patterns matter. CentralRepoOps is “where a central control repository dispatches work to target repositories or aggregates issues from component repositories”; OrchestratorOps handles “dispatching parallel worker workflows for large-scale multi-repo operations” (Using at Scale). The cross-repo writes flow through the same safe-outputs boundary, now with target-repo and allowed-repos; GitHub Apps are “preferred for automatic token rotation and fine-grained scoping.”

3. Roll out safely

Don't flip a fleet to production writes on day one. Safe Rollout “describes how to move from report-only or staged behavior to production writes with evidence and control” — using the staged: true preview mode from Chapter 6 as a shadow-evaluation step before promotion (Using at Scale).

Scaling multiplies both value and mistakes. Before cloning a workflow across a fleet, it should have earned it on one repo first. A readiness checklist:

When not to

• Don't fan out a workflow you haven't operated. Prove it on one repo; earn the fleet.
• Don't copy-paste across repos. That's the drift trap — distribute a pinned shared import so one change updates everyone.
• Don't go to production writes without a rollout. Start report-only or staged, gather evidence, then promote.
• Don't scale without central governance. A fleet without org defaults and policy gates is an unbounded cost-and-risk surface; set them before you widen, not after.

Here is the Repo Assistant as a fleet citizen: it imports the org's central triage policy, records where it was installed from, and tags its output for fleet-wide search. Every repo runs this same thin file.

on:
  issues: { types: [opened, reopened] }
  workflow_dispatch:
permissions: { contents: read, issues: read }
engine: copilot
network: { allowed: [defaults, github] }
source: "my-org/agentic-workflows/workflows/triage.md@v1.2.0"  # where it came from, pinned
tracker-id: repo-assistant-triage      # find all its assets fleet-wide
imports:
  - shared/triage-policy.md            # the org's single source of truth
tools:
  repo-memory: true

This one file embodies the whole of Part III. The policy comes from a shared import (Ch. 11), so a fix propagates everywhere. source: pins it to a released version of the central repo, so gh aw update pulls upgrades deliberately. tracker-id: makes the fleet auditable — one search finds every comment and label it produced across every repo. And it inherits the budgets and policy gates an admin set org-wide (Ch. 13).

# install the central workflow into a repo (records source:)
gh aw add my-org/agentic-workflows/workflows/triage.md@v1.2.0

# later, pull the org's upgrade while preserving local edits
gh aw update

# find everything the fleet's triage assistant has done
#   GitHub search: "gh-aw-tracker-id: repo-assistant-triage" in:body

gh aw compile examples/ch14/fleet-triage.md
# ✓ examples\ch14\fleet-triage.md (109.9 KB)
# ✓ Compiled 1 workflow(s): 0 error(s), 0 warning(s)

You've reached the top of the arc — from one workflow to a governed fleet:

• Beyond one repo, workflows coordinate and scale across dozens — org-wide rollouts, cross-repo quality, a single issue-tracking control plane.
• Distribute via gh aw add/update from a central source-of-truth repo with pinned versions; coordinate with CentralRepoOps/OrchestratorOps and cross-repo safe outputs.
• Roll out safely (report-only → staged → production), make the fleet auditable with tracker-id, and govern it centrally before you widen.
• A fleet is just Parts I–II, governed and multiplied — and it's where measured impact (15 repos, 651 issues, 9× velocity) shows up.

The road ahead. You set out to look at your own repository, spot three tasks a tireless teammate could own overnight, and ship a governed agentic workflow that does them — safely, cheaply, and reviewably. You now can. Start with one 10-minute win, earn trust, and let the fleet compound. That's Continuous AI: the outer loop, automated — with people firmly in the loop. Go build your Repo Assistant.