In this pattern an agent’s behaviour improves by editing a text file, not the model. A second, scheduled agent reads human feedback on the first agent’s work and opens a pull request that changes the skill file the first agent reads. There is no fine-tuning, embeddings store, or memory service.1
The problem it solves
Warp’s code review agent, used across roughly 800,000 monthly developers, kept making suggestions engineers had already rejected: the reviewer’s explanation lived in one session’s context and was discarded, so the next run read the same instructions.1
Two loops
| Inner loop | Outer loop | |
|---|---|---|
| Runs | Per task (every PR) | On a schedule, over many past runs |
| Reads | The skill file, the diff, repository context | Accumulated feedback and the skill file |
| Produces | The code review | A small, focused edit to the skill file |
| Applied by | Immediately, in the session | A pull request a person merges |
As described in the source.1 The outer skill never does the task; it compares what the agent suggested with how people responded and proposes an edit.1
Feedback quality over volume
A thumbs-down says the output was wrong but not why. A comment such as “our convention is that this kind of global variable uses this naming pattern” states a rule the improver can write into the skill. A small amount of detailed feedback from a senior engineer is worth more than a large volume of cursory ratings.1
Adopting it
- Keep the agent’s instructions in a file in the repository.
- Capture feedback as text, attached to the run it answers.
- Write the improver as its own skill: read feedback since the last run, compare with the skill file, propose one small edit, open a PR.
- Schedule it; per-task improvement has too little evidence and churns.
- Review the PRs, rejecting one reviewer’s preference presented as team convention.
Where it breaks down (analysis from the source)
The note’s author lists: skill files that grow into long, partly contradictory lists without periodic pruning; overfitting to the people who write the most feedback; product complaints turned into skill rules; and no measurement after merge, so a bad change shows up only slowly in later feedback.1
Related
- Agents propose, people and policy accept: why the improvement is a PR.
- Source: How Warp Builds Self-Improving Agents on Claude