Compared with ci/cd
CI/CD assumes the steps are known in advance. Operational AI work does not.
GitHub Actions, GitLab CI and Jenkins are the right home for builds, tests and deployments: a repository event arrives, a declared sequence runs, an artifact and a status come out. Cross-system operational work has a different shape, and stretching a pipeline file to cover it produces something fragile.
What it does well
Where ci/cd is the right tool.
Worth stating plainly first. A comparison that only lists gaps is marketing, and it will not survive contact with the engineers who chose the tool.
Repository automation is a solved problem
Build, test, package and deploy on a repository event, with caching, matrix execution and status reporting. Decades of convention sit behind this and the teams who own it have earned their tooling.
The definition is already in Git
Pipeline files are reviewed, versioned and promoted like any other code. This is the part CI/CD got right long before anyone else, and it is worth preserving rather than replacing.
Determinism is a feature
The same inputs producing the same outputs is exactly what you want from a release pipeline. It is also precisely why the model strains when the next step depends on what the previous step found.
Capability comparison
Head to head on the operating model.
The same capabilities the full comparison uses, narrowed to this category. What matters is which controls are native to the system and which your team must design, host and audit around it.
| Capability | CI/CDActions, GitLab CI, Jenkins | NopsAI |
|---|---|---|
| GitOps-owned platform configurationOperational definitions need review, promotion, rollback and drift evidence across environments. | Partial Strong for pipeline files | Core Built into the platform model |
| Caller-scoped AAA before dispatchStarting a run and using each referenced runtime resource are separate authorization decisions. | Partial Repository and environment controls | Core Product and runtime checks |
| Scripts and goal-based steps in one DAGTeams need deterministic checks and LLM-assisted reasoning inside the same dependency graph. | Partial Scripts are the primary model | Core One pipeline definition |
| Approved LLM and MCP profilesProvider, credential, scope, model, tool and timeout choices should be centrally governable. | External Custom integration required | Core System registry and scopes |
| Docker and Kubernetes runner placementSensitive work needs eligible execution locations selected by scope, affinity, capacity and state. | Partial Runner model varies by system | Core Dispatcher-managed runners |
| Knowledge and secret resolutionA run needs governed context assembled before execution without embedding secrets in definitions. | Partial Secrets and artifacts | Core Scopes, knowledge, secret references |
| Human approval inside the run graphA run must pause for a named approver and resume from persisted state without holding a runner. | Partial Environment approvals | Core Approval step with durable resume |
| Durable run evidenceOperators need the trigger, policy decisions, context, logs, outputs and final state in one record. | Partial Build and deployment history | Core Run-owned evidence model |
| Proposal-first AI changesGenerated pipeline, trigger and schedule changes should return to explicit review rather than mutate production silently. | External Custom review workflow | Core Read and proposal-only assistant tools |
Category comparisons describe common design centers, not every implementation or product edition. See all three categories side by side.
Where it stops
The questions that arrive after the prototype works.
None of these are criticisms of the category. They are the problems it was not built to solve, which is a different thing.
Authorization is repository-scoped, not caller-scoped
CI/CD authorizes the repository and the environment. It does not resolve whether the specific human or service that initiated this run is permitted to use each downstream resource the run will touch — a separate decision that has to happen before dispatch, not at merge time.
There is no model for approved AI access
Which models may be called, which tools they may reach, with which credentials and under which timeouts, is configuration that wants to be resolved centrally and referenced by name. In CI/CD it becomes environment variables and per-job wiring that drifts between repositories.
Operational context has nowhere to live
A runbook, an architecture decision record and a policy document are inputs to a reasoning step. CI/CD has no concept of governed context because it never needed one, so retrieval becomes a bespoke step in every job.
Approval gates are environment gates
Deployment approvals protect an environment transition. They are not a general primitive for pausing mid-run at an arbitrary point, naming a permitted approver, releasing the runner and resuming from persisted state.
The record is per-repository
Build history answers what happened in this repository. Cross-system operational work needs the trigger, the policy decisions, the resolved context, the tool calls and the outcome in one record that is not scoped to whichever repository happened to host the job.
Using both
Composition beats replacement.
Replacing a system your team already knows is rarely the honest recommendation. The useful question is where the boundary between them belongs.
Nothing here argues for replacing CI/CD
Builds, tests and deployments belong exactly where they are. Moving them would trade a mature, well-understood system for a novel one and gain nothing.
Compose at the event boundary
A Git event starts a governed run, the run performs the cross-system work CI/CD was never designed for, and status flows back as a check run. Each system does the job it is good at, and the seam between them is an ordinary integration.
Common questions
What teams ask in evaluation.
Why not just add AI steps to our existing pipelines?
Many teams start there and it works for a single workflow. It stops scaling when the second and third pipeline need the same model access, the same tool allowlist and the same credential, configured again per repository. At that point the configuration wants to be a central registry referenced by name rather than copied per job.
Do we have to move our builds?
No. The productive pattern is composition, not migration: a repository event starts a governed run, and the run reports status back as a check run. Builds, tests and deployments stay in CI/CD.
What actually needs the different model?
Work that crosses systems and where the next step depends on what the last step found — incident investigation, release readiness assessment, security finding triage. Pick one that already touches three systems and ask who authorized the last execution, which tools it could call and where the approval is recorded. If that takes more than one link to answer, the gap is structural.
Map what your current tools own — and where the governed run boundary is still missing.
Bring your architecture. We will walk the four boundaries with you: reviewed intent, runtime decision, isolated execution and provable outcome.