Build reproducibly
Stays, and matters moreToday: Turn a commit into an artefact the same way every time.
With agents: Matters more. The thing tested must be the thing that runs, whoever wrote it.
The methodPosition paper
Agent Pipelines
Do we still need pipelines when agents do the work?
For twenty years the pipeline was where software quality was enforced. When AI agents write the change, open the pull request and propose the release, most of what a pipeline was for is already being done. It is tempting to conclude that CI/CD is diminished. In one sense it is. In the sense that matters, it is not.
The pipeline had two jobs: to orchestrate the work, and to be the place where an independent, deterministic check said whether the work was fit to move. Agents remove the need for the first and multiply the need for the second. The question is not whether you still need a pipeline. It is where the independent check lives, what evidence it leaves, and who can prove it happened.
Five jobs, two fates
Strip the tooling away and a pipeline does five things. Only one of them is about how work gets done. The other four are about whether work may move — and those grow in importance when the author is an agent.
Verify deterministically
Stays, and matters moreToday: Tests, static analysis, dependency and infrastructure scans.
With agents: Matters more. Nothing an agent says is a proof; every claim needs a check that cannot be talked out of it.
Gate
Moves off the pipelineToday: Refuse to move the artefact until the checks pass and a person approves.
With agents: Moves to the artefact. Readiness is checked before work starts, done-ness against the change, release readiness against the release.
Record
Moves off the pipelineToday: Keep the logs, the versions and the approvals for the auditor.
With agents: Becomes structured. A pass/fail per run gives way to claims, each with evidence, pinned to the content it judged.
Orchestrate
Moves off the pipelineToday: The YAML, the runners, the flaky step, the person who knows why the deploy job needs a flag.
With agents: Shrinks. Agents propose and maintain the workflow files; people approve them.
What changes when agents do the work
Each of these argues for more independent verification and better records, not fewer — and for verification that is attached to the artefact and enforced by the system, not a script somebody remembers to run.
Volume
A studio of agents opens more pull requests in a day than a team did in a sprint. Any control that needs a person to read every change becomes a queue.
Provenance
A change is the output of a model, a prompt, a context bundle, a set of tools and a repository state. "Who wrote this?" has a longer answer than a git author.
Non-determinism
Ask twice and get two plausible answers. A review that passed once cannot be assumed to pass after a regeneration.
Speed of the loop
A reviewer's finding is read and acted on in minutes. A finding that was wrong propagates just as fast.
The approver is the bottleneck
The author was the scarce resource; now the approver is. Whatever an approver must do per change has to be small and well-evidenced.
Text is an attack surface
An agent reads the repository, the issue and the comments. A pipeline never worried that a README could tell it to skip the tests.
Predictability without determinism
You cannot make a language model deterministic. You can make the system behave the same way twice: the same gates apply, the same evidence is required, the same people decide, the same record is left. Four properties give that.
| Property | What it means | In the Studio today |
|---|---|---|
| Bounded | Every agent step has a scope, a cost and a deadline it cannot exceed. | Runs carry turn, cost and time budgets; an agent may only write to allowed paths, and CI and executable configuration are denied. |
| Observable | Every step leaves a record a person can read and a machine can check. | Gate reviews hold per-item evidence; an append-only evidence ledger indexes it per artefact; an execution ledger records model, prompt version and cost; the audit table is append-only. |
| Attributable | Every decision names a person or an agent, and every agent action names the person who asked. | Evidence records who recorded it and who triggered it; reviewer roles are ids the server resolves, never job titles. |
| Reversible | A transition can be reopened and re-decided, and what shipped can be rolled back to. | Verdict history is append-only; reopening a release clears both keys; a pull request head that moved refuses release until approved again. |
Two principles turn these into controls rather than conventions. Fail closed: a rule that cannot be evaluated refuses. Server-owned guardrails: an agent's persona may be the customer's, but the task, the guardrails and the output contract come after it and always win, and anything read from a repository, a board or a comment is treated as data, never instruction.
Controls at the artefact: what the Studio does today
The AI Product Studio puts the gates on the work, not on the pipeline, and keeps the evidence with the artefact. Each of these is shipped; the route is where it lives.
Two-sided gates on real transitions
A work package is approved and dispatched only when its Definition of Ready has passed, and completed only when its Definition of Done has. Each item names an agent, a human role, or both; neither side stands in for the other.
/studio/work-packagesEvidence pinned to what it judged
An assessment records the package content hash and, when it read the code, the pull request head. Either moving makes the evidence stale and the transition refuses.
/studio/work-packagesServer-minted agent verdicts
The gate runs the reviewer agents itself from a server-owned prompt. A client cannot post an agent's approval or choose which agent answers.
/studio/work-packagesThe merge hold
A commit status follows the Definition of Done gate. Branch protection can require it, so the pipeline enforces the gate's decision without deciding anything itself.
/studio/repositoriesRelease readiness, re-checked
A release is approved with two keys and, for AI-built work, an approved DPIA snapshotted at approval. What ships is what was approved: a moved head refuses the release.
/studio/releaseTrust as a dial
Supervised or Semi-Autonomous, chosen by the owner. Separation of duties is a setting, off by default, so one developer is never blocked and a team can turn it on.
/studio/trust-settingsPipelines described and proposed
The DevOps panel reads a repository's pipelines and draws them; it proposes build, test, scan and deploy workflows for each part it finds, opened as a pull request the owner merges.
/studio/repositoriesAn audit the role cannot edit
Every create, update and delete lands in a dedicated audit table with field-level diffs, and the application role is denied update and delete on it.
/studio/auditAn evidence ledger per artefact
Every assessment, decision, exception, release approval, CI result and coding run is recorded in an append-only ledger for its work package or release, in the same request as the event. Entries are chained by hash, and the application role cannot update or delete them.
/studio/work-packagesThe Artefact Passport
A Passport tab on every work package, and a passport on every approved release: gates, both sides, the evidence behind each, exceptions, provenance and CI at the assessed head. It says whether the chain is intact and names what it does not know. It downloads as JSON.
/studio/work-packagesControls on checklist items
A Definition of Ready or Done item names the controls it is evidence for — ISO 27001, SOC 2, NIST SSDF, SLSA or your own. The passport derives each control's status from the items citing it, and never shows one as satisfied without evidence in the ledger.
/studio/settings/work-package-checklistsExceptions that expire
A waived item and an override of the reviewer agents are one record: who granted it, under which authority, why, and until when. Expired or voided, the item is unmet; a material change voids it. On a studio's own items an expiry is optional, so one developer is never blocked.
/studio/work-packagesSigned passports
Approving a release issues its passport: the evidence record frozen at that moment and signed with the platform's key. Each issue is a new version and none is ever rewritten. An owner or admin can issue one on demand, for a release or a work package — a lone owner does it alone.
/studio/releaseChecked with a public key alone
The public keys are published, so an auditor checks a signed passport offline — with a small script, the verification endpoint or standard in-toto tooling — without access to the Studio. A good signature on a passport that records something unmet says so; it is never shown as clean.
/studio/releaseEvery agent named in the evidence
Evidence an agent recorded carries one form of identity: the studio, then the agent's roster id or its role. For each pull request head the Studio itself published, a passport's provenance names the agent whose work it is and the GitHub account the commit was made as; for every run it names the account GitHub gives as the author of the pull request. A head a cloud agent or a person pushed is recorded as seen, with no agent credited. Where one of these was not recorded the passport says so; it is never inferred.
/studio/work-packagesDeployment reports
A deployment pipeline reports where a release went — environment, commit, workflow run, time, and any rollback — with a deploy token that can read that repository's release passports and report its deployments, and nothing else. The Studio refuses a commit the release's signed passport does not cover, and records each report as evidence.
/studio/repositoriesA passport check before every deploy
In a GitHub Actions pipeline the Studio generates, every deploy waits for a job that finds the release for the commit, fetches its signed passport and verifies it on the runner with the published keys — the verifier is written into the workflow and pinned by its hash. The studio owner chooses, for each environment, whether a check that does not pass holds the deploy or only warns; the proposal holds production and warns in dev. A pipeline written by hand is not held until it carries the same check. For each deploy job it finds, the Studio says whether the check is the one it generates and holds the deploy, only warns, has been changed, or is missing — and says so when it could not read a pipeline file. It finds a deploy by the job's environment, its name, or its waiting for the check; a deploy done by any other job is not seen, and a job that calls a workflow in another repository is listed as one the Studio cannot read.
/studio/repositoriesThe lifecycle these controls guard is the AI Delivery Lifecycle; the Studio itself is described on the AI Product Studio page.
Guardrails set once, at the organisation
A governed, compliant CI/CD practice expects guardrails set centrally and enforced in every project. An Enterprise organisation sets a guardrail policy in the Organisation Hub; every linked studio enforces it and may tighten it, never loosen it. A studio with no organisation keeps its own checklists, its evidence ledger, its passports and its exceptions.
Set once, at the organisation
A guardrail policy says what every linked studio must check and who must decide it, in the Studio's own vocabulary of Ready and Done items with agent and human sides. Activating it freezes a version, and every passport names the version it was judged against.
/organisation/guardrailsTighten, never loosen
Organisation items come first in every new work package, locked. A studio may add its own items and, where the policy allows, add a reviewer or a control to an organisation item; it may not remove or weaken one. A work package keeps the version it was born under.
/organisation/guardrailsOrganisation reviewer roles
A policy names the organisation's own reviewer roles, and each studio says which of its roles answers for each. An organisation can require a named role, so that "any human in the loop" does not count for it.
/organisation/guardrailsRelease rules
A policy can require CI to have passed at the approved head, a software bill of materials for each package's delivered commit, and name the roles a release approver must hold. A release takes the strictest rules among its work packages.
/organisation/guardrailsSampled review after the fact
A policy can name a share of completed work packages and a reviewer role. The server picks them when each completes; a member of that role records what they found, as evidence. It never blocks: a pending sample or a concern is shown on the passport, the release and the organisation's list, and stops nothing.
/organisation/assuranceLegal hold and declared retention
A hold on a work package or a release refuses every deletion that would destroy or orphan its records. The organisation declares the minimum time it keeps evidence for. That is a declaration: nothing deletes evidence, with or without one.
/organisation/assuranceOne register of exceptions
Every waived item and every override across the organisation's studios — in force, expired or voided — with who granted it, under which authority and why. The policy sets whether exceptions are allowed, how long an item may stay under exception in all, and who may grant one.
/organisation/exceptionsSolo developer first
A studio without an organisation behaves exactly as it did. Nothing needs two people unless a studio or an organisation chooses it; where one person decided both sides, the Go dialog and the passport say so.
/studio/trust-settingsAvailable now Guardrail policies and the exceptions register are for Enterprise organisations. The evidence ledger, the passport, controls and exceptions are in every Studio plan.
What is not built yet
A release's passport is signed and can be checked from outside the Studio, and the GitHub Actions pipelines the Studio generates run that check before every deploy. The paper sets out each of the following as well; none of them is available today.
The check in pipelines the Studio did not generate
The passport check is in the GitHub Actions pipelines the Studio generates. A pipeline written by hand, or one on GitLab or Bitbucket, has no such job: the Studio lists its deploys as having no passport check, and it is not held.
Scan results as evidence
Security and dependency scan results reported by the pipeline and recorded against the artefact, beside the CI results and the bill of materials that already are.
Deleting evidence when its retention ends
An organisation declares how long it keeps evidence, and a legal hold refuses deletion. Nothing deletes evidence when the declared period ends: the evidence ledger has no expiry at all, and it outlives the studio it describes.
The SBOM step in generated pipelines
A pipeline reports a bill of materials with a script and the repository's deploy token. The pipelines the Studio generates do not yet carry that step.
A credential of its own for every agent
Every agent acting under its own least-privilege credential. Today the Studio's own runner commits with the publishing person's GitHub account, and the passport says which account that was.
Not built yet These are set out in the position paper. They are not shipped capability.
Evidence for release: the Artefact Passport
The release process gathers evidence as an artefact moves through its gates, and evaluates it when the release is approved. The Artefact Passport is that record — one per artefact, at one version, judged against one policy version. Day to day it is a page a person reads, assembled from the evidence ledger each time it is opened. When a release is approved it is also issued: frozen and signed, a file a machine can check with a public key alone. What it does not hold yet is marked below. The passport has a page of its own — the problem it answers, the process step by step and what is built: Artefact Passport.
Artefact Recorded today
What it is and which version: the work package or release, its content version, its repository, pull request and head.
Policy Recorded today
The organisation guardrail policy version it was judged against — or that none applies — and a hash of the checklists themselves.
Gates Recorded today
Ready and Done: every item, both sides, the evidence behind each and the verdicts. A release adds its readiness check and who approved it.
Exceptions Recorded today
Listed first: each waiver and each override, as in force, expired or voided, with its expiry, who granted it and under which authority.
Controls Recorded today
Each framework control a checklist item names, as satisfied, waived, not satisfied, not needed or unknown. Unknown is never shown as satisfied.
Provenance Recorded today
For each pull request head: the runner, the model and who started the run where the Studio published that head, and the DPIA a release relied on. What was not recorded is shown as unknown.
CI results Recorded today
The CI check runs and commit statuses at the head that was assessed, recorded as evidence rather than only displayed.
Ledger Recorded today
A hash chain over the evidence. The passport says whether the chain is intact, whether each entry still matches its source, and what was recorded late or lost.
Signature Recorded today
On an issued version: the passport frozen at release approval, or on demand, and signed with the platform's key, so that anyone holding the file and the published public key can check it. The page read day to day is assembled afresh and is not itself the signed copy.
Deployments Recorded today
Which environment a release reached, the commit, the workflow run and when, and any rollback — as a deployment pipeline reports it.
Bill of materials Recorded today
On a release: each software bill of materials a pipeline reported — its format, the commit it describes and the SHA-256 of the document. The document itself stays with the pipeline; the digest is what is recorded.
Sample review Recorded today
Whether the package was picked for a second look after it completed, and what the reviewer found. Shown; it is never a reason a release is held.
Legal hold Recorded today
Whether a hold is in force on the artefact, who placed it and why.
Scan results Not built yet
Security and dependency scan results reported by the pipeline, recorded against the artefact.
An adoption path
Organisations do not move to this in one step. Each step is useful on its own, and none requires the ones after it.
Read only Available now
One page per artefact showing every gate, every piece of evidence and every exception. CI results are recorded as evidence. Nothing changes in behaviour.
Map Available now
Attach control references to the studio's own Definition of Ready and Done items. The passport's controls table fills in.
Set guardrails Available now
An Enterprise organisation defines its first guardrail policy — five to ten items and a handful of release rules — and its linked studios' new work packages are born under it.
Verify externally Available now
Check a release's signed passport with the published public key before a deploy, in warn-only mode first, then held for production. The pipelines the Studio generates run the check before every deploy, and the studio owner chooses warn or enforce for each environment.
Tighten Available now
Separation of duties where the risk warrants it, exception expiry, and sampled human review after the fact for any studio running autonomously — which records what a reviewer found and never holds a release.
The pipeline is not dying. It is being demoted, and that is a promotion.
From how work is done to how work is verified and enforced. Agents write the code and propose the releases; the organisation says, once and centrally, what must be true before work moves; the system gathers the evidence at the moment each decision is taken. The last step — the pipeline refusing, deterministically, anything that does not carry that evidence — is built for the pipelines the Studio generates, and is still to build for every other pipeline.
The full position paper, Agent Pipelines: control and predictability in an agent-driven SDLC, is available with the Vendor Pack. How the Studio's compliance controls and evidence work today is on Compliance & Controls.