Inspiration
As developers building web and mobile applications, we face a difficult reality: deploying a new backend does not mean every customer updates their app.
An API can return HTTP 200 and pass its unit tests while breaking an older mobile client. A renamed field or changed response type can become a production incident for users who had no control over the update.
Release Guard grew from a question: what if a release had to demonstrate that existing clients still work before reaching production?
We wanted to apply agentic AI to the responsibility that comes after writing code: understanding the consequences of a change and verifying that it is safe to ship.
What it does
Release Guard is designed to protect existing API consumers throughout the release process.
Its workflow connects:
- Compatibility detection: compare API contracts and test the candidate against supported consumer profiles.
- Impact analysis: explain which expectations failed and which client versions depend on them.
- Agent-assisted repair: use GitLab Duo to investigate the failure and prepare a focused correction.
- Independent verification: rerun deterministic checks against the repaired commit.
- Supervised deployment: validate staging and request human approval before production.
- Release evidence: collect findings, test results, revisions, approvals, and deployment outcomes in a Release Passport.
Our central demonstration scenario is straightforward: a backend change renames total to amount, breaking an older client. Release Guard’s intended response is to identify the incompatibility, preserve the existing contract where appropriate, and verify both client expectations before publication.
How we built it
We structured the project around a small orders API, versioned consumer expectations, and a release workflow on GitLab.
The architecture separates three responsibilities:
- Deterministic checks establish evidence. Contract comparisons and consumer tests determine whether compatibility expectations are satisfied.
- GitLab Duo provides investigation and repair. The agent interprets failures in context and prepares a proposed code change.
- Release policy controls publication. Approval belongs to a specific revision and artifact, so a later commit cannot inherit an earlier approval.
The interface is organized around the release journey: what changed, what failed, what was repaired, and what evidence supports the next action.
Challenges we ran into
During planning, the hardest question was defining when an automatic repair is appropriate.
Restoring a removed field can preserve compatibility, but it may contradict an intentional migration. The workflow therefore needs explicit consumer expectations and clear boundaries for when to stop and request a human decision.
Another challenge was separating an agent’s explanation from proof. A convincing summary cannot replace passing tests. This shaped our decision to make verification independent of the model.
We also had to define how approvals remain valid as code changes. Binding evidence and approval to the exact candidate became a core architectural requirement.
Accomplishments that we're proud of
We are proud of shaping the project around a concrete problem with a visible consequence: a backend update breaking an existing application.
The design connects diagnosis, repair, verification, and publication into one accountable workflow. The Release Passport makes that relationship inspectable rather than hiding it behind a single success indicator.
What we learned
Designing Release Guard reinforced that compatibility is a relationship between a service and its consumers.
An API specification describes a service, while consumer tests reveal expectations that real applications rely on. Both are valuable.
We also learned that useful autonomy requires boundaries: an agent needs to know what it may change, what evidence it must produce, and when a person must decide.
What's next for Release Guard
Our next steps are to validate the complete workflow against real GitLab executions, measure its behavior across additional breaking-change scenarios, and refine deployment recovery.
Beyond that, we want to support more consumer contract formats, richer migration guidance, and adoption by small development teams.
Our goal is simple: help developers move quickly while protecting the applications their customers already use.
Built With
- fastify
- gitlab-duo
- node.js
- typescript
