RollguardRollguard
In developmentJoin the waitlist

For teams that let AI agents ship to production

Trust what your agents ship.

Rollguard makes every release reversible, feature by feature. Guards watch your metrics and roll back on their own the moment something breaks, so you can give your agents more autonomy with less risk.

Join the waitlistSee how it will work

In development · Android first · GitHub Actions and GitLab CI

feature checkoutRelease 44, written by an agent
Rolled back to 43
checkout_successguard: < 95%
95% 91.8%
  1. 14:02The agent merges PR #812 and ships release 44
  2. 14:20Rollout to 10% of devices
  3. 14:31checkout_success drops to 91.8%: the guard trips
  4. 14:31Checkout rolls back to 43, applied on next screen view
  5. 14:32The agent gets the incident and opens PR #813

Illustrative example. No human had to step in.

Reviewed before the merge. Guarded after it.

Your agents write and review the code. Rollguard adds the next layer of confidence: guards that watch production and take back what breaks.

Roll back what CI/CD can't.

Your agents ship to phones, TVs and customer devices, where a redeploy changes nothing. Rollguard reverts their mistakes right on the device.

Roll out & back, feature by feature.

When an agent's feature misbehaves, only that feature goes back to its previous code. The rest of its work stays live.

Rollbacks without a release.

No hotfix build, no store review, no waiting for users to update. Your agent keeps its autonomy, your users keep a working app.

Why now

Agents doubled the output. Confidence has to keep up.

Reviews catch a lot before the merge. Some problems only show up with real users, on real devices. That is where Rollguard adds a layer of confidence.

1 in 3pull requests on GitHub involves an agent.Microsoft, July 2026
2.09×more pull requests per developer once agents are adopted: twice as much to review.Second Talent, 196,000 PRs
96%of developers don't fully trust AI-written code. Only 48% always check it before committing.Sonar, State of Code 2026
43%of AI-written changes need debugging in production, even after QA and staging.Lightrun 2026

How it will work

Four steps. Three of them run on their own.

Step 1 of 4

New code goes into a versions block

Your agent writes the new version next to the old one, inside a versions block. Nothing changes for users until the config says to play the new one.

Checkout.ktKOTLIN
versions("checkout") {
  44 { CheckoutV2() }  // written by the agent
  base { CheckoutV1() } // safe fallback
}

Per-feature rollback

Roll back the feature, not the release.

Release 44 ships four features. One breaks. A classic rollback throws away all four, and the revenue the other three were bringing in.

Rollguard rolls back only the broken one. Need the whole version back? One rule does that too.

Release 444 features · 3 still live
  • new_checkoutRolled back to 43
  • smart_searchLive · 100%
  • onboarding_v2Rollout 50%
  • dark_modeLive · guarded

Mobile, desktop, TV, embedded

When you can't redeploy, roll back in place.

On a server, you redeploy and everyone has the fix. On a phone, a TV or a customer's device, a broken release stays broken until the store approves your fix and every user updates. Each of those days costs users and revenue.

Without Rollguard
  1. Bug found in production
  2. Write and ship a hotfix
  3. Wait for store review
  4. Users update, slowly, some never

Days with a broken checkout on every device

With Rollguard
  1. The guard trips on 10% of devices
  2. The feature rolls back on the device itself
  3. Users are back on 43, no update needed
  4. The fix ships when it's ready

Minutes, on a fraction of your users

15.4% of users uninstall an app after a single crash. Luciq 2026

53.2% abandon a purchase during a sale because of a crash or slowdown. Luciq 2026

Custom rules

Rollback rules as precise as your incidents.

Roll back only where it breaks. Combine conditions with AND and OR, on the signals you already have.

DeviceOS versionCountryApp versionCrash rateExpectationsBusiness metricsCrashlytics alertsWebhooks

Use cases

Give your agents more room, safely

Agents with production access

Let agents merge and release on their own. Guards add a layer of confidence on top of their reviews, in production.

One bad PR in a batch

Twelve agent PRs in one release, one of them faulty: roll back that PR and keep the other eleven.

An external signal fires

A Crashlytics alert or a webhook comes in: a rule tightens the rollout or triggers a rollback, no human in the loop.

Ship any day of the week

Releases climb step by step, Friday included. If anything drifts, they come back down on their own.

A first look at the SDK

Ten lines. The rest is automatic.

Each level of a versions block is the code of one app version. The SDK plays the level the signed config tells it to, and falls back to the previous one on a crash, even offline.

You decide when a switch applies: next launch, next screen or instantly, per feature.

CheckoutScreen.ktKOTLIN
@Composable
fun CheckoutScreen(cart: Cart) {
  versions("checkout", applyAt = NextForeground) {
    44 { CheckoutV2(cart) }   // new version
    43 { CheckoutV1(cart) }   // previous version
    base { LegacyCheckout(cart) }
  }
}

Built for agents

Automatic safeguards, not more human checkpoints

Rules your agents can drive

A dashboard for humans, an API and an MCP server for your agents. One engine behind all three.

Safety Ratchet

Agents can always tighten a rule. Loosening one takes proof: a simulation on real data and a limited budget.

Signed config

Every decision sent to devices is signed. The SDK rejects anything that doesn't come from your project.