Production agents need context and a way to verify their work

Code agents have repositories, linters, and tests. Production agents need the same two things: context about the system and evidence that their decisions worked. Cleric builds both from your environment.

Most agents do not check what happened next

They investigate an alert or incident, recommend or apply a fix, and stop. They also stop after a change—a specific release going to production. They do not check whether production recovered, a new issue appeared, or an engineer reversed the action.

Cleric uses context from your environment

The Decision Model records your services, dependencies, past investigations, changes, and engineer actions. Cleric builds it from Slack threads, PRs, tool calls, and corrections, then queries it when forming and testing hypotheses.

Cleric checks what happens after every change

For up to 14 days after a change is announced in Slack, Cleric checks for new alerts, downstream failures, metric regressions, and engineer overrides. It uses the same signals to verify issue investigations.

Verified outcomes let Cleric take on more work safely

Each verification result is written back to the Decision Model. Over time, these results show where Cleric has been reliable and where an engineer should still review its work.

01 · Investigates

Investigation engine

For each alert, incident, or engineer question, the investigation engine forms hypotheses, queries connected production data to test them, and proposes a root cause.

The Decision Model supplies the reasoning model with environment-specific priors and context. The same symptoms can therefore produce different hypotheses on different stacks.

1
ReasonForm and prune hypotheses against your environment and prior outcomes.
2
RetrievePull relevant context from the world model, strategies, and past investigations.
3
ProposeReturn root cause, recommended action, and the evidence behind both.
02 · What it knows

Decision Model

The Decision Model holds what Cleric knows about your environment and what has worked in it. It updates from every verified outcome.

It contains three structures: a world model of your services and their dependencies, strategies distilled from real investigations, and verification results from changes and issue investigations. Cleric derives these structures from connected production data, engineer activity, and verified results.

1
World modelServices, dependencies, and baselines observed from your environment.
2
StrategiesInvestigation patterns distilled from how your team and Cleric's agents have actually solved problems.
3
Verification resultsRecorded results for changes and issue investigations, used to measure where Cleric is reliable.
03 · Checks what happened

Verification engine

The verification engine follows each change into production for up to 14 days. It checks the same signals after an issue investigation.

It evaluates alert recurrence, downstream stability, metric recovery, and engineer overrides. Each signal has known failure modes and none is conclusive on its own. Cleric weights each signal using context from the change and the environment, then records the verification result and the signals behind it.

1
Evaluate signalsCheck alert recurrence, downstream stability, metric recovery, and engineer overrides.
2
Record the resultStore the verification result and the production signals used to determine it.
3
Include engineer overridesRecord when an engineer reverses or corrects Cleric's action.
4
Follow changes for 14 daysStart from the change announcement in Slack and keep checking production for up to 14 days.
04 · How it improves

Calibration engine

Calibration uses verified results to update investigation strategies.

It replays past production issues and runs self-play to test whether alternative investigation paths would have reached the correct diagnosis. Strategies are retained or dropped based on those tests and verified production results.

1
Replay and self-playTest investigation strategies against past production issues.
2
DistillPull procedures from runbooks, Slack threads, and the agent's own decision traces.
3
Retain or pruneKeep strategies that produce correct diagnoses; drop the ones that don't.
05 · Keeps the model current

Discovery engine

Discovery keeps the Decision Model accurate as your environment changes.

It maps services, dependencies, deploy patterns, observability conventions, and code ownership. As infrastructure changes, Cleric updates the model so investigations query the current state of the stack rather than a fixed snapshot.

1
MapServices, dependencies, and deploy patterns observed in your environment.
2
Learn conventionsObservability practices, on-call patterns, and code ownership, not just topology.
3
UpdateKeeps the world model current as infrastructure changes.

See Cleric follow your changes into production

Run Cleric on real changes and production issues. See what it catches, how it investigates, and where to keep an engineer in the loop.