Inspiration

Teams currently select a single global autonomy level for coding agents. This applies the same level of trust to a documentation typo as to a deployment configuration change. There is no mechanism to adjust autonomy based on agent reliability or specific change types. Autonomy Ledger lets agents earn autonomy per change class from real outcomes. Level changes live in git as commits and merge requests; outcomes live on the merge requests as labels.

What it does

Autonomy Ledger uses a policy.json file to define autonomy levels (assisted, supervised, hands-off) and ceilings for change classes including docs, tests, code, config, and policy.

The system uses Duo flows to judge changes. A custom review flow posts a structured verdict note that the gate reads. A custom incident flow writes the postmortem issue after a rollback. A custom steward flow runs on a weekly scheduled trigger and opens an autonomy report issue from the published ledger. The foundational Developer Flow turns issues into merge requests, the Fix CI/CD Pipeline flow repairs failing pipelines, and the Code Review flow reviews every merge request alongside the gate.

Deterministic CI gates categorize changes and labels. For hands-off classes with a green pipeline, the system arms auto-merge. For assisted classes, it builds a child pipeline where the production deployment remains manual. The system performs health checks on staging and production and performs automatic rollbacks to the previous package version if failures occur.

The ledger recomputes outcomes from GitLab data such as human commits, closed merge requests, and health results. Five consecutive clean outcomes trigger a promotion merge request. A rollback or health breach demotes the class by a direct commit in the same pipeline. A rejected merge request demotes it at the next ledger run. A dashboard on GitLab Pages displays levels, streaks, events, and promotion or demotion history.

How we built it

I used the Duo Agent Platform custom flows, Flows API, and foundational Developer Flow. I used the foundational Fix CI/CD Pipeline flow and Code Review flow. Triggers start the Developer Flow (assign) and the Fix CI/CD Pipeline flow (pipeline failed); the custom flows are started from CI through the Flows API because bot-created merge requests cannot fire triggers. CI/CD child pipelines, Pages parallel deployments and the Package Registry carry the deploys. Each default-branch pipeline creates a Release. SAST, secret detection and dependency scanning run on every merge request. Environments, an hourly scheduled check and the ledger job close the loop.

Challenges we ran into

Flow triggers require a human actor. CI starts the flows through the Flows API and verifies the flow's merge request note with a per-pipeline token. The flow's OAuth token is limited to the ai_workflows scope, so merges, releases and deploys are done by CI jobs with a project token. Custom CI variables are invisible inside flow jobs. I make sure all required data travels within the goal text. A merge request must never be able to rewrite the code that judges it, so the gate runs in a separate pipeline on the protected default branch, started by a trigger token, and takes every fact from the GitLab API instead of the environment.

Accomplishments

The system implements a multi-layered governance model for AI agents. Demotions are automatic; promotions are proposed as merge requests that a human approves, so autonomy only ever grows with a human signature. Level changes are git history; outcomes are merge request labels. The automation touches all nine DevSecOps lifecycle stages listed by the hackathon. Everything below is public in the project and can be checked in the pipeline history.

What we learned

I learned how to coordinate complex interactions between CI/CD pipelines and the Duo Agent Platform. I learned how to manage permissions between flow tokens and project tokens. I learned how to use GitLab Pages to visualize complex system states like autonomy streaks and history.

What's next

Run the nine prepared agent issues through the Developer Flow so docs earn hands-off from real clean merges, then shadow mode for assisted classes, a per-class credit budget, and Orbit context for blast radius.

Status at submission (honest)

• Project: https://gitlab.com/mikgpt-group/autonomy-ledger (MIT, public). Pipelines: https://gitlab.com/mikgpt-group/autonomy-ledger/-/pipelines
• The default-branch pipeline runs green end to end: tests, SAST, secret detection, Eco CI energy measurement, package, release, staging deploy and health check, a policy-shaped child pipeline where production is a manual job for assisted classes, production deploy and health check, and the ledger job that publishes the dashboard: https://autonomy-ledger-3972d9.gitlab.io/ledger/
• A real merge request (https://gitlab.com/mikgpt-group/autonomy-ledger/-/merge_requests/1) went through the full gate: the merge request pipeline started a gate pipeline on the protected default branch through a trigger token, the gate classified the change as docs at level supervised and labelled the merge request.
• The Duo review flow, incident flow and steward flow are created in the AI Catalog and enabled in the project by the bootstrap script. On this new account GitLab answered the Flows API with "Identity verification is required to use GitLab Duo Agent Platform", so the review could not run before the deadline. The gate failed closed exactly as designed: verdict blocked, a human approval rule, no merge. The pipelines run on a project runner for the same reason.
• The full earn and lose loop (five clean merges, promotion merge request, hands-off auto-merge, production breach, rollback, demotion commit) is proven offline by tools/simulate.py against a fake GitLab API, and 83 unit tests run in every pipeline.

Lifecycle stages covered

Plan: Issue templates and flow planning. Create: Developer Flow merge requests and Fix CI/CD Pipeline flow. Verify: Unit tests, build, and review flow results. Package: Versioned site tarballs in the Package Registry. Secure: SAST and secret detection templates. Release: a GitLab Release per default-branch pipeline. Configure: Config as code and policy-shaped child pipelines. Monitor: Staging and production health checks with scheduled pipelines. Govern: policy.json, promotion merge requests, demotion commits, outcome labels, incident postmortems, the dashboard.

Built With

• gitlab
• gitlab-ci
• python