Main site

Engineering AI agent · Deployment

CI/CD & Deployment AI Agent

Attest to what the build actually did — which sources, which components, which environment — bind that evidence to the artefact, and hold the promotion for the named engineer who releases it.

Typical delivery
4–6 weeks
Deployment
Your stack
Named releaser
Build evidence
After launch
Agent Care

What this agent does

Evidences the build, never the release

In

  1. 01

    A build completes, and the sources, the toolchain and the environment it ran in are written beside it.

  2. 02

    A bill of materials is drawn up as the build runs, machine-readable, and bound to the artefact.

Reason

  1. 03

    An artefact is promoted, and the build that produced it travels with it into the environment receiving it.

  2. 04

    A promotion enters a regulated environment, and the change plan it must stay inside is checked first.

  3. 05

    A release branch turns five years old, and a security-only patch is cut on it without the features after.

Decide

  1. 06

    A shipped component is reported as exploited, and the builds and versions carrying it are listed.

  2. 07

    A deployment record is written by the pipeline, not the actor, so the deploying account cannot edit it.

Out

  1. 08

    A promotion is prepared, and it waits on the named engineer whose name goes on the release record.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Building, evidencing and promoting belong to the agent. Release belongs to a named engineer, who owns the artefact in production and answers for it after it is there.

Example workflow

One artefact, commit to production

  1. 1Build triggeredSource repository, tag, pull request or scheduled build trigger
  2. 2Build evidence assembledThe commit, the toolchain, the components, the target environment and the build identifier
  3. 3Artefact produced and boundThe artefact digest, the machine-readable bill of materials, the build record and confidence
  4. 4Controls appliedProvenance checks, component checks, environment checks, change-envelope checks and confidence

No human action required

Stages 1 to 4 run unaided, and nothing reaches production at any of them — the agent is building, and the engineer lane opens at the promotion gate.

5DecisionSplits at the promotion gate
Evidence complete

Goes to the named engineer to release.

Anything missing

Adds a platform owner read first.

Engineer release

The artefact is held with its build record, its bill of materials and what the controls returned.

Release · Rebuild · Send to platform review

Released — by the named engineer

  1. 6Deployment and registry records updatedOnly where write access and release policy allow it
  2. 7Outcome evaluatedProvenance completeness, rollback events, engineer corrections and what production found after release

Corrections

Each engineer correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Releasing an artefact into production.
    • Signing any attestation about how software was built.
    • Judging whether a device change needs a new submission.
    • Declaring a product free of known exploitable flaws.

  • Automation boundary

    Agent acts unaided

    • ✓Draw up the bill of materials while the build runs.
    • ✓Bind the artefact digest, its components and the build record together.
    • ✓Check each promotion against the change envelope held on record.
    • ✓Hold the artefact for the engineer who releases it.

    Nothing reaches production except by a named engineer, inside the agreed boundaries.

    • Notifying a regulator that a deployment went wrong.
    • Granting the deploy credential or the release role.
    • Choosing which release branch a customer is supported on.
  • Changes to pipeline rules or promotion thresholds.

Example output

One artefact, annotated

A workflow agent sequences a business process across systems; this one moves an artefact from a build machine into production. Below is one artefact as the agent leaves it.

Build output · single artefact

Illustrative example
Artefact
Payments service, release branch
Recorded as
Promoted from the build that made it
Environment
Digest, bound
Evidence of record
Build record, 3 August 2026
Confidence
Held unreleased
Held for
The named engineer, by name

As received

Taken from the build system and the registry — the agent vouches for where this came from, not for the code inside it.

What the record holds

  • Source commit
  • Component inventory
  • Artefact digest

Why no release here

Promoting an artefact into production is an act a named engineer owns.

What the score decides

Below the configured threshold an artefact gets a platform read before the engineer sees it.

Action

ReleaseRebuildSend to platform review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each artefact

From the build that produced it

03Evidence

Where the evidence is used

No statute separates the developer from the deployer; that separation is an auditor testing convention, and the record is what lets it be met or argued.

01Approved path

The pipeline is the claim

The federal attestation a named executive once signed for how software was built was rescinded in January 2026, so anyone selling compliance with it is selling a rescinded memo.

02Human review

What was checked, and not found

No law of general application consulted requires a test to pass before a deployment, a staging environment to exist, a second person to review the code, or a rollback to be possible. The duties that do exist are European and dated: reporting from 11 September 2026, the rest from 11 December 2027.

04

Build an evidence trail

The build, the artefact it produced and the person who released it stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Build and CI systems

    • GitHub Actions
    • GitLab CI/CD
    • Jenkins
    • Buildkite
    • Tekton

  • Registries and artefacts

    • OCI registries
    • Artifactory
    • npm
    • Maven
    • PyPI mirrors

  • Runtime and delivery

    • Kubernetes
    • Amazon ECS
    • Nomad
    • Argo CD
    • Flux
    • Spinnaker
    • Helm

Agent

CI/CD and deployment

  • Reads the build
  • Binds the evidence
  • Holds the promotion

  • Change and evidence systems

    • Jira
    • ServiceNow change records
    • SBOM stores
    • signing services

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six locks between the build and production

Six locks down one staircase, the last the deepest. What descends is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to build evidence only when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and pipeline rules, and note the version each build was produced under.Track
L4TraceabilityRecord each build, the components under it, the artefact it produced and every read of the record.Record
L3Engineer releaseHold the artefact for a named engineer; the hold governs promotion, not whether the artefact is sound.Gate
L2Provenance guardrailsTest each artefact against its recorded build, and refuse a promotion whose evidence is absent or does not match.Restrict
L1Confidence thresholdsRoute a thin or unmatched build to a platform owner read before the artefact reaches an engineer.Require review
Model coreArtefact built — the commit, the components, the digest and the target environment
L1 – L2
Test whether a promotion may stand
L3
Leaves the release to a named engineer
L4 – L5
Keep the release and the build behind it
L6
Holds the promotion when signals degrade

How Nestack evaluates it

Evaluate the whole pipeline — not only the artefact that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the artefact production runs

  1. E1Final-output evaluationDid the artefact carry the build record it was actually produced from?
  2. E2Step-level evaluationDid the agent read the right commit, the right components and the live pipeline rules?
  3. E3Tool evaluationDid it read and write the correct registry and the correct environment?
  4. E4Confidence calibrationDo low-confidence promotions actually attract more engineer corrections?
  5. E5Slice evaluationHow does performance change across specific environment classes?
  6. E6Business outcomeHow many promotions needed a correction before the engineer released?

Floor — the estate a release lands in

Failure modes

Where each failure originates in the agent

Seven failure modes, each set at the stage where it first surfaces.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • QU-03

      Stale build input read

      The component read is not the one in the artefact.

    Stage gathers

    The commit, the components, the toolchain and the target

  2. 02 · Reasoning

    2 modes

    • QU-04

      Promotion asserted, not evidenced

      An artefact moves with no build record behind it.

    • QU-06

      Retired pipeline rule read as live

      A superseded promotion rule is worked as current.

    Stage proposes

    The digest, the components and the environment

  3. 03 · Tool / write

    2 modes

    • QU-02

      Thin promotion passed forward

      An artefact moves on without the platform read.

    • QU-05

      Artefact bound to wrong environment

      The build is promoted into another target.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • QU-01

      Released, build unrecorded

      The record shows a release but not the build under it.

    Stage returns

    The artefact production runs and a customer already has

  5. 05 · Change / Version

    1 mode

    • QU-07

      Silent pipeline drift

      A promotion rule loosens while the stored record keeps the old one.

    Stage tracks

    Model, prompt, pipeline rules and environment config

  • Sev-1 · an artefact released on no evidence
  • Sev-2 · a wrong build reaches production
  • Sev-3 · evidence degrades, promotion held
See the complete Engineering failure-mode catalogue

Affected slices

Regulated estates absorb the corrections

An environment-level provenance figure can read clean while regulated production estates carry most of the held promotions. Nestack reports the correction rate by environment, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Regulated production estates12.8%3.7×Review
Long-lived release branches9.1%2.6×Review
Newly onboarded environments5.7%1.6×Watch
Routine service deployments2.4%0.7×Normal

Bar: correction-rate lift vs. routine-deployment baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What a green tick did not say

A loop closes when the artefact promoted without provenance is a standing case. That suite is what the next release cut is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Held-promotion rate rises on regulated estates.

  2. 02

    Diagnose

    The artefact that reached production on a Friday with nothing behind it but a green tick is read back through the pipeline until a single cause remains.

  3. 03

    Improve

    Number the change; the builds that drove it are filed beneath it.

  4. 04

    Verify

    A single red build case stops the whole promotion.

  5. 05

    Learn

    One case joins the suite, one line joins the pipeline rules.

  6. Learn → Detect

    The return edge. The next release is cut against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, promotion workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Release discovery and automation-boundary definition.Week 1
  2. 02Build, registry and runtime sources.Week 1, Week 2
  3. 03Component-inventory and change-envelope rule mapping.Week 1, Week 2
  4. 04Build-record ingestion.Week 2
  5. 05Provenance binding and promotion logic.Week 2, Week 3
  6. 06Confidence scoring and review routing.Week 3
  7. 07Engineer release workflow.Week 3, Week 4
  8. 08Registry and runtime integration.Week 5
  9. 09Build and promotion cases.Week 4, Week 5
  10. 10Guardrails and release controls.Week 4
  11. 11Build-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne pipeline, one environmentProductionProduction release trainAdvancedMultiple pipelines / estates
Introduced at Pilot
Build evidence to your pipeline rules✓✓✓
Named engineer release✓✓✓
Pipeline-inventory baseline✓✓✓
Introduced at Production
Reporting by environment class—✓✓
Platform review workflow in your systems—✓✓
Approved promotion write-back—✓✓
Registry-and-runner integration—✓✓
Introduced at Advanced
Multi-registry provenance——✓
Cross-environment release packs——✓
High promotion volume——✓
Multi-environment promotion controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, promotion volume, release controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your live pipelines and the environments each one promotes into

    Pipeline capture and promotion-rule versioning

    Week 1

  2. 02Representative builds, registries and deployment records

    Source binding, provenance logic and the build baseline

    Week 2

  3. 03Your deployment window and the engineers it names

    Provenance mapping, component binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Build, registry and runtime assessment, then integration setup

    Week 2

  5. 05Releases you would not want attested

    Promotion cases and the failure-mode round

    Week 4

  6. 06What no pipeline may attest

    Confidence scoring, review routing, guardrails and release controls

    Week 3

  7. 07A named engineer who releases the artefact

    Deployment approval workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Two of these phases really do share week five, and no band was widened to make the column look neat.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Release-workflow discovery, promotion rules and the automation boundary

W2Build and registry integration and the pipeline-inventory baseline

W3Provenance binding, promotion logic and release controls

W4Evaluation suite, promotion cases and failure-mode testing

W5Runtime integration, pilot promotions and targeted corrections

W6One release train run under the platform owner, then Agent Care handover

Reading the band
A bar spans the weeks its work is named in and no others; the fifth week is genuinely doubled.
At the end of W6
When the build record validates, Agent Care picks the agent up.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Engineering AI agent

Build a CI/CD agent around the evidence your last release never carried.

Show us one service you deploy weekly and the record behind its last release. What was attested there was that the configured checks ran and returned, not that the artefact was sound. An artefact that cannot say where it came from comes back as a finding.

Typical delivery
4–6 weeks
Deployment
Your pipelines
Named releaser
Build evidence
After launch
Agent Care available

Nestack Agents · CI/CD and deployment

AGT-ENG-03 · Agent Care available after launch

Build a CI/CD agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your pipelines

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.