Pipelines fail at the seams between stages, not inside them. Here is how to hand context from build to test to deploy so risky releases stop looking like routine ones.
See the pattern in action, tap through the tabs below:
[2026-10-05 pipeline] where context dies
Every stage knows its own job and nothing else. Build knows what changed. Test does not. Deploy does not know which tests were skipped. A migration flag set in a pull request never reaches the canary step, so the risky release gets the same treatment as a typo fix.
The outcome you want is simple: each stage receives a short, verified brief from the stage before it, and refuses to proceed when the brief is missing or does not match the artifact.
{
"handoff_id": "rel-2026-10-05-0142",
"from_stage": "build",
"to_stage": "test",
"artifact": "registry.example.com/shop/api@sha256:9f2c...",
"commit": "a41b7de",
"changed_paths": ["services/checkout/", "db/migrations/0198.sql"],
"risk_flags": ["schema_change", "touches_payments"],
"tests_required": ["contract", "migration_dry_run", "load_smoke"],
"open_questions": [],
"rollback_ref": "rel-2026-10-04-0139",
"signed_by": "build-agent@ci"
}
$ handoff verify rel-2026-10-05-0142 [build -> test] manifest schema ok [build -> test] artifact digest matches registry [test] risk_flags include schema_change, adding migration_dry_run [test] contract: pass | migration_dry_run: pass | load_smoke: pass [test -> deploy] handoff accepted, rollback_ref confirmed [deploy] canary 5 percent... error budget healthy [deploy] promoted to 100 percent, handoff chain archived
[checklist] first week
1. Pick one pipeline with a painful deploy history. 2. Define the manifest fields above, nothing more. 3. Make build write it and test refuse to run without it. 4. Add deploy last, once test handoffs are stable. 5. Review rejected handoffs weekly and tighten the schema.
The bottleneck: context dies between stages
Most CI/CD pipelines are a relay race where the baton is a green checkmark. A green build says nothing about which services changed, whether a migration is attached, or what the last release looked like. By the time the deploy step runs, the only thing it knows is "tests passed."
That is how a payments change ships with the same canary window as a README edit. The fix is not a smarter deploy tool. It is a structured handoff between stages.
The outcome: Automated CI/CD Stage Handoffs
Every stage ends by writing a small manifest and every stage starts by verifying the one it received. The manifest carries four things:
- Identity: the artifact digest and commit, so nothing gets swapped mid-pipeline.
- Risk flags: schema change, secrets touched, payments path, and similar.
- Obligations: which checks the next stage must run because of those flags.
- Escape route: the rollback reference, confirmed before deploy begins.
Why this beats a bigger test suite
Adding tests makes every release slower. Handoffs make risky releases slower and leave routine ones fast. The risk flags decide the path, so a docs change flows straight through while a migration picks up a dry run and a longer canary.
It also fixes the blame problem. When a stage rejects a handoff, the log says exactly which field was missing or which digest did not match. No one has to reconstruct the story from five dashboards.
Where the agents fit
A small agent per stage does the boring parts: reading the diff to set risk flags, assembling the manifest, and checking the incoming one. Keep the agents narrow. They propose flags and verify fields. Humans own the schema and the policy for what a flag requires.
How it is built
Tooling is the easy part. Build the manifest as a pipeline artifact in GitHub Actions (or the equivalent in your CI), sign it so tampering is visible, and borrow the provenance ideas from SLSA. An LLM step can classify the diff into risk flags, but the verification step should be plain deterministic code: schema check, digest compare, rollback lookup.
Common mistakes
- Letting the agent decide policy. It should only flag, never waive a required check.
- Free-text handoff notes. If a field is not machine-checkable, the next stage cannot refuse on it.
- Starting with deploy. Begin at build to test, where the payoff is quick and the blast radius is small.
FAQ
What is a CI/CD stage handoff?
It is the structured brief one pipeline stage passes to the next, covering the artifact identity, risk flags, required checks, and rollback reference.
Do I need AI agents to do this?
No. The manifest and verification are ordinary code. Agents help with reading diffs and drafting the manifest, which is the tedious part.
How is this different from a normal pipeline artifact?
Artifacts carry files. A handoff carries decisions and obligations, and the next stage is allowed to refuse it.
Want this workflow built for your own team? The hands-on labs in the DevOps Boot Camp are a good place to start, and the rest of the catalog lives on our courses page.
