This is the abridged developer documentation for Central Agentic Ops # Hyperscale Agentic Campaigns.
Centralized Control Planes. > CAO coordinates Agentic Campaigns, each across its explicitly enrolled repositories—shared policy, staged rollout, bounded execution, cross-campaign evidence, and human decisions about what scales next. # What Is Central Agentic Ops? > Learn how CAO runs, observes, and evolves governed agentic campaigns across an enterprise. Central Agentic Ops (CAO) is a control plane for agentic work at enterprise scale. It runs governed campaigns across authorized repositories and connects every run to evidence, cost, and results. ## Common Use Cases [Section titled “Common Use Cases”](#common-use-cases) CAO supports many kinds of bounded agentic campaigns. It often delivers the clearest immediate value on necessary work that individual development teams should not have to carry manually: * **Maintenance:** dependency upkeep, configuration drift, stale automation, and repository hygiene. * **Compliance:** evidence collection, control assessment, policy checks, and bounded remediation. * **Operational toil:** repetitive investigations, updates, and follow-up work that compete with product delivery. These jobs are easy to defer one repository at a time and expensive to ignore across an enterprise. CAO lets a central team encode the outcome once and return reviewable results to repository teams instead of asking every team to adopt and operate another process. ## How CAO Scales [Section titled “How CAO Scales”](#how-cao-scales) Scaling CAO is not simply running many prompts in parallel. It means operating the same campaign safely across a large, changing repository fleet: * discover only repositories admitted by policy; * dispatch bounded workers with one target each; * keep credentials, modes, and output permissions explicit; * correlate activity, cost, outputs, and outcomes; * improve the campaign from evidence without silently expanding its authority. A campaign can start with one repository and retain the same control model as it grows to thousands. ## Run, Observe, Evolve [Section titled “Run, Observe, Evolve”](#run-observe-evolve) ``` flowchart LR outcome["Define an outcome"] run["Run
bounded agents"] observe["Observe
evidence · cost · value"] evolve["Evolve
campaigns and coverage"] approve["Human review
and approval"] outcome --> run --> observe --> evolve --> approve --> run ``` ### Run [Section titled “Run”](#run) A control repository owns campaign definitions, credentials, rollout policy, and workflow runs. It may be public only when its policy, run metadata, dashboard data, evidence, and review outputs can also be public. Orchestrators select eligible repositories within policy. Workers receive one dispatched target and only the tools and safe outputs declared by their workflow. ### Observe [Section titled “Observe”](#observe) CAO correlates orchestrator and worker activity with review items, operational evidence, cost, and measured value. Operators can see whether a campaign ran, what it produced, where it stopped, and whether the intended outcome occurred. ### Evolve [Section titled “Evolve”](#evolve) Evidence reveals recurring failures, missing capabilities, and campaigns that need refinement. CAO can recommend what to improve, adopt, or author next. Maintainers still review and approve workflow changes, campaign installation, and rollout. ## The Operating Boundary [Section titled “The Operating Boundary”](#the-operating-boundary) CAO separates four responsibilities: | Part | Responsibility | | ---------------------- | ----------------------------------------------------------------- | | **Catalog** | Publishes reusable campaigns | | **Control repository** | Owns policy, credentials, workflows, and runs | | **Orchestrator** | Selects and dispatches repositories within policy | | **Worker** | Handles one authorized repository and emits declared safe outputs | “Central” does not mean one global installation. An organization, enterprise, team, region, or trust boundary can operate its own control repository. Control is centralized within that boundary; execution is distributed across enrolled repositories. Credential reach never grants authority by itself. The effective boundary is the intersection of checked-in policy, the dispatch request, worker limits, credential reach, and compiled workflow capabilities. ## Review Before Live [Section titled “Review Before Live”](#review-before-live) Campaigns begin in `review` mode. In review, proposed outputs stay in the declared review destination and the target repository does not change. Operators can inspect the evidence, behavior, and cost before explicitly approving live output for a bounded scope. This makes CAO suitable for work that must be automated without making agent autonomy open-ended. ## One Operator Interface [Section titled “One Operator Interface”](#one-operator-interface) The installer adds a repository-local `./cao.sh` command. Operators use it to add and update campaigns, configure authentication, switch between preview and live policy, enable or disable campaign workflows, inspect runtime health, and query activity evidence. Workflow execution remains with gh-aw: use `gh aw run` to start a campaign and `gh run` to watch it. See [CAO Commands](/gh-aw-cao/cao-cli/) for the complete operator loop. ## Where to Go Next [Section titled “Where to Go Next”](#where-to-go-next) * [Set up the control plane](/gh-aw-cao/setup-quickstarts/) for the exact repositories it may need to reach. * [Learn the CAO commands](/gh-aw-cao/cao-cli/) for configuration, campaign control, and operational queries. * [Browse ready campaigns](/gh-aw-cao/catalog/) for an outcome you can install. * [Build a campaign](/gh-aw-cao/author-your-first-operation/) when your outcome is not in the catalog. * Read the [control plane overview](/gh-aw-cao/architecture/) for the detailed execution and safety architecture. # Set Up CAO > Create one control repository, install CAO, and follow the interactive setup. ## 1. Open the Control Repository [Section titled “1. Open the Control Repository”](#1-open-the-control-repository) Use a private repository unless every target and all future operational data may be public. You need GitHub CLI (`gh`), Git, Bash, `curl`, and Node.js 24 or newer. Use a GitHub CLI account that can access the control repository and the repositories you plan to enroll. If you are not signed in, run `gh auth login` (add `--hostname HOST` for a non-default GitHub host), then confirm your session: ```bash gh auth status ``` If you already have a **empty** local control-repository checkout, open a terminal at its root. Otherwise, clone an existing repository: ```bash gh repo clone OWNER/CONTROL_REPOSITORY cd CONTROL_REPOSITORY ``` Create one when needed: ```bash gh repo create OWNER/CONTROL_REPOSITORY --private --clone cd CONTROL_REPOSITORY ``` Replace uppercase placeholders with your values. `CONTROL_REPOSITORY` is the repository name without its owner in the `cd` command. ## 2. Install and Set Up [Section titled “2. Install and Set Up”](#2-install-and-set-up) ```bash curl --fail --silent --show-error --location \ https://raw.githubusercontent.com/githubnext/gh-aw-cao/main/install.sh | bash ./cao.sh setup ``` The setup command: 1. asks which repositories CAO should read; 2. checks their visibility and owners; 3. offers authentication choices based on that scope; verify each profile’s prerequisites in the [authentication profile guide](/gh-aw-cao/control-plane-authentication/); 4. shows the exact plan before changing policy, credentials, or Pages settings; 5. configures the control repository’s Pages source as GitHub Actions and, for a private repository, restricts the site to repository readers (requires Pages access control support and permission to manage Pages settings); 6. installs no campaign and runs no workflow. ## 3. Validate, Review, and Save [Section titled “3. Validate, Review, and Save”](#3-validate-review-and-save) ```bash ./cao.sh validate git diff --check git status --short ``` Validation checks the installed control plane; the expected result is a valid policy with the exact repository scope you selected. Setup installs no user-facing campaign and runs no workflow. Review the complete status and diff before committing. The following command stages every change under these paths, so use it only in a clean checkout. If you are reusing a repository with other work, stage only the setup files you reviewed. ```bash git add .github activity dashboard cao.sh git commit -m "Install Central Agentic Ops control plane" git push --set-upstream origin HEAD ``` ## Next: Add a Campaign [Section titled “Next: Add a Campaign”](#next-add-a-campaign) Choose and install the first operation as a separate change: ```bash ./cao.sh add githubnext/gh-aw-cao/CAMPAIGN ``` Replace `CAMPAIGN` with a campaign slug from [Browse campaigns](/gh-aw-cao/catalog/). Read the campaign guide before installing it. Adding a campaign installs its workflows but does not run them. For manual or non-interactive authentication, use the detailed [authentication guide](/gh-aw-cao/authentication/). # What Dependabot / Update Planner measures > Definitions, evidence rules, and interpretation for the Dependabot / Update Planner operational-value report. This page explains the operational-value timeline in plain language. It defines what was measured; it does not decide whether the workflow caused the observed changes. ## How to read the timeline [Section titled “How to read the timeline”](#how-to-read-the-timeline) * The purple dotted line marks workflow adoption on `2026-09-17`. * The left side is pre-adoption evidence; the right side is post-adoption evidence. * Each dot is one immutable observation. Missing evidence is omitted, never treated as zero. * Workflow runs show execution activity only. They do not prove repository value. ## What was measured [Section titled “What was measured”](#what-was-measured) ### Open security alerts [Section titled “Open security alerts”](#open-security-alerts) * **What it tells you:** Open security alerts. This is a `primary` measure. * **Native measurement formula:** `Dependabot security alerts open at the cutoff` * **Unit:** `alerts` * **Goal:** Lower values are better. * **Chart display:** The chart shows the native value directly on a metric-specific axis. ### Open critical/high alerts [Section titled “Open critical/high alerts”](#open-criticalhigh-alerts) * **What it tells you:** Open critical/high security alerts. This is a `diagnostic` measure. * **Native measurement formula:** `Dependabot security alerts with critical or high severity open at the cutoff` * **Unit:** `alerts` * **Goal:** Lower values are better. * **Chart display:** The chart shows the native value directly on a metric-specific axis. ### Open Dependabot pull requests [Section titled “Open Dependabot pull requests”](#open-dependabot-pull-requests) * **What it tells you:** Open Dependabot pull requests. This is a `diagnostic` measure. * **Native measurement formula:** `Dependabot-authored dependency pull requests open at the cutoff` * **Unit:** `pull-requests` * **Goal:** Lower values are better. * **Chart display:** The chart shows the native value directly on a metric-specific axis. ## Evidence rules [Section titled “Evidence rules”](#evidence-rules) * **Repository:** `githubnext/gh-aw-cao` * **Evidence population:** A Dependabot security alert in an authorized target repository that was open at the immutable observation cutoff. * **Collection:** Fetch Dependabot alert lifecycle records and Dependabot-authored pull-request lifecycle records once per supported repository, then reconstruct every requested cutoff locally from their authoritative timestamps. * **Observation window:** 7 days, sampled every 7 days * **Maturation delay:** 0 days * **Filters:** `Count alerts created no later than the cutoff and not fixed, dismissed, or auto-dismissed by that cutoff.`; `Count critical and high alerts separately without severity weighting.`; `Count Dependabot-authored pull requests created no later than the cutoff and not closed by that cutoff as a separate queue diagnostic.`; `Fail the observation closed when complete alert or pull-request lifecycle evidence is unavailable.` The same definitions and formulas are applied before and after adoption. The structured evidence, exact snapshots, provenance, units, and native values are recorded in the adjacent `dependabot-update-planner-timeline.json` artifact. ## Important limitation [Section titled “Important limitation”](#important-limitation) A before/after pattern is an association, not proof of causation. Other repository changes may explain some or all of the movement. Value-function SHA-256: `78540498a35c483cea4a7727ca961c3b2e0e94ca2c9604ff4b648064ad87ea34`