Self-Improving Agents, Without Retraining — How Warp Turns Human Feedback Into Skill Files (2026)

Warp is an AI-powered terminal and agentic development environment built on the Claude Platform. For scale: $73M raised, 800K monthly developers, 56% of the Fortune 500, 40M Warp Agent conversations, and — a striking number — "10M Claude Code sessions run inside Warp to date, 400K+ per week."

The problem was an unpopular internal agent

Warp's code review agent was annoying its own engineers. They "complained that their agent made unhelpful comments and produced low-quality output." The article states the general form crisply: "A first-pass prompt that gets 80% of the task correct can create a noisy and annoying experience for the user."

Two stopgaps came first, and both are the ones most teams try. Manually rewriting the prompt after each observed failure "made output more usable but didn't scale." Improving context files "like AGENTS.md also helped, but was far from a complete fix." The general version of that ceiling is covered in why agents ignore the instruction files you wrote.

The inner skill holds the knowledge

The base skill "holds the functional domain knowledge and instructions." When a PR opens, Warp's code agent runs against that skill and produces its review.

Zach Lloyd, Warp's founder, describes why the file form matters: "File-based skills are a way of encoding knowledge for agents without putting that knowledge directly in the prompt, as something the agent can simply look up in the course of doing its job."

The improver skill is an observer, not a participant

This is the part that makes the loop work, and the scheduling detail is easy to miss. The outer skill "functions as an observer agent that runs on a schedule rather than per-task. It pulls the accumulated human feedback, compares what the agent suggested against how humans responded, and proposes a small, focused edit to the base skill."

Not per-task. On a schedule. It is a separate job looking at a corpus, not a reflection step bolted onto each run.

What it wants from humans is specificity. Lloyd's example: "A human could affirm, 'this was a good, useful comment'. But the human could also give detailed reasons why a code review wasn't good. Specifics like 'you suggested renaming this variable, but our code base convention is this type of global variable uses this particular naming context' tell the agent how to do it right next time."

The loop closes through code review

Here is the property that makes this more than a clever trick: "Because skills are plain files, agents are extremely good at updating them. These updates, which are reviewable, approvable, and mergeable, can flow through a normal PR/code-review workflow; once merged, the next run of the inner skill inherits the improvement."

Warp's issue triage agent shows it end to end. A GitHub Action fires an agent that analyzes a new issue for complexity and feasibility, assigns labels, and suggests a direction. On one issue it missed the ready to spec label. A maintainer left feedback on the issue itself — "exactly where the work was happening" — explaining both what he expected and why.

The improver then ran in Oz, Warp's agent orchestration platform, as a scheduled "update triage" agent. It authenticated to GitHub, ran a Python script bundled with the skill to pull recent issues carrying feedback, summarized them into a JSON file, and read that back into context. It then "opened a PR editing the inner skill to apply the 'ready to spec' label when an issue describes a real problem, even though the exact UI or UX shape is not yet defined."

And then a person merged it. Anthropic's framing of that step: "That final human step closes the loop and keeps a person in control of what actually changes."

Warp now runs this across its whole open-source repo, with separate spec-writing, review, and triage agents each carrying their own loop — "hundreds of people contributing and we're doing thousands of code reviews."

The pattern is convincing. The evidence for it is a vendor case study, and it is worth being precise about the difference.

No before-and-after numbers are given. The article reports no measured improvement in review quality, triage accuracy, or complaint volume. The impressive figures — 800K developers, 10M Claude Code sessions — describe Warp's business, not the loop's effect size. Nothing here quantifies how much better the agents got.

Warp is unusually well-equipped for this. A public repo with hundreds of contributors already leaving PR comments is a feedback corpus most teams do not have. Oz is an in-house orchestration platform for scheduled agents. Strip out either and the loop needs replacing with something you build.

The domains chosen are the friendly ones. Code review and issue triage have an existing review ritual and roughly checkable outputs. Warp's own guidance concedes the hard case directly, advising you to ask "Is your domain verifiable?" and, if not, to "Lean on deterministic evals against golden outputs wherever they exist."

It is not autonomous self-improvement. Every change is a PR a human merges. "Self-improving" describes where the proposals come from, not who decides.

Warp assumes the feedback will be wrong sometimes. Their answer, quoted in full because it is the most useful line in the piece: "Assume it will be. Don't let the agent accept feedback blindly — give it context to sanity-check, filter whose input counts, and keep a human in the loop at either the filtering or final-review stage."

And it is a procedural loop, not a memory system. This one is important enough that Anthropic put it first in the article's own FAQ, under the heading "Are you conflating skills with memory?" The answer: "Skills are procedural and stable—'how to do X,' run-agnostic, changed deliberately. Memory is auto-written by the agent at inference time and never stops changing."

That is the same distinction we have argued for in why Agent Skills aren't memory, stated by the vendor. It matters here because it tells you what the loop improves: how the agent performs a task. Not what it knows about your project.

"Skills are memory now." The article says the opposite, in a heading. A skill is stable procedure you change on purpose; memory is written at inference time and never stops changing. Warp's loop makes the procedure improve — deliberately, through review.

"The agent improves itself." A human merges every change. Remove that step and you have an agent editing its own instructions unsupervised, which is a different and worse system.

"Two files is all it takes." You also need a place feedback lands, a scheduler, and something that pulls the corpus into context — in Warp's case a GitHub Action, Oz, and a bundled Python script.

"More feedback is better." Warp's position is quality first: "You can get really good signal even from a relatively small sample size if it's very detailed feedback from a person around domain specific knowledge that the agent otherwise would have no way of getting." And for unverifiable domains, "restrict it to domain experts — don't open the floodgates."

"This replaces writing things down." It industrializes writing things down. The improver's whole job is to turn feedback into a durable file.

Two gaps open up when you try to copy this outside Warp's setup, and both are about the corpus rather than the skills.

The first is that the improver can only work from feedback it can reach. Warp's is in PR comments because that is where their work happens. If your corrections land in Slack threads, review calls, and someone's head, there is nothing for a scheduled job to pull.

The second is the one the vendor's own distinction points at. Skills hold procedure. They are the wrong container for the facts a correction usually contains — why the convention exists, what you already tried, which constraint made the obvious answer wrong. Warp's example correction carries all three: the naming convention, the category it applies to, and the reason. The procedure goes in the skill. The reason has nowhere to go.

That is what MemoryLake holds: your project's durable facts in a layer your agents query, so procedural knowledge and factual knowledge stop competing for the same file. Setup is three steps.

Step 1: Create an API key

Sign in and create an API key. One credential across the tools you connect.

Step 2: Upload your first memories

Short entries, one claim each. The corrections you have already given are the best possible source material:

The convention plus the reason. "Global config values use CFG_ prefixes because the loader greps for them at boot." The rule can live in a skill. The reason stops the rule being reverted.

Approaches already rejected here. The category that appears in no skill file and no commit message, and gets re-proposed on every fresh session.

Corrections you have given more than once. If you have said it twice, it is a fact about your project, not a preference about that task.

Environmental constraints nothing announces. The test that only fails in CI, the undocumented rate limit, the ordering dependency between two jobs.

Step 3: Connect your AI & agents

MemoryLake is reachable over MCP and over an API, so MCP-native agents — Claude, Claude Code, Codex, and OpenClaw among them — connect by pointing at the MCP server, while other assistants read the same memory through the API. An improver-style job can query it for context before proposing a change, which is exactly the sanity-check Warp recommends.

Three honest limits, and the first one matters most here. This is not a substitute for the loop. Anthropic's distinction cuts both ways: a memory layer does not hold procedure, and skills do not hold facts. If you want your agents to get better at a task, build the loop — Warp's design is good and the PR-review step is a genuine advantage a memory layer does not have. MemoryLake does not write your skill files and has no view into your agent's runs. And it holds only what you or your agents put into it, so Step 2 is deliberate.

Feedback stops being disposable. A comment becomes a file edit instead of a message someone scrolls past.

Improvements arrive as pull requests. Reviewable, revertable, attributable — which is more than most agent tuning offers.

"Explain the why" becomes a work habit. Warp's advice to write principles rather than rules only pays off if the reasons are recorded.

The improver becomes reusable. In Lloyd's words, "the improver skill for a code review agent is not that different from the improver skill for any other agent."

Skills stay small on purpose. Progressive disclosure and bundled resource files, not one growing document — the same pressure described in what coding agents actually read.

Facts and procedure stop fighting. The skill says how; something else holds why.

Pick a domain with an existing review ritual. Code review and triage work because someone was already going to look.

Capture feedback where the work happens. Warp's rule: "Low friction is what keeps signal flowing."

Insist on the why, not just the verdict. A thumbs-down does not say what to change. Warp's own example correction is a sentence long and contains a rule, a category, and a reason.

Schedule the improver; don't run it per task. It needs a corpus to compare against, not a single interaction.

Keep a human on the merge. This is the step that makes the whole thing safe to run.

Assume some feedback is wrong. Filter whose input counts and give the agent context to sanity-check against.

Write principles, not rules. "Construct the skill as though you're instructing a smart person, not like you're programming a computer."

Build the verification harness first if your domain allows one. Then let the agent tune against it.

Keep the facts out of the skill file. Procedure is stable and deliberate; facts accumulate and change — and the cost of keeping low-value ones active is measured in what a retention-scored memory tree showed.

Warp's pattern is the most practical thing published on self-improving agents in a while, mostly because it is boring in the right places. An inner skill holds the domain knowledge. An outer skill runs on a schedule, reads accumulated human feedback, compares what the agent proposed against what humans actually wanted, and opens a pull request editing the inner skill. A person merges it. The next run inherits the change.

What makes it credible is that nothing depends on the model getting better. Skills are plain files, agents are good at editing plain files, and pull requests already have a review culture around them. What should keep you honest about it is that no before-and-after numbers are published, Warp brought a large feedback corpus and an in-house scheduler to the problem, and their own guidance tells you to assume the feedback will sometimes be wrong.

And keep the distinction the article leads its FAQ with. Skills are procedural, stable, and changed deliberately; memory is written at inference time and never stops changing. A feedback loop makes your agent better at doing the job. It does not make it remember your project. You want both, in different containers — and the fastest way to start is to make your next correction include the reason, so that whatever reads it later has something worth keeping.