Inspiration

Code generation is solved. The bottleneck moved downstream: planning, review, pipeline failures, security triage, and releases. Small teams skip those steps under pressure — and pay for it in production. We asked: how much of that can agents carry, and where must they stop?

What it does

ShipSafe is a crew of GitLab Duo Agent Platform flows around a tiny Flask service, for Path A (Start Fresh) at the Supervised autonomy level:

  1. Triage plans a new issue and posts a scoped plan and Definition of Done.
  2. Gatekeeper reviews every MR it is assigned to, checks test coverage, triages SAST, secret, and container findings, and ends with VERDICT: READY / NOT READY.
  3. Pipeline Medic reads real failed job logs, diagnoses the root cause, and opens a minimal fix MR — or, when confidence is low, an issue that says NEEDS HUMAN DECISION and changes nothing.
  4. Release Scribe summarises a green main pipeline, verifies staging health (or honestly reports NOT VERIFIED), checks config drift, and posts a release candidate for one human approval.
  5. Config Drift compares live config with intended config, key by key, and opens a fix MR instead of applying a change itself.

All of them are governed by AGENTS.md: agents may open MRs and post notes; they may never merge, approve their own work, or deploy to production.

One rule is enforced by code, not trust — the Verdict Gate: a CI job that reads the Gatekeeper's latest verdict and blocks merging if it is missing, NOT READY, stale (its VERDICT_SHA no longer matches the head commit), or written by the MR author. It fails closed and leaves an evidence report on every pipeline.

How we built it

Five custom Duo flows in .gitlab/duo/flows/ with focused, structured prompts and GitLab tools for work items, MRs, and pipeline logs; a GitLab CI/CD pipeline mapping test, build, SAST, secret detection, container scanning, and Cloud Run staging deploy to the nine DevSecOps stages; a flow-validation script in CI; Python and Flask with Docker for the demo service; and a scheduled monitor with a 404 control test. Locally verified: 24 tests pass, and POST /checks returns ready_for_production: true with good inputs and false with two critical vulnerabilities.

Challenges

GitLab identity verification blocked CI jobs entirely — pipelines failed with 0 jobs, not with a code error, so we had to read the pipeline error detail instead of fixing code that was not broken. Project access tokens kept failing because they were Guest project bots, not the owner account, so the final push had to be done in the browser as the owner, one file per commit. And in PowerShell, plain curl is an alias that breaks headers, and inline JSON arrived empty — Invoke-RestMethod was the reliable way to test the API.

What we learned

Agents are most trustworthy when their limits are written down and enforceable: separate the verdict step from the merge step, require evidence for every claim, and make "NOT VERIFIED" a valid, respected answer.

What's next

Scheduled monitoring runs, carbon-aware staging deploys, and a drift flow that opens (never applies) config-fix MRs.

Built With

  • anthropic
  • docker
  • flask
  • gitlab-ci/cd
  • gitlab-duo-agent-platform
  • google-cloud-run
  • prometheus
  • python
Share this project:

Updates

Submission history