On August 26, 2026, Anthropic published what looks like a startup field note on the Claude blog: How Warp builds self-improving agents on Claude, by Michael Segner. There is no new model launch and no fresh leaderboard score. Instead, the piece explains how Warp—an AI-powered terminal and agentic development environment—turned “user feedback that vanishes when a session ends” into a durable self-improvement loop other teams can copy.
According to the article’s public “quick pitch,” Warp was founded in 2020 by CEO Zach Lloyd; its stack includes Rust, Golang, GitHub Actions, an internal orchestration platform called Oz, and the Claude Platform. It reports $73M raised, about 800K monthly developers, usage at 56% of the Fortune 500, 10M Claude Code sessions inside Warp to date (400K+ per week), and 40M total Warp Agent conversations. Those figures are vendor-side disclosures, not third-party audits.
This commentary is less about “a chatbot in a terminal” and more about a product philosophy Anthropic is now marketing in the open: pull domain knowledge out of raw prompts into versioned skill files, then run an observer skill that consumes human feedback, proposes a small edit, and ships it through a normal PR—so an agent’s progress is reviewable, mergeable, and revertible like code.
What Warp actually built
The official story starts from a familiar failure. Warp’s internal code-review agent was noisy: engineers complained about unhelpful comments and low-quality output. Manually rewriting prompts helped but did not scale. Improving context files such as AGENTS.md helped only partly. The real diagnosis: feedback to an agent usually disappears when the session ends, stripping critical context from the loop.
Their answer is an Agent Skills–based self-improvement framework that is almost aggressively simple:
The inner / base skill holds domain knowledge and instructions. When a PR opens, the review agent runs from that skill plus repository context.
Human feedback sits in the middle. A thumbs-up works; specifics work better. Zach Lloyd’s example: instead of “good comment,” say “you suggested renaming this, but our convention for this kind of global is X”—teach the next run how to do it right.
The outer / improver skill runs on a schedule, not per task. It pulls accumulated feedback, compares what the agent suggested with how humans responded, and proposes a small, focused edit to the base skill. Because skills are plain files, agents are good at editing them; the updates are reviewable and mergeable through a normal PR. Once merged, the next inner-skill run inherits the improvement.
Warp now runs the pattern across its open-source repo—spec-writing, review, and triage agents each carry their own loop. Lloyd is quoted on the core idea: file-based skills encode knowledge agents can look up without stuffing it into the prompt; the beauty is the simplicity of a domain skill plus an improver skill.
The post also lists practical writing advice: principles over brittle rules; explain the why; capture feedback where people already work (PR/issue comments) with no extra form; keep skills small with progressive disclosure; prefer feedback quality over volume while still valuing volume; invest extra effort in the improver because it reuses across agents. It draws a sharp line: skills are procedural and stable—“how to do X,” changed deliberately—while memory is auto-written at inference time and never stops changing. Feedback can be wrong, so do not accept it blindly: give the agent context to sanity-check, filter whose input counts, and keep a human at filtering or final review.
The clearest demo is the issue triage agent. A new GitHub issue fires a GitHub Action: the agent judges complexity and feasibility, assigns labels, and suggests a fix direction. The inner skill defines what labels mean and how to research the codebase first. In a sample, the first pass was solid but missed ready to spec—a signal that a contributor can start product and technical specs. A maintainer commented on the issue with both the expectation and the reason. The outer improver, scheduled inside Oz as an “update triage” agent, authenticated to GitHub, ran a Python script bundled with the skill to pull recent issues with feedback, summarized them to JSON, read that back, and opened a PR with the smallest edit that would apply ready to spec when a real problem is described even if UI/UX shape is not yet defined. Humans review and merge; the next triage run inherits the knowledge. That merge step is framed as both the loop’s close and the proof that people still control what changes.
Why this is more than another prompt tweak
For two years, agent products have often failed not because models were dumb, but because organizational knowledge would not stick: prompts lived in someone’s notes, wins would not reproduce, and failures vanished with the chat window. Warp’s pattern engineers improvement itself—the object is a file, the channel is a PR, the trigger is a human signal left in the original work surface.
For developers, it is a copyable scaffold: inner skill + outer improver + human merge. It reduces dependence on a single “prompt whisperer” and turns house conventions into git history. For enterprises, the audit story is attractive: who changed agent behavior, on which feedback, and when it took effect can be traced in the repo. For end users, the indirect bet is less noisy assistants that actually learn local convention—if the product writes stable procedure back into reviewable files rather than only auto-memory.
Technically, the novelty is less a new algorithm than a control plane: Claude Platform skills as deployable units, Oz as a scheduled observer, GitHub as feedback bus and change gate. The public piece does not show before/after accuracy tables, mislabel curves, or improver PR reject rates; “better” largely rests on mechanism narrative. That is the honest boundary of this genre: it sells a reusable pattern, not a reproducible experiment.
Who else is fighting over “agents that get smarter”
OpenAI, Google, and Microsoft all pitch memory, custom instructions, and enterprise knowledge stores; Cursor, Claude Code, and other coding agents pile on context engineering and hooks. By hosting Warp’s story, Anthropic marks “file-based skills + improver loop” as a showcase pattern for the Claude ecosystem—distinct from chat memory or pure RAG, which more often emphasize fact retrieval than versioned procedural knowledge.
Against the “bigger model” arms race, this is a second front: whoever first gets customers to encode conventions into mergeable skills raises switching costs. The story also rhymes with Anthropic’s own Claude Tag and Managed Agents messaging—pushing agents from one-off chats toward operable systems. The buying question for the next six months will sound less like “what’s your single-task score?” and more like “do agent behavior changes ship as PRs? can bad feedback poison the global skill? can improvers be split by domain?”
Risks, limits, and doubts worth keeping
Officially flagged: feedback can be wrong; do not accept it blindly; quality beats volume but volume still helps; if the domain is verifiable, build the harness first; if not, restrict human feedback to domain experts.
Not proven in the public piece: migration cost outside Warp’s own environment; whether “smallest edits” drift into contradictory rule piles over long horizons; how noisy feedback is weighted when hundreds contribute and thousands of reviews land; and how tightly Oz plus Claude Platform creates lock-in.
Author’s read: the commercial motives are clear—Anthropic needs Claude Platform to look like a home for self-improving agent products, not merely a model pipe; Warp needs its terminal to look like a distinctive harness, not a chat skin. The cultural risk is real: treating skills as code also imports “prompt politics” into code review—who may change global review conventions becomes a new organizational friction. Without golden sets or deterministic evals, self-improvement can become “whoever comments loudest rewrites the rules.”
Where I land
I buy the parts that keep feedback in PRs/issues, land improvements as reviewable files, and leave humans on the merge gate—that is more engineering than the slogan “turn memory on.” The ready to spec triage example is especially strong: the gain came from one maintainer comment that explained why, not from a thousand thumbs.
I stay skeptical because the case lives inside Warp’s own open-source repo and orchestration platform—tooling-rich and culturally homogeneous. In orgs with messy permissions, drifting label taxonomies, and seniors who will not write long comments, the same framework may first emit low-quality skill PRs and raise review load. The public article also never tells you how much metrics would degrade if the loop were switched off.
The next six to twelve months
If “inner skill + outer improver + human PR” becomes default Claude-ecosystem teaching material, competition will shift from single-task success rates to governance of skill assets: versioning, permissions, eval gates, and reusable improver templates across agents. OpenAI and Microsoft will answer with their own memory / custom GPT / Copilot Studio stories; open-source coding agents will compete on observability and rollback.
For readers, acceptance tests can be concrete: do you treat agent behavior changes as code changes? is there a filter that rejects bad feedback? do you run a small regression set before merging a skill? Whoever productizes those answers is selling compounding agents—not a weekly prompt-theater revival.