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.
System architecture
- 01 Investigation engine For each alert, incident, or question, forms and tests hypotheses against your environment.
- 02 Decision Model Stores environment context, investigation strategies, and verification results.
- 03 Verification engine Checks production after a change or investigation and records the verification result.
- 04 Calibration engine Tests investigation strategies against past production issues through replay and self-play.
- 05 Discovery engine Updates services, dependencies, deploy patterns, and ownership from connected production data.
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.
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.
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.
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.
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.
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.