Central Agentic Ops

Warning

This project is experimental and not ready for use.

Run GitHub Agentic Workflows across an enterprise from private central control planes. An enterprise control repository runs enterprise-shared AWs against configured repositories across organizations. Organization control repositories can run additional organization-shared AWs against their own downstream repositories, while repositories can still run workflows specific to themselves.

What You Get

• One control point: shared authentication and safety policy for every installed bundle.
• Gradual rollout: every bundle starts in preview, can move through private review, and reaches live independently.
• Controlled writes: GitHub tools are read-only; workers can write only through declared safe outputs.
• Bounded execution: orchestrators choose repositories, while each worker receives one target and cannot promote its own mode.
• Traceable runs: worker outputs link back to the originating control-plane run.

Enterprise Deployment

Each workflow runs from the central repository that owns its policy and rollout:

Workflow scope	How it runs
Enterprise-shared AW	Runs in an enterprise-operated central control repository and dispatches per-repository workers against configured targets across organizations.
Organization-shared AW	Runs in an organization-operated central control repository and dispatches per-repository workers against configured targets in that organization.
Repository-local AW	Runs in the repository that owns it and is outside this control plane unless explicitly enrolled.

The orchestrator and worker definitions stay in their central control repository. A worker checks out one target repository and sends declared safe outputs, such as an issue or pull request, to the configured destination. Target repositories do not receive installed copies of the enterprise-shared or organization-shared workflows.

An enterprise control repository and an organization control repository may both target the same downstream repository. Each source keeps its own credentials, rollout mode, review destination, correlation data, and safe-output limits.

Control Boundary

Central Agentic Ops governs workflows run through its central control repositories. It does not prevent people, repositories, or other automation from creating or running workflows outside the catalog, and it does not make the control plane the only path for GitHub Actions execution.

Enterprises that require mandatory enforcement must pair it with GitHub-native controls such as Actions policies, repository rulesets, protected environments, required reviews for workflow changes, least-privilege App installations, and restricted administration. See What This Does Not Do.

How It Works

1. Install the full catalog or one bundle into a private control-plane repository.
2. Authenticate with a GitHub App (preferred), a fine-grained PAT, or both.
3. Validate against one repository in preview, then route proposals to a private repository in review.
4. Promote only the proven bundle to live; other bundles keep their own modes.

Mode	Effect
preview	Stage outputs without mutating the target
review	Route proposals to an explicit private review repository
live	Allow declared worker safe outputs to update the selected target

Quick Start

1. Install the GitHub CLI, authenticate, and install gh aw:

   gh auth login
   gh extension install github/gh-aw

2. Create a new private repository for the control plane, clone it, and run gh aw init in the clone. For enterprise scope, create it in the designated organization that hosts the enterprise control repository.

3. Install the full catalog. Replace <catalog-release> with an exact release tag:

   gh aw add-wizard githubnext/central-agentic-ops@<catalog-release>

   Install a single capability as follows:

   gh aw add-wizard githubnext/central-agentic-ops/dependabot@<catalog-release>
   gh aw add-wizard githubnext/central-agentic-ops/optimization@<catalog-release>

The installer prompts for authentication and leaves every bundle in preview. Use a GitHub App through GH_AW_GITHUB_APP_ID and GH_AW_GITHUB_APP_PRIVATE_KEY (preferred), or a fine-grained PAT through GH_AW_GITHUB_TOKEN. When both are configured, App tokens take precedence.

Control Plan

Start with the control plan, or go directly to:

• Install and operate
• Configure variables, secrets, and run inputs
• Configure authentication
• Promote or roll back a bundle
• Understand the architecture
• Add an orchestrator or worker