> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt
> Use this file to discover all available pages before exploring further.
# The improvement loop
> Review feedback flows back into the SOP — the process gets better exactly where it failed, and every change is documented and approved.
Every reviewed case is feedback. An approval confirms the SOP handled that case correctly. A rejection with a comment marks a place the SOP got it wrong or said nothing at all.
The **improvement loop** is what turns that feedback into a better procedure: the agent reads the comments and approval outcomes across your cases, finds the patterns, and proposes a revision to the [SOP](/concepts/sops). A human approves the revision. The new version takes effect.
## The loop
Following the current SOP. Some resolve cleanly, some get flagged, some get it wrong.
Approve, reject, or mark for review — with a comment explaining the decision.
Ask it to look at recent review outcomes. It reads the comments and statuses across cases and looks for patterns: the same correction three times, a category of case that always ends up in `Needs review`.
As a concrete change with reasoning — "eight rejections in the last two weeks all correct the shipping method for AT deliveries; here's the rule I'd add, and here's where it goes in the priority order."
The revision is a document change you read and sign off on. Then the new version applies to every case that follows.
Ask for it in the chat when you want it:
> Look at the last two weeks of reviews in Order Match. What are the reviewers correcting most often, and what would you change in the SOP to fix it? Show me the proposed change.
## Why this shape
**It improves where it actually failed.** The feedback is attached to real cases with real documents, not to a hypothesis about what might go wrong.
**Nothing drifts silently.** The agent does not quietly change how it behaves because it saw a correction. It proposes; a person approves; the SOP file records what changed and why. If someone asks in six months why orders to Austria route the way they do, the answer is in the file's history.
**It compounds.** Each round moves cases from `Needs review` into clean automation — and the ones that stay flagged are increasingly the genuinely hard ones, which is where you want your reviewers' attention.
## Write comments the loop can use
The quality of the loop is the quality of your rejections. Name the rule, not just the mistake.
| Weak | Useful |
| -------------------------- | --------------------------------------------------------------------------------------------------------- |
| "Wrong" | "Wrong customer — two sites share this postal code; the VAT ID on the order distinguishes them." |
| "Bad shipping method" | "We never ship express to AT. Standard road, always, regardless of the customer's default." |
| "Should have flagged this" | "Two candidate items matched on description alone — that's never enough to auto-resolve; flag with both." |
The second column is a rule the agent can turn into an SOP line. The first is only a score.
When you find yourself typing the same correction a third time, that's the signal — ask the agent to propose the SOP change rather than fixing case four by hand.
## Relationship to agentic approval
They're two different mechanisms and they work together:
* **[Agentic approval](/concepts/review-approvals)** *enforces* the SOP. An approval agent checks each result against the procedure and the output, approving the clean ones and routing anything uncertain to a human.
* **The improvement loop** *evolves* the SOP, using what humans decided on the cases that reached them.
Enforcement without evolution means the same exceptions land on a human forever. Evolution without enforcement means a good procedure nobody applies consistently. Run both.
How the procedure is written and revised.
Where the feedback comes from — statuses, comments, approval gates.