Skip to content

Knowledge base

Agentic continuous delivery

The delivery rules for agent-written changes and what each pipeline stage checks, for teams letting agents commit to a production codebase.

Written by

Updated:

Agentic Engineering 5

Our position. We wire the pipeline’s checks into the agent’s own hooks as well, because a pipeline answers only after the push (opens in a new tab). We treat green CI and a working deployed site as two different claims, so a factory needs a part that checks the live site against reality (opens in a new tab).

Once coding is fast, the constraint moves to the delivery infrastructure. Each pipeline stage then enforces one part of a per-change delivery contract, from pre-commit checks to canary rollback.

Which delivery rules apply to agent changes?

The continuous delivery community writes the constraints behind structural trust down as delivery rules. Its starting rule is that a change an agent generated has to clear at least the same quality bar as a human change, through the same pipeline. Once coding is fast, the constraint moves to coordination, the safety architecture and the delivery infrastructure. On top of the minimum CD practices it adds hard rules for agents: a human owns the intent before any change starts, and intent and architecture are versioned and deployed with the code as delivery artifacts. Intended behavior is specified apart from the implementation, and the pipeline checks that intent, tests, code and architecture agree. An agent never promotes its own change to production, and while the pipeline is red an agent may only produce changes that repair it (MinimumCD.org and DojoConsortium.org - Agentic Continuous Delivery (opens in a new tab), as of September 2026).

The same source orders the work: continuous integration, test fundamentals, build automation, small work items, infrastructure as code, a single deterministic path to production, and only then agents. Manual review is replaced step by step by expert validation agents, never all at once. The central artifact is a delivery contract per change that holds intent, behavior, constraints and acceptance criteria: a human drafts it, an agent critiques it, the human decides, and the agent refines and implements (MinimumCD.org and DojoConsortium.org - Agentic Continuous Delivery (opens in a new tab), as of September 2026).

What does each pipeline stage check?

The same guide makes each pipeline stage enforce one artifact of the delivery contract. Pre-commit gates catch the mechanical errors agents make most often: style, type mismatches and embedded secrets. The first CI stage runs the human-defined tests, so a failing test means the implementation is wrong however plausible it reads. Contract and schema tests hold the system constraints at integration boundaries, which agent code breaks often. Mutation testing, performance benchmarks and security integration tests find code that passes its tests but violates a non-functional requirement or leaves an edge case untested. Acceptance tests run the BDD scenarios in a production-like environment. Canary deployment and SLO monitors roll an agent change back automatically when production metrics degrade (MinimumCD.org and DojoConsortium.org - Pipeline Enforcement and Expert Agents (opens in a new tab), as of September 2026).

The reference architecture behind it names a pre-feature baseline of nine gates that pass on every commit before any feature work starts: linting and formatting, static types, secret scanning, SAST for injection patterns, the build, unit tests, contract tests at every integration boundary, dependency vulnerability scanning and schema migration validation. The stages carry time budgets: CI build and fast tests under 5 minutes, contract and boundary validation under 10, broader verification under 15, and acceptance tests under 20. A stage that overruns its budget delays integration and hides defects. Gates run cheapest and fastest first. Checks that depend on live systems, such as integration tests against real services, run after deployment and never block a commit. The architecture grows through three topologies: one team with one deployable, several teams feeding sub-pipelines into a thin integration pipeline for one deployable, and independent teams whose API contract verification replaces integration testing (MinimumCD.org and DojoConsortium.org - Pipeline Reference Architecture (opens in a new tab), as of September 2026).

Which agent, prompt and intent produced a change is recorded as provenance, described on Agent observability.

Resources

Delivery practice