The Release Agent

An agent that takes a service from tests to a signed release, and proves every step.

Comment

Inspiration

Writing the code is the easy part now. What happens after is the challenge. I run a small signed verification API, and every release meant the same manual checklist: run the tests, package it, sign it, write down what happened. I wanted an agent that does the whole lifecycle and proves it did, so I built one.

What it does

The Release Agent takes verify-atom from code to release through six supervised stages: VERIFY runs the 26-test pytest suite and halts the release on any failure; BUILD packages the service into a versioned zip; SIGN generates a fresh Ed25519 keypair for the run and signs the artifact manifest; ATTEST writes a signed release attestation covering test results, artifact hash, timestamp, and key id; PUBLISH stages the bundle as a dry run and writes the deploy plan a human would follow; REPORT produces a human-readable release log and re-verifies the attestation signature. Every gate decision and stage outcome lands in a JSONL evidence log, so the full trail is auditable.

Three autonomy modes, one code path: assisted (human approves every stage), supervised (agent runs the pipeline, human approves the release gate), hands-off (full auto, evidence log is the audit trail).

How it uses GitLab

The .gitlab-ci.yml maps the agent onto GitLab shared runners: five jobs (test, build, sign, attest, publish), each invoking one agent stage in hands-off mode with the pipeline id as the run id, passing the run directory forward as artifacts. The attest job independently re-verifies the attestation signature. It runs at $0 on shared runners.

Paths entered

Path B: Bring Your Own. The existing project is verify-atom, a live signed verification API; the agent automates its post-code DevSecOps lifecycle. Eligible tracks include the Path B autonomy prizes, Most Stages Covered, Most Impactful, and Most Creative.

  • Original MIT project: https://github.com/asherengos/verify-atom
  • This entry, public on GitLab: https://gitlab.com/asherengos/release-agent
  • Deployed project, publicly accessible, live through judging: https://asheraistudios.duckdns.org
  • Updated and deployed after October 5, 2026: the Release Agent, its attestation module, and the GitLab CI pipeline were built and pushed October 20-21, 2026, including a fix that lets the pipeline run one stage per CI job by restoring earlier stages from the evidence log. The underlying verify-atom service itself dates to September 26, 2026 and remains live.

Honest scope

  • PUBLISH is a dry run by design. The agent stages the bundle locally and never deploys; no production deployment is claimed.
  • Attestation keys are fresh demo keys generated per run, never committed, never the service's production key.
  • The demo video shows a real local pipeline run and the real CI definition. Test counts and signature verifications shown are real.
  • Platform note: the project requirements name GitLab Duo Agent Platform as the platform. This entry's agent is custom Python running on GitLab CI, not Duo. That gap is disclosed here rather than papered over. The automation, signing, and attestation are real and running on GitLab CI today.

Future work: Duo integration (planned, not built)

The signed Python pipeline stays the core. It works, it is auditable, and it is not being replaced. Duo joins it as a complementary, independent participant, in this order:

  1. Duo review. A Duo agent reviews each release attestation and evidence log and posts a review note on the pipeline. A second, independent pair of eyes fits the verify-atom ethos of independent verification. This is the first integration to build because it adds value without touching the signed pipeline.
  2. Duo triage. When a stage fails, a Duo agent opens an issue with a diagnosis and a proposed fix drawn from the job log, so a failure arrives with a first draft fix instead of just a red pipeline.
  3. Duo release notes. A Duo agent drafts the human-readable changelog from the evidence log and attestation for the operator to approve before publishing.

Before building any of these, the first step is research on the account (a Duo license was already issued through contributor onboarding): confirm exactly how Duo agents are triggered, whether by issue assignment or by CI job, so the integration is genuine and not a label.

Built With

Share this project:

Updates

Submission history