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 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. 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, Case states, Initiatives, Autonomy and limits, and The MCP server.
Questions: hello@perfloop.ai