# The verification loop: Your coding agent writes the code. Cleric gets it to production.

> Cleric takes ownership after the PR: it refines, deploys, monitors, and verifies every agent-generated change in production, then feeds what it learns back to the coding agent.
>
> Markdown version of https://cleric.ai/verification-loop for AI agents and LLMs. Site index: https://cleric.ai/llms.txt

The page is a looping animation of about 37 seconds. It opens with the statement “Your coding agent writes the code. Cleric gets it to production.” and the subtitle “It verifies every change in production and resolves issues before they reach you.” The steps below describe it in order.

## The lifecycle

The animation follows a change through four stages:

1. **Developing:** the coding agent writes the change.
2. **Refining:** Cleric reviews and refines the PR.
3. **Deploying:** Cleric deploys the change.
4. **Verifying:** Cleric monitors production and verifies the change.

The coding agent owns Developing. Cleric owns the rest: “refines · deploys · monitors · verifies”.

## The problem

Coding agents made Developing fast, but everything after the PR is still gated by people:

- Developing: AI speed
- Refining: still human-gated
- Deploying: still manual
- Verifying: rarely tracked

Changes stream out of Developing and pile up at the manual gate. The counter climbs to 18 changes waiting after PR.

## Cleric works the pipeline

The backlog drains as Cleric takes over. The example change is a PR titled “Add Stripe support” (#482).

1. **The coding agent opens a PR.** It crosses from Developing to Refining.
2. **PR review.** Cleric rates the risk as Critical (checkout path touched). Of three findings, Cleric fixes two (circuit breaker, usage events) and a human reviews one (payment fallback). The success criteria are payments, latency, adoption, and error rate.
3. **Deploying.** Cleric deploys the change.
4. **Verifying.** Cleric monitors production against the success criteria:
   - System metrics: Stripe error rate (target < 1%) and Stripe p99 latency (target < 1s)
   - Business metrics: Stripe payment success (target > 99%) and Stripe adoption (target > 5%)

   On the first pass, the Stripe error rate rises to 2.3%, breaching its target, while p99 latency holds at 0.9s.
5. **Regression found.** Cleric routes the change back from Verifying to Refining.
6. **Cleric fixes.** Cleric refines the change again.
7. **Re-ships.** The fixed change deploys and goes back to Verifying. This time the Stripe error rate is 0.4%, p99 latency 0.9s, payment success 99.6%, and adoption 6.2%: all within target.
8. **Verified in production.** The change is verified.
9. **Learns for the next change.** Cleric feeds what it learned back to the coding agent at Developing.

## Close

“Merge the PR. Cleric owns everything until there’s a verdict.” The animation ends on the Cleric logo, then repeats.