Cleric uses an AI agent to monitor production events, investigate possible causes, and present a diagnosis to engineers.
2
The agent needs concise answers, confidence scores, and ways for engineers to inspect its reasoning and teach it from feedback.
3
Cleric is working toward closed-loop remediation for specific classes of incidents, while keeping automatic resolution behind human approval today.
Summary
Willem Pienaar describes Cleric as an AI-powered SRE that operates inside a company's production environment. It receives infrastructure events, forms hypotheses, calls existing tools, uses a knowledge graph of services and relationships, and investigates until it can present a diagnosis. The system is designed to reduce the amount of context switching engineers do across dashboards, logs, traces, and other systems. Pienaar is candid about the limits. Agents can fail and hallucinate, so Cleric tracks confidence and avoids interrupting engineers when it is not confident. Engineers can inspect the investigation, provide feedback, and add local instructions. The major technical work involves building useful tools for metrics and other infrastructure data, grounding confidence in past successful investigations, and sharing useful learnings across teams. Cleric currently focuses on diagnosis and keeps remediation behind human action. Its longer-term goal is reliable closed-loop fixes for defined classes of production problems, followed by preventative action before failures occur.
Production complexity grows faster than hiring can absorb
Pienaar shows a graph of a small Kubernetes cluster containing pods, deployments, and other resources. Even this limited environment has enough relationships that engineers cannot keep the whole system in mind. Teams develop heuristics about which services to inspect, but those habits do not scale as systems grow. Hiring more people costs money and does not remove the underlying complexity. Runbooks and scripts also have limits because each incident is different and needs judgment. Adding more observability data can leave engineers with more dashboards without giving them a way to act.
Cleric investigates alerts through tools, hypotheses, and memory
Cleric is triggered by events in the production environment. For a login failure, it can form hypotheses involving an authentication service, a database connection, or a deployment. It investigates these paths by calling tools, using existing context from its knowledge graph, and going deeper until it reaches a diagnosis. The agent can examine many systems concurrently and return a concise answer in Slack. Its knowledge graph records relationships among teams, clusters, virtual machines, and deployments. A learning module remembers solved problems and guidance from engineers.
An agent must earn trust through restraint and inspectable reasoning
Pienaar says Cleric should avoid wasting an engineer's time when it is uncertain. The team found that concise findings work better than sending people to a web interface or presenting every raw metric and dashboard. Engineers can open an investigation to inspect the reasoning and the tools used when they need more detail. Confidence scores become useful when past high-confidence answers have usually been correct. Follow-up actions such as rerunning with feedback or proposing a solution give the team positive and negative signals for improving the agent.
Engineers need to teach and control the agent in their normal workflow
Pienaar says engineers onboard an agent much like they onboard a new teammate. Cleric supports questions and follow-up dialogue in Slack, extracts services and facts from those conversations, and remembers feedback from actions such as rerunning an investigation. Teams can also provide specific instructions for particular services, clusters, and conditions. This local control gives engineers a way to guide the agent instead of treating it as an external system. Repeated custom tools and instructions can reveal capabilities that belong in the core product.
Tool design determines how much of infrastructure an agent can understand
Production systems expose APIs, command-line interfaces, dashboards, logs, traces, and structured data, but these inputs vary in difficulty. Logs are relatively easy for language models to search and correlate. Metrics are harder because engineers often compare many service graphs and infer causal links between changes. Cleric needs tools that reduce the search space to relevant services rather than forcing the agent to inspect everything. Pienaar also points to an ACI layer used in code-generation systems such as SWE-agent and OpenHands as an example of giving an agent a more uniform view of a large tool environment.
Confidence should come from repeated experience rather than an LLM score
Pienaar argues that an LLM should not blindly assign confidence to every alert. Cleric classifies, enriches, tags, and labels incoming events, then stores successful investigations and their resolutions. When a similar event returns, the system retrieves those memories and can say it has solved the problem repeatedly. The difficult part is deciding which dimensions to use for those labels, because the agent may be reliable for one kind of incident and weak for another. Confidence therefore depends on matching the current event with relevant past runs.
Shared learning could turn local incident knowledge into wider patterns
Cleric currently learns inside an individual customer or team through its tools, context, and operating guidance. Pienaar wants to generalize those lessons to organizational, industry, and universal patterns. A solution to a zero-day vulnerability in one environment could then benefit other customers. This requires extracting useful behavior from local investigations and adding it to the broader product rather than leaving every team to solve the same problem independently.
Full autonomy means proving each incident class before allowing remediation
Cleric's proposed path to autonomy moves through accurate plans, findings, diagnoses, and fixes for defined classes of production problems. Pienaar does not claim that every unusual event can be anticipated, since black swan incidents will remain. The immediate focus is diagnosis. The next step is remediation for selected classes with enough confidence for closed-loop resolution. The longer-term goal is to identify failures before they happen and move beyond reacting to alerts. In the question session, Pienaar confirms that Cleric triggers automatically from infrastructure events, but it still requires human action before resolving issues.
