WEBVTT

1
00:00:01.300 --> 00:00:07.639
This is Anthropic, Read Aloud. Today: How Warp builds self-improving agents on Claude.

2
00:00:08.939 --> 00:00:11.809
How Warp builds self-improving agents on Claude.

3
00:00:12.259 --> 00:00:18.275
How Warp devised a simple development pattern that anyone can use to create self-improving agents.

4
00:00:18.725 --> 00:00:22.854
From Claude Blog, published August 26, 2026.

5
00:00:23.854 --> 00:00:35.389
In our series,, we highlight how startups are transforming their industries with A I. In this article, we share how Warp turned stateless user feedback into a self-improvement loop for its agents.

6
00:00:35.839 --> 00:00:37.151
Table with 6 rows.

7
00:00:37.391 --> 00:00:38.695
Header: The quick pitch.

8
00:00:38.935 --> 00:00:40.589
The quick pitch: Name; Warp.

9
00:00:40.829 --> 00:00:43.530
The quick pitch: Founded; 2020.

10
00:00:43.770 --> 00:00:46.574
The quick pitch: Founders; Zach Lloyd (C E O).

11
00:00:46.814 --> 00:00:54.649
The quick pitch: Stack; Rust, Golang, GitHub Actions, internal agent orchestration platform (Oz), Claude Platform.

12
00:00:54.889 --> 00:01:14.750
The quick pitch: Growth; 73 million dollars raised. 800 thousand monthly developers build on Warp. 56 percent of the Fortune 500 uses Warp. 10 million Claude Code sessions run inside Warp to date, 400K+ per week. 40 million total Warp Agent conversations..

13
00:01:15.200 --> 00:01:36.078
Agents need to handle recurring tasks reliably and effectively. A first-pass prompt that gets 80 percent of the task correct can create a noisy and annoying experience for the user. Warp learned this the hard way, and used this to inform its product strategy, creating an improved experience for nearly 1 million developers worldwide.

14
00:01:36.528 --> 00:01:54.762
Warp, the A I-powered terminal and agentic development environment, builds on the Claude Platform. The team ran into this “noisy experience” problem with their internal code review agent. Engineers complained that their agent made unhelpful comments and produced low-quality output.

15
00:01:55.212 --> 00:02:12.042
The team initially tried stopgap solutions, like manually rewriting the prompt based on observed code review failures. This made output more usable but didn’t scale. Improving context files like AGENTS.md also helped, but was far from a complete fix.

16
00:02:12.492 --> 00:02:34.370
Ultimately, they realized, the real issue was that feedback to an agent, no matter what its purpose, typically disappears when the session ends, removing critical context from the agentic loop. Their solution: an Agent Skills -based framework to create self-improving agents where feedback compounds over time to continually refine and enhance agent output.

17
00:02:34.820 --> 00:02:38.941
Read on to learn how they built it with skills on top of the Claude Platform.

18
00:02:39.741 --> 00:02:42.292
Agent self-improvement loops built on skills.

19
00:02:42.742 --> 00:02:58.914
The central technique is a self-improvement loop using skills, which are file based encodings of knowledge that keep instructions out of the raw prompt. Warp evolved a self-improving agent architecture consisting of two skills, with human feedback in between.

20
00:02:59.364 --> 00:03:12.137
The inner/base skill holds the functional domain knowledge and instructions. For example, when a P R is opened, Warp’s code agent executes using that base skill and context to produce its review.

21
00:03:12.587 --> 00:03:22.995
Human feedback on agent output is a critical component for the self-improvement loop. For code review this could be something as simple as a thumbs up, but the more explicit the better.

22
00:03:23.445 --> 00:03:45.929
“A human could affirm, ‘this was a good, useful comment’,” Warp founder Zach Lloyd explains, “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.”

23
00:03:46.379 --> 00:04:03.131
The outer/improver 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.

24
00:04:03.581 --> 00:04:20.057
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 P R/code-review workflow; once merged, the next run of the inner skill inherits the improvement.

25
00:04:20.507 --> 00:04:30.789
Warp now runs this pattern across its entire open-source repo, with separate spec-writing, review, and triage agents, each carrying their own self-improvement loop.

26
00:04:31.239 --> 00:04:51.674
“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,” says Zach. “The framework is really simple actually: there's the base domain-specific skill and then there's the improver skill that refines that domain-specific skill.

27
00:04:51.794 --> 00:04:54.410
This simplicity is the beauty of this approach.”

28
00:04:55.210 --> 00:04:57.695
How to write self-improving skills for agents.

29
00:04:58.145 --> 00:05:04.203
Here are some of the Warp team’s tried and true tips for writing self-improving skills for agentic loops:

30
00:05:04.653 --> 00:05:20.760
Write principles, not rules. "Construct the skill as though you're instructing a smart person, not like you're programming a computer,” Zach says. “Including direction in the skill like ’Look for repeated code’ provides better direction than exhaustive variable naming rules.”.

31
00:05:21.000 --> 00:05:32.040
Explain the why. Providing the rationale behind the rule lets the agent reason about the problem instead of following rigid instructions, again allowing for better generalization.

32
00:05:32.280 --> 00:05:52.974
Make feedback effortless to give. Capture it where people already work, like by commenting directly on a P R or issue. Also, make this happen automatically, with no extra submission step. “Low friction is what keeps signal flowing,” Zach notes. “If you make it too hard you're not going to get the feedback and you're not going to be able to improve the skill.".

33
00:05:53.214 --> 00:06:04.328
Keep skills small and use progressive disclosure. A good skill file isn't large; it references resource files and scripts rather than dumping everything into context at once.

34
00:06:04.568 --> 00:06:18.450
Feedback quality > volume, but volume helps. A small amount of detailed, domain-specific feedback from a senior engineer can be worth more than lots of cursory feedback because binary thumbs up/down doesn't say why.

35
00:06:18.570 --> 00:06:40.125
“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,” Zach continues. “That said, the bigger the corpus of quality signal, the better. At Warp we're using a loop to manage our whole open source repo.

36
00:06:40.245 --> 00:06:44.640
We have hundreds of people contributing and we're doing thousands of code reviews.”.

37
00:06:44.880 --> 00:06:58.938
Put extra effort into the improver skill. Putting extra effort into writing the improver skill (the observer agent) pays off beyond the immediate agent loop, because improver skills are very reusable across different use cases.

38
00:06:59.058 --> 00:07:10.983
“Outside of the domain specific knowledge component, this is a fairly reusable mechanism, the improver skill for a code review agent is not that different from the improver skill for any other agent.”.

39
00:07:11.783 --> 00:07:14.624
The loop in action: Warp’s issue triage agent.

40
00:07:15.074 --> 00:07:34.018
Warp’s issue triage agent demonstrates the self-improving agent skills framework. The pattern is triggered whenever someone files a new GitHub issue: a GitHub Action fires an agent that analyzes the issue for complexity and feasibility, assigns labels, and suggests a direction for the fix.

41
00:07:34.138 --> 00:07:43.364
That triage agent runs off an inner skill file holding the domain knowledge about what each label means and how to research the codebase before acting.

42
00:07:43.814 --> 00:08:03.180
On a sample issue, the first-stage inner skill did a solid job but missed one label, ready to spec, which signals that a contributor can start building product and technical specs against the issue. A maintainer on the Warp team caught the gap and left feedback directly on the issue, exactly where the work was happening.

43
00:08:03.300 --> 00:08:11.223
Critically, he explained both what he expected and why he expected it: actionable feedback easy for the agent to absorb later.

44
00:08:11.673 --> 00:08:31.449
The outer improver skill runs in Oz, Warp's agent orchestration platform, as a scheduled “update triage” agent. The agent authenticated to GitHub, ran a Python script bundled with the skill to pull recent issues carrying feedback, summarized them into a Jason file, and read that back into context.

45
00:08:31.569 --> 00:08:39.505
The bundled script is itself a best practice; skills can reference resource files instead of writing fresh code on every run.

46
00:08:39.955 --> 00:08:59.777
From there, the agent identified the concrete feedback signals in the maintainer comments and proposed the smallest edit that captured them. It opened a P R editing the inner skill to apply the "ready to spec" label when an issue describes a real problem, even though the exact U I or UX shape is not yet defined.

47
00:09:00.227 --> 00:09:18.211
Because the whole update is a skill file, it moves through the normal code-review workflow. The P R arrived with a description explaining which signals prompted the change and what it altered. A human reviews, approves, and merges, and the next run of the triage skill inherits the new knowledge.

48
00:09:18.331 --> 00:09:23.869
That final human step closes the loop and keeps a person in control of what actually changes.

49
00:09:24.319 --> 00:09:35.857
This is the same mechanism Warp now runs at scale across its open-source repo, where spec-writing agents, review agents, and triage agents each carry their own self-improvement loop.

50
00:09:36.307 --> 00:09:52.478
Any agent, no matter what its task, gets better over time if you build one of these loops into it from the start to capture human feedback signals, turn them into skill updates, and expand agents from one-off helpers into capable systems that compound across your org.

51
00:09:52.928 --> 00:09:54.364
Table with 7 rows.

52
00:09:54.604 --> 00:09:56.870
Header: Best practices from the Warp team.

53
00:09:57.110 --> 00:10:12.330
Best practices from the Warp team: Are you conflating skills with memory?; 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..

54
00:10:12.570 --> 00:10:29.155
Best practices from the Warp team: Do you need one improver loop, or one per agent?; Meet in the middle: a templated base loop captures the overlap across your agents, with domain-specific weights layered on. A handful of improvers can each own one; a hundred should share..

55
00:10:29.395 --> 00:10:45.434
Best practices from the Warp team: What happens when the feedback is wrong?; 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..

56
00:10:45.674 --> 00:10:59.125
Best practices from the Warp team: Is your domain verifiable?; Build the verification harness first, then let the agent tune against it: generate a reference corpus, compare output to reference, fix, repeat..

57
00:10:59.365 --> 00:11:14.277
Best practices from the Warp team: And if it isn't domain verifiable?; Lean on deterministic evals against golden outputs wherever they exist. Where you must use human feedback, restrict it to domain experts, don't open the floodgates..

58
00:11:14.517 --> 00:11:29.839
Best practices from the Warp team: How do you know the whole system is improving?; Track the global metrics humans already eyeball, time to merge, contributor count, cost, and feed them back into the improver agents. Go crawl-walk-run on deployment..

59
00:11:30.289 --> 00:11:39.926
View the full webinar for a live demo and deeper discussion of how Warp uses Claude to build agents that learn from team feedback and improve themselves over time.

60
00:11:40.376 --> 00:11:42.633
Start building with the Claude Platform today.

61
00:11:43.633 --> 00:12:00.721
That was How Warp builds self-improving agents on Claude, from Claude Blog, published August 26, 2026. Read the original at claude dot com. This unofficial audio edition was generated automatically for the podcast Anthropic, Read Aloud.