Gremlin's Foresight AI reruns the failing chaos test to check its own proposed fixes

Foresight AI starts from a chaos experiment that has already exposed a weakness. Gremlin positions it against AI tools that respond to incidents already underway, aiming instead at failure modes a team can test in advance ^[10]. Going by Gremlin's materials, a run has four steps:

1. A controlled fault test exposes a weakness in a service ^[2]. 2. The product diagnoses it from the test, service and health-check context, tying its recommendations to the observed results ^[6]. 3. It proposes a configuration patch or an infrastructure-as-code change for the team to approve ^[2][8]. 4. It reruns the test that exposed the risk, and can repeat tests as the system evolves ^[2][11].

Step four is the good engineering here. Runtimewire put the case plainly: a recommendation can be plausible and still leave the failure mode untouched, and rerunning the originating test checks the result under the same condition ^[13]. A passing rerun covers one injected fault. Side effects of the change on paths that test never exercised have to surface in the rest of the suite.

Step two draws on what Gremlin calls its Failure Atlas, a proprietary set of more than a decade of cause-and-effect data on failures and recovery ^[5]. Treat it like any benchmark built on someone else's workload. For its diagnoses to transfer, the failures in that data have to resemble the dependencies and recovery behaviour of the stack under test.

The model question is separate. Use of an external large language model is optional and requires customer permission, Gremlin says ^[7]. Runtimewire notes that buyers are able to check which system context the product draws on and under what conditions it may be passed to an AI service ^[14]. Granting that permission is a different decision from approving any single change.

Gremlin says Foresight AI completed a beta. The announcement also leaves out the beta's customer count, its duration and any incident-prevention results ^[3][9]. Runtimewire concluded that Gremlin's claim to have already proven the product can identify and address risks before incidents is unverified by those measures ^[4].

I think the right deployment is a supervised pilot on non-critical services. Keep the approval gate Gremlin describes on every change ^[8], and log each outcome as accepted, edited or rejected. Counted over the pilot, those outcomes give an acceptance rate measured on the team's own services.