# Steering and learning.

How to direct the work, and what Perfloop learns from the way you direct it. Those lessons are kept per repository.

Updated 27 September 2026.

## Feedback on a case

**Request changes** on the case page says what you want changed, with a reason, and files one review on the case. A coding agent does the same with `fileFeedback`. Requested changes also hold publication. A pending publication then shows your review on its approval, and one approval clears it and publishes. A publication that was already approved waits in Inbox with **Allow publication**, which clears the hold in one click, like an approval; neither asks for a reason. The next Session reads the feedback and may record one corrected candidate. If your feedback asks a question, the Session answers it on the case, under your review in the Timeline; the answer does not settle the review. When two Sessions in a row end without settling the same feedback, and neither was stopped by a person, the case waits for a person. **Work this case** starts it again, and new or changed feedback lets the next Session start on its own. Feedback never lowers the proof bar: the verifier reads it as a request to check.

Feedback on a pull request Perfloop opened works the same way. With PR feedback set to handle automatically, a comment or a review starts a Session when the code host says its author can push to the repository, and a failed check starts one by itself. Anything else waits in Inbox; on Cursor Origin, there is no push check.

## Scope

Repositories in scope are set in Setup; out of scope means no model upkeep and no cases. An [Initiative](https://perfloop.ai/docs/work/initiatives) gives the loop a direction: one outcome, the reasoning, and the targets and exclusions on the model. Its scope is those targets and exclusions, wherever they live — a repository, a service, a workload, a component, or any other model entity — so one Initiative can span repositories. Research proposes hypotheses within it, and triage and verification read it. A coding agent changes it with `editInitiative`.

## Closing with a reason

**Close case** records that the work stopped and asks why; `closeCase` does the same. It does not stop a Session that is already running; **Stop work** or `stopSession` does that. **Stop work** asks you to confirm first; the case stays open and keeps what the Session already recorded. The reason stays with the case, and Perfloop reads recent reasons before it proposes where to look next. Closing is not refutation: a new case on the same hypothesis stays possible, and **Reopen case** reverses a plain close.

When a pull request Perfloop opened is closed without a merge, Perfloop reads the discussion and decides whether the case closes or continues with another approach. When it cannot decide, the question comes to Inbox, and you answer there or with `decidePRClosure`.

## Ideas

`submitIdea` proposes a hypothesis from a coding agent: what should change, and where. Perfloop checks it against the model and admits it as a case or records why not; `submission` reads the outcome.

## What Perfloop learns from you

Perfloop learns your system from the code and your telemetry, and that is the model. From your feedback and the repository's review history it learns lessons, kept per repository. A lesson belongs to one repository, it can name the reviewer who raised the concern, and it names where it applies: everywhere in the repository, or a component, a service, a workload, or a source file inside it. A lesson with no target applies nowhere, and never repository-wide by default. A lesson can be corrected, and one whose basis is withdrawn is retired rather than deleted. Nothing learned in one workspace reaches another.

Lessons come from four places. Your feedback on a case: **Request changes**, or `fileFeedback` from a coding agent. Your feedback on a pull request Perfloop opened: the comments, the review threads, and the discussion when it is closed. A rejected publication, which is recorded as case feedback. And the repository's own review history, including reviews of work Perfloop did not write. The reason you give when you close a case stays with the case, and Perfloop reads it. A stopped Session, an exhausted budget, or a closed case is not evidence against the hypothesis.

What you explain in a review teaches more than a bare closure does: why the change was unwanted, the constraint it violated, and what would make another approach acceptable. A closure on its own supports no rule.

Triage reads the applicable lessons before it chooses what to work on next, the proposer reads them while it writes a candidate, and the independent verifier reads them too. A lesson can change what Perfloop tries first. It cannot make a weak candidate pass or waive a check, and it lowers no proof bar. It does not become one of your requirements, and it grants nobody a veto.

Perfloop learns from a repository's feedback when **Keep working** is on for it, and from its review history under **Keep working** or **Keep model current**. Both switches are on [Autonomy and limits](https://perfloop.ai/docs/work/autonomy#controls). You do not read the lessons; neither the app nor the MCP server shows them. What you see instead is Setup reporting **LEARNING** while Perfloop is updating its contribution policy, and the Usage page showing what that Session cost under **Learning**. Their effect shows up in the next case they apply to.

Also in this section: [The loop](https://perfloop.ai/docs/work), [Case states](https://perfloop.ai/docs/work/states), [Initiatives](https://perfloop.ai/docs/work/initiatives), [Autonomy and limits](https://perfloop.ai/docs/work/autonomy), and [The MCP server](https://perfloop.ai/docs/work/mcp).

Questions: [hello@perfloop.ai](mailto:hello@perfloop.ai?subject=Perfloop%20docs)