LegionEdge
All blog posts
EngineeringMay 6, 20261 min read

Designing Foltrac's autonomous rollback policy

An agent that can deploy must know when not to. Inside the policy engine that decides.

CategoryEngineering
PublishedMay 6, 2026
Reading time1 min
Sections01
SourceEngineering blog
00

Overview

The scariest part of autonomous operations isn't the deploy — it's the moment after, when something looks slightly wrong and a system has to decide whether to keep going or back out. Foltrac's rollback policy is the most carefully designed piece of the product.

The core rule: rollbacks must be boring. Foltrac never invents a recovery strategy at incident time. Every deploy records its inverse as a concrete, pre-validated plan before the first byte ships, so rolling back is replaying a plan that was checked when everyone was calm.

Detection is deliberately conservative. The policy engine watches error rates, latency distributions, and resource envelopes against baselines from the previous release — not absolute thresholds, which rot. A regression has to be sustained and attributable to the new release before the engine acts; transient noise gets logged, not acted on.

There's also an asymmetry built in: the engine needs strong evidence to keep a suspect release, but only moderate evidence to roll it back. Reverting a good deploy costs you minutes; keeping a bad one costs you an incident. The math should reflect that.

Our agent systems research powers the coordination underneath — multiple regions roll back in dependency order, not alphabetically. The result across clouds: recovery that's fast because it was planned, not because it was clever.

Want the build notes as they happen?

The blog is written by the engineers shipping Nokuva, Tavoc, and Foltrac — deep dives land here as the work does, and the authors answer questions.