Self-healing at the code level — Sentinel watches the Versus control plane and every tenant and on-prem instance for glitches, diagnoses the root cause in Versus's own source, and generates a tested, scanned, reversible fix under governance you set per environment. Ships read-only.
Every other tool in Versus watches your network. Sentinel watches Versus itself — and, uniquely, it doesn't stop at noticing a problem. It diagnoses the root cause in Versus's own code and proposes a tested, reversible fix.
Versus runs a critical-infrastructure control plane and a fleet of tenant and on-prem instances. A glitch in any of them — an unhandled exception, a 5xx spike, a failed background task, a slow query, a broken migration — shouldn't have to wait for a human to notice. Sentinel collapses the time from a tenant hit a bug to a tested fix is proposed from days to minutes. It is the code-level evolution of Self-Healing: where that surfaces a detected issue and packages a support bundle, Sentinel goes on to diagnose and fix. (It is not Diagnostics AutoPilot — that fixes your managed network devices; Sentinel fixes Versus. They share the agentic and governance patterns, nothing else.)
Ships read-only. Sentinel defaults to detect, diagnose, and propose — it opens a pull request for humans to review. Auto-apply is opt-in and gated per environment, and production is never blind-merged: a fix reaches prod only after green tests, clean security scans, a passing staging verification, a canary with no recurrence, and human approval — regardless of the model's confidence.
Sentinel captures malfunctions everywhere Versus runs — the SaaS control plane and every tenant slice and on-prem install — and clusters raw errors into a Glitch: a deduplicated signature (error class + code location + version) with first- and last-seen, affected tenants and versions, frequency, severity, and evidence. Signal sources include:
For each Glitch, an AI agent reads the trace, the recently changed source, and the implicated files, then produces a diagnosis: the suspect file(s) and function(s), the change class (null-guard, off-by-one, missing migration, bad query, race, config), and a proposed fix strategy — with a confidence and a risk class. This is read-only: at this stage Sentinel has explained the bug in Versus's own code, not touched anything.
When enabled to proceed, a code agent with least-privilege repo access and a sandboxed workspace produces a minimal patch plus a regression test that reproduces the glitch and passes only with the fix. It runs the targeted tests and the affected app's suite, iterating up to a bounded number of attempts until green, then runs SAST/SCA over the diff and blocks on any new finding. The result is an opened pull request carrying the diagnosis, the diff, the new test, the scan results, and the affected-instance list — and by default the flow stops there for human review. Where tolerance allows, the rollout continues as a reversible workflow: staging deploy and verify, then a canary on one tenant or a small percentage watched for signature recurrence, then production and distribution to on-prem and tenant installs through the existing code-update poll-and-apply channel (air-gapped installs receive signed bundles and never phone home). Every stage is a gate, and every stage can roll back.
The hard part of fixing your own code is doing it safely — so the guarantees are structural, not a promise:
Phased, safest-first — each phase useful on its own: