Documentation

Sentinel

Autonomous monitors that detect issues and start remediation tasks when they spot one.

Sentinel Sentinel watches for conditions and takes action when it finds one. While a schedule is triggered by time, Sentinel is triggered by something becoming true.

You’ll find it in the factory’s Schedules section.

What it monitors

Conditions you define — a failed check, a pattern in the codebase, a signal from a linked system, or a standard falling out of compliance.

When a monitor fires, it starts remediation work: a regular task with a specification, following the same planning, build, verify and review process as any other task.

Why this approach is secure

Sentinel does not edit your code directly. It initiates work that fixes your code, and that work results in a pull request for you to approve.

This is more important than it might seem. An autonomous system that edits production code directly lacks a review step at the precise moment you need one — when no one requested the change and no one is watching. Routing through the normal workflow means autonomy boosts throughput without removing control.

Templates

Common monitors come as templates so you don’t have to create the first one from scratch — recurring health checks, drift detection, and standard remediation cycles.

Start with a template, run it in advisory mode for a while, and tweak it before letting it start work unattended.

Keeping it under control

Work started by Sentinel competes for the same agent slots as all other tasks. A monitor that fires frequently can quietly use up your capacity.

Three rules to keep it useful:

  1. Give it lower priority than work requested by humans. P2 or P3.
  2. Make conditions specific. “A test is failing” triggers constantly in a busy repository; “this specific check has failed on the base branch for over an hour” triggers only when something is genuinely wrong.
  3. Review the outcomes. If a monitor has created twenty tasks and you merged just two, it is creating noise and wasting resources rather than delivering value.

Watch the merge rate, not the fire rate

The true measure of a monitor is what proportion of its work gets merged. A monitor that fires rarely but is correct every time is effective. A monitor that fires constantly and is usually ignored is a burden.