Verdant

Inspiration

Writing code got fast. Everything after the last keystroke - review, tests, security fixes, packaging, release, deployment, monitoring, rollback, audit - still moves at human speed and lives in separate tools. At the same time, teams are asked to understand the carbon cost of what they run, but carbon usually lives in an annual report, not in the pipeline.

I'm in Johannesburg. In Google's own 2025 data, the closest cloud region to me runs on one of the dirtiest grids in the dataset: 641 gCO2e/kWh. Finland's is 29.8. No pipeline asks that question. Verdant treats carbon like latency or security: measurable, budgeted, and able to block a deploy.

What it does

1. Plan - A project member files an issue from the Verdant Change Request template and assigns it to Verdant's flow service account. The Intent Planner agent classifies it against a bounded change catalog (add a read-only endpoint, update a service setting, patch a dependency) and posts a plan with carbon, latency and blast-radius budgets - or refuses anything touching auth, secrets, migrations, IAM, CI or infrastructure and labels it verdant:needs-human.
2. Create - The Builder/Verifier agent edits only app/, runs the tests and linters itself, creates verdant/<iid>-<type>, commits and opens the merge request.
3. Verify - pytest with coverage, ruff, and unit tests for the OPA policies.
4. Secure - GitLab SAST and Secret Detection, Trivy dependency scan, CycloneDX SBOM.
5. Package - Docker image, signed keylessly with Sigstore cosign using the pipeline's GitLab OIDC identity, SBOM attached as an attestation, signature verified, image scanned.
6. Configure - The carbon engine evaluates 11 Google Cloud regions with Google's published 2025 grid-intensity data, rejects those outside the latency budget or residency allowlist, picks the lowest-carbon feasible region, and fails the job if modeled SCI is over budget. An OPA gate then combines security findings, secrets, the change catalog (agent branches can't touch CI, policy or infra) and the carbon decision.
7. Release - Tags produce a GitLab Release with the signed digest and the carbon summary.
8. Deploy & Monitor - Optional Cloud Run canary at 0% traffic in the selected region, live SLO probes, then promotion or automatic rollback to the previous revision. Every pipeline also probes the exact built image as a service.
9. Govern - An evidence pack (tests, scans, SBOM, digest, policy decision, carbon decision log, SLO result, SCI report) is published as an artifact and on GitLab Pages. The Pipeline Guardian flow, triggered by pipeline events, posts it to the MR and the original issue - or, if the pipeline failed, makes at most two bounded repairs in allowlisted classes and otherwise escalates to a human.

How we built it

• GitLab Duo Agent Platform: two custom flows written in the v1 flow schema (.gitlab/duo/flows/), five agents in total, conditional routers, a flow runtime config (.gitlab/duo/agent-config.yml) and an AGENTS.md that every agent follows.
• GitLab CI/CD with nine stages and real gates: nothing is || true.
• MCP: three stdio MCP servers (carbon engine, Cloud Run operations with dry-run by default, notifications) wired into Duo Agentic Chat through .gitlab/duo/mcp.json.
• Policy as code: OPA Rego v1 with its own test suite.
• Service: a FastAPI "GreenOps Status API" exposing the carbon decision (/api/region, /api/sci, /metrics, status page).

Challenges we ran into

Making autonomy safe rather than just fast: every permission an agent has is re-checked independently in CI (the change-catalog policy re-validates agent branches), and the gates are attacked on every run to prove they still block. Being honest about carbon: we replaced illustrative numbers with Google's published dataset, defined the baseline as the lowest-latency region a carbon-unaware deployer would choose, and stated every assumption. Getting agent flows, CI and a free live deployment to work end-to-end in a few days.

Accomplishments that we're proud of

• The Duo agent took an issue to a merged, live endpoint: it planned 3 files and 4 tests, wrote the code, and its branch passed 14/14 jobs.
• 10/10 gate-proof scenarios on every pipeline (leaked secret, vulnerable dependency, agent editing CI, unsupported change, oversized change, broken release, carbon breach, plus controls).
• 84.65% lower modeled operational SCI than the carbon-unaware choice, from published data, and a pipeline that measures its own emissions.

What we learned

Agents are only as trustworthy as the checks around them, so we re-checked every agent permission independently and attacked those checks on every run. Honest carbon numbers - published data, a fair baseline, stated assumptions - are less dramatic than marketing numbers but defensible. And building from Johannesburg made the problem concrete: the fastest region for us is the dirtiest in the dataset.

What's next for Verdant

Hourly or marginal grid intensity and time-shifting deferrable CI jobs; measured latency instead of profiles; per-request energy from runtime telemetry; and more change types in the catalog.

Built With

• cosign
• cyclonedx
• docker
• fastapi
• gitlab
• gitlab-ci
• gitlab-duo
• gitlab-duo-agent-platform
• gitlab-pages
• google-cloud-run
• green-software-foundation-sci
• model-context-protocol
• open-policy-agent
• playwright
• python
• rego
• render
• sigstore
• terraform
• trivy