Inspiration
AI now writes code faster than small teams can safely review and ship it. A team without a release manager or an on-call SRE has two bad options: review everything by hand and lose the speed, or let agents ship and lose sleep.
The real question isn't can an agent ship to production. It's why would you trust it to? Prime answers that the way a good team treats a new engineer: autonomy is earned, scoped, and reversible.
What it does
Prime takes a change from a GitLab issue to production on Google Cloud Run, then watches it, and repairs it when it breaks.
- Earned. Each area of the codebase has a trust score in an Autonomy Ledger. A clean release adds 10. A rollback subtracts 40, so one rollback outweighs four clean releases.
- Scoped. Every merge request gets a risk tier from policy-as-code: 🟢 HANDS_OFF, 🟡 SUPERVISED or 🔴 HUMAN. Hands-off needs low risk and trust ≥ 70 in every area it touches. Hard caps no score can override: changes to the rules that govern agents always need a human, payments are never fully hands-off, and an open High/Critical security finding blocks autonomous release.
- Reversible. Every release goes through a canary. Its size and wait are set by the tier (50% for 2 min, 10% for 5 min, 5% for 10 min). If the error rate or p95 regresses, a deterministic guard rolls production back with one traffic update. No LLM is involved in that decision.
- Self-healing, with proof. After a rollback, Prime opens an incident and starts an Incident Responder agent. The agent finds the root cause, opens a fix MR with a regression test, and writes the postmortem. A fix can ship hands-off through a remediation lane even though trust was just lost, but only with proof: its new test must fail on the bad commit and pass on the fix.
The core rule: agents make judgments, deterministic rails hold the keys. No Prime agent has a merge, deploy, promote or rollback tool. GitLab CI does all of that, from rules a human wrote.
What the video shows (all real runs on this project, Oct 26):
- Hands-off. I created issue #7 and touched nothing else. The Triage Planner wrote acceptance criteria, a plan and tests. Prime's dispatcher handed it to GitLab's Developer flow, which opened MR !6. The policy scored it 25/100, the Gatekeeper confirmed, and it auto-merged, passed a 50% canary with 0.0% errors and was promoted.
apitrust rose from 80 to 90. - It breaks, and heals. MR !7 passed all 18 tests, but would crash in production: it parsed the release version, which is a commit SHA in prod. The Gatekeeper agent caught it and escalated HANDS_OFF to SUPERVISED. I merged it anyway, as humans do. The canary saw 20% errors on
GET /invoices, and Prime rolled back in under a minute, opened incident #8 and cutapitrust by 40. The Incident Responder wrote the postmortem and fix MR !8 with a regression test. The fix shipped and the incident closed itself. - Proof, not reputation. In an earlier run (incident #4 → MR !2), the responder's fix earned the remediation lane: its test failed on the suspect commit and passed on the fix, so it shipped hands-off through a 5% canary.
- Humans stay in charge. A draft MR that lowers the hands-off bar (MR !5) is capped at 🔴 HUMAN: "Changes to the rules that govern agents always need a human."
How we built it
GitLab Duo Agent Platform: 4 agents.
| Agent | Type | Started by | Can | Cannot |
|---|---|---|---|---|
| 🧭 Triage Planner | custom flow | a human creating an issue (work-item trigger) | read code, label, write the plan | write code, merge |
| 🛠️ Developer | GitLab foundational flow | Prime's dispatcher moving the issue to In progress | write code and tests, open an MR | merge, deploy |
| 🛡️ Autonomy Gatekeeper | custom flow | CI on every MR (Flows API) | review the diff, confirm or escalate | lower a tier, merge |
| 🩺 Incident Responder | custom flow | CI after a rollback (Flows API) | find the cause, push a fix branch, open an MR, write the postmortem | commit to main, merge, deploy |
- Flows as code. Flow definitions and triggers live in
.gitlab/duo/flows/andcatalog.yml. Aflows:syncCI job pushes them to the AI Catalog and records the result on the Prime-Flows wiki page. Changing an agent's instructions is an MR like any other, capped at HUMAN. - Tool scoping. What an agent may do is set by the toolset in its flow file. None has a merge or deploy tool.
- Fail-safe. If the Gatekeeper doesn't answer within 8 minutes, the change is treated as SUPERVISED. Agents can only make a decision stricter.
GitLab CI: the rails (verify → secure → govern → package → staging → canary → gate → promote | rollback → report)
- Lint and unit tests, SAST, secret detection.
risk_score.pyapplies.autonomy/policy.yml: area weights, change size, new dependencies, deleted tests, security findings, plus trust from the ledger.autonomy_gate.pyposts one Autonomy Decision note per MR and enables auto-merge only for HANDS_OFF.remediation_proof.pyruns the fix's new tests against the suspect commit's code and against the fix.canary_check.pydrives real traffic at the canary revision and gates on error rate (SLO 2%) and p95.record_release.pywrites the result to the Autonomy Ledger, a wiki page whose history is the audit trail. Resetting trust is a manual, logged CI job.
Google Cloud
- Cloud Run runs
prime-stagingandprime-prod. The canary and rollback use revision tags and traffic splitting, so a rollback is one traffic update. - Artifact Registry stores the images.
- Workload Identity Federation: GitLab CI exchanges its OIDC token for a short-lived Google token. No Google keys are stored, and only this project can impersonate the deployer.
Observability. The demo service (a FastAPI invoice API) sends OpenTelemetry traces to GitLab Observability.
DevSecOps coverage, all 9 stages: Plan (Triage Planner, work-item statuses) · Create (Developer flow, Incident Responder) · Verify (tests, staging smoke, Gatekeeper, remediation proof) · Package (images to the GitLab registry and Artifact Registry) · Secure (SAST, secret detection, caps) · Release (canary, promote, rollback on Cloud Run) · Configure (Cloud Run and flows as code, keyless deploys) · Monitor (OpenTelemetry, canary health gate, automatic incidents) · Govern (policy-as-code, trust ledger, decisions on every MR, hard caps, agent tool scoping).
Challenges we ran into
These are GitLab.com platform limits as of Oct 2026, and how Prime works around each one. They're in the README too:
- A flow can't trigger another flow. Triggers fire only on human actions. So CI orchestrates, starting flows through the Flows API at decision points.
- A flow's
start_flowtool returned "insufficient permissions to create a new pipeline". A scheduled CI dispatcher moves READY issues to In progress, which fires the Developer flow's trigger. - Creating an issue isn't a status-change event. The planner runs on "work item created", and the dispatcher makes the status change.
- The Flows API ignores
agent_privilegesfor catalog flows. Permissions are scoped by each flow's toolset instead, and CI owns every irreversible action. - Per-trigger goals and "mark MR ready on finish" are feature-flagged. The planner writes its plan into the issue description, and the gate marks Developer drafts ready only when they ship HANDS_OFF.
Accomplishments that we're proud of
- The safety model worked against its own author. In the recorded run, the Gatekeeper agent caught a production-only bug that every test missed and escalated it. When a human overrode it, the deterministic rails still caught it within a minute.
- The whole loop is real, not mocked: issue → plan → code → review → canary → production, and rollback → incident → fix → postmortem. It's all visible in the pipeline history, incidents #4 and #8, and MRs !2, !6, !7 and !8.
- Trust is earned honestly. We reset the ledger before recording, and every bit of trust in the video came from clean releases.
What we learned
- Agents are best as reviewers that can only tighten. Giving the Gatekeeper the power to escalate, but never to relax, made it safe to trust its judgment. It also turned out to be the layer that caught the bug.
- Your safety rails need testing too. Incident #8 exposed two bugs in Prime itself. The remediation proof couldn't read merge commits, and releases ignored the Gatekeeper's escalation. We fixed both in MR !9, which Prime correctly capped at 🔴 HUMAN because it touched the rules.
What's next for Prime
- Per-endpoint SLOs and canary checks driven by the Observability MCP server.
- Trust that decays without recent releases, and finer areas (per module or per endpoint).
- Carbon per release using the Software Carbon Intensity method.
- Packaging Prime as an AI Catalog bundle, so any GitLab project can adopt it with one
policy.yml.
Log in or sign up for Devpost to join the conversation.