A workflow that keeps documentation current or investigates a failing build can be a useful teammate. Once it works, the next question is tempting: what if we ran it across all our repositories? But who would maintain it, notice when it stopped helping, or decide whether another run was worth the cost?
Central Agentic Ops (CAO) is a GitHub Next research prototype exploring those questions. It brings workflow activity, costs, and available outcomes into one view, with controls for teams that want to operate shared workflows. The goal is useful work, at the right time, within limits people control.
Read the CAO documentation, explore the campaign catalog and public sample dashboard, or contribute at github.com/githubnext/gh-cao.
From an agent factory to many repositories
We arrived at this problem by using agentic workflows ourselves. In
Peli’s Agent Factory,
we built and operated more than 100 specialized workflows in github/gh-aw.
They triaged issues, investigated failures, improved tests, maintained
documentation, and even helped us understand other workflows.
As useful patterns emerged, we wanted them to help more repositories. Simply copying them everywhere would leave us with another maintenance problem: which copies were current, which had drifted, and who was responsible for them? We needed a way to maintain shared workflows without losing sight of what ran, what failed, and what was wasting effort.
The building blocks were taking shape in GitHub Agentic Workflows. Safe outputs let workflows request changes through declared, limited operations. They could delegate work to coding agents and refer to newly created items later in the same workflow run. Workflow markers, run audits, and correlation identifiers made the resulting work easier to trace. Patterns such as CentralRepoOps let shared workflows live in a central repository while the software they worked on stayed with its own team.
Our work on token efficiency made the need more tangible. Auditors exposed unused tools, blocked loops, and expensive runs. That raised broader questions: were several workflows repeating the same reads? Could shared evidence replace work each agent rediscovered? And were lower costs accompanied by useful results?
Background and event-triggered agents are already part of today’s development tools. CAO’s focus is operating the factory, not building another agent: maintaining shared workflows, seeing their combined costs and results, and using that evidence to guide what happens next.
A concept and an implementation
Continuous AI is our term for automated AI that supports software collaboration. Agentic Workflows are one way to implement it: instructions written in Markdown, run through GitHub Actions with declared tools, permissions, and outputs, using engines such as Copilot CLI, Claude Code, or Codex. CAO governs whether and where shared work may run; Agentic Workflows governs how it executes.
CAO is an operations layer, not an all-purpose agent. It builds on Agentic Workflows and GitHub Actions while preserving repository permissions, branch protections, and human review.
The open
specifications describe
the evidence and control boundaries of an agentic-workflow factory: a
collection of specialized workflows maintained and operated together.
githubnext/gh-cao is one opinionated implementation, not the only possible
architecture. Other implementations can explore the same contracts with
different infrastructure.
Run when the evidence calls for it
Scaling a factory should not mean keeping every agent busy. Two workflows can succeed while repeating the same investigation. A documentation check can run when nothing relevant changed; a failed task can retry before its missing prerequisite has been fixed.
CAO asks how evidence about outcomes, cost, reliability, and review effort can guide whether and when work runs. Monitoring can continue on a schedule without launching an agent for every observation. The research goal is a factory that selects useful tasks, skips duplicates, and waits when there is no reason to act.
One design proposal is to store shared facts once, use deterministic code to identify actionable changes, and call agents only for the judgment those changes need. That would make coordination less dependent on repeated scans and conversations between agents.
The current intelligence layer groups recurring failures into review-only recommendations.
The feedback loop closes through reviewed change. Agents can learn from evidence generated by live workflows: outcomes, failures, costs, and human feedback inform proposed improvements to instructions, tools, or campaigns. Reviewed updates guide subsequent runs, which produce new evidence.
This is operational learning, not automatic model retraining. Choosing and dispatching the most valuable interventions remains research; feedback does not grant agents broader authority.
Start small. Roll out with confidence.
CAO can grow with you; a complete factory is not a prerequisite. Imagine a team keeping documentation current across several repositories. It can describe that goal in natural language and use CAO’s agent skills to start with one reviewable operation.
Shared workflows, policy, and runs live in a control repository. The repositories being worked on are targets; their teams still decide which changes to accept. A small rollout might look like this:
- Observe what already runs. CAO’s Activity collector gathers a bounded, read-only snapshot from explicitly selected repositories. Monitoring does not move existing workflows or take control of them.
- Try one target in review mode. Define the task, repository scope,
credentials, and allowed outputs.
reviewis real execution: the agent runs, but proposed outputs go to the control repository—or another configured review destination—rather than the target. - Inspect the result before expanding. Was the proposed documentation change useful? What did it cost, and how much review did it need? If the evidence supports proceeding, explicitly authorize live outputs to the target. Creating a pull request is still not the same as accepting it.
One bounded run may be enough. An agentic campaign packages a repeatable goal with an orchestrator and separate workers when targets need independent execution or retries. The operating-pattern guide explains when to use each structure, including ordinary Actions for deterministic work. The catalog offers examples of repository assistance, dependency maintenance, and architecture review; installing one does not authorize it to run.
Focus attention, not just activity
Human attention is scarce. The dashboard should focus it on what needs judgment next, not every run. We want a mobile-first view for the agentic engineer: quick check-ins, then deeper investigation.
People and agents share the same operating plane: named queries serve both dashboard views and agent APIs. Dashboard Language lets you shape views around your team’s questions. The local Copilot canvas supports generating, previewing, and saving custom views. These stay workspace-local and grant no execution authority.
A completed run, a proposed change, a maintainer’s acceptance, and a lasting improvement are different things. A workflow might open many pull requests while creating more review work than it saves. Cost and reliability therefore belong beside accepted outcomes and review effort, not in place of them.
The value specification defines success before measurement and counts outcomes equally, whether achieved by people or agents.
These are snapshots, not a live feed. Results may be stale, partial, or unavailable; missing evidence must not look like a healthy zero.
Keep control with the team
We favor explicit processes over bigger swarms. Policy is reviewed alongside the workflow version and checked before invoking the agent. Each run must fit its policy, request, credentials, tools, and safe outputs. Missing authority, access, or required evidence blocks execution.
Campaign workers handle one assigned target. They cannot discover extra targets, dispatch more workers, or promote themselves to live mode. Writes use declared safe outputs, not unrestricted access.
Workflow versions, policy, runs, and proposals leave an audit trail. Shared updates still need review of version changes and local customizations. CAO governs explicitly integrated workflows, not every job it observes; these limits reduce risk rather than eliminate it.
From individual maintainers to enterprises
You do not need to start with an enterprise-wide platform. The setup paths cover different levels of access:
- No additional App or PAT. Monitor the control repository and explicitly
selected public repositories with the built-in Actions
GITHUB_TOKEN. Authenticated setup still needs control-repository settings access; this path does not grant cross-repository writes. - Fine-grained PATs. Where suitable Apps are unavailable, use eligible, approved tokens scoped to each resource owner, subject to API limits, expiration, and rotation.
- Organization Apps. Use approved private Apps with separate read and safe-output write access. Repository administrators can extend approved installations where organization policy permits.
- Enterprise Apps. Across organizations in one enterprise, use approved enterprise-owned private Apps with selected-repository installations in each organization. Enterprise ownership alone grants no access.
Pages, secrets, and App setup may require administrator help beyond repository write access.
Choose the stack you need
Hosting is independent of credentials. Start with GitHub Actions and Pages: browser-side queries, no external server, database, or cloud account. Normal GitHub plan limits apply. Or bring your own Go server and PostgreSQL on a compatible container platform; see the deployment guide.
Add only what you need. The optional Webhook Gateway connects Jira, Linear, and Azure DevOps events to approved GitHub workflows, with authentication, reviewed scope, and fresh access checks. OpenTelemetry, private archives, and deeper analytics are optional too. The storyboards show possible combinations, not a mandatory stack.
The Azure profile uses Functions, PostgreSQL Flexible Server, and Key Vault. ADX is a separate, optional paid destination. The native deployment command supports fresh development deployments only; the guide covers supporting services, costs, and exporter requirements.
Whatever the stack, verify dashboard visibility before publishing private evidence: a private repository does not automatically make Pages private.
Toward factories that learn
A workflow run is an accounting unit, but not always the right unit of learning. We want to connect episodes of work to their original intent, context, actions, and independently assessed outcomes, including work that spans runs or campaigns.
With approved data use and reliable outcome labels, these episodes could support reusable evaluations and RL research. Campaign definitions, evaluation methods, and lessons could be shared across the Agentic Workflows community without publishing private traces.
What transfers across domains: successful strategies, objective functions, or ways to measure effectiveness? Those patterns might help connect technical evidence to resource allocation, project roadmaps, and ROI. At hyperscale, the aim is to grow useful work without overwhelming human attention. Domain-specific goals and causal evidence still matter: these are research questions, not a shipped training system or universal measure of business value.
CAO is still an early research prototype. As we did with Agentic Workflows, we are shaping it quickly in the open: its specifications, terminology, interfaces, and operating patterns will change as we learn. We want to understand not just how much work agents can do, but which work is worth doing.