How Software Factories Improve Themselves — Suraj Gupta, Warp
Siraj Gupta of Warp outlines three practical ways software factories can improve over time: self-updating skills driven by outer-loop agents with pull-request review, versioned and traceable persistent memory that works across harnesses, and cost-aware model routing with custom rules and evals.
Siraj Gupta, who leads harness development at Warp, argues that most of the conversation about self-improving agents and software factories centers on individual agents, while little attention goes to how the factory itself gets better over time. He organizes the talk around three concrete mechanisms: self-improving skills, persistent memory, and model routing. Each is illustrated with Warp’s open-source client repository, which runs as a software factory.
Skills that improve themselves
Skills give agents procedural memory, a described procedure the agent follows across many similar tasks. Gupta uses a triage agent as the example: it may have a skill describing how to reproduce issues, but that skill goes stale as humans give feedback and the agent learns from its own trajectories. His answer is an outer-loop agent that watches the inner-loop triage agent’s runs. It collects signals such as thumbs up or down on issues, user comments, and comments from Warp employees, then synthesizes them into an updated skill. The workflow fires on every new GitHub issue, and the triage agent decides whether information is missing, whether the issue duplicates an existing one, or whether it is worth building.
The design point that matters most is that the outer-loop agent’s changes land as a pull request. Every revision to the skill is tracked in Git, giving full observability into how it evolved, and a human reviews each update so the outer loop cannot introduce mistakes that degrade the inner loop.
Persistent memory
Skills cover procedures, but not everything else. Gupta describes a Sentry agent that finds and fixes an issue, then encounters a similar one later. It might rediscover the same root cause by luck, but usually it burns tokens regathering context it already had. Persistent memory addresses this with a fact store scoped to an agent. An outer-loop agent extracts facts, learnings, and outcomes from inner-loop runs so future runs can build on past work.
In Oz, Warp’s cloud agent platform, memory stores are versioned and traceable. Each memory links back to the run that produced it, so a human can judge whether it is useful or is a local maximum to discard. People can also create, edit, or delete memories directly, though the creation loop is primarily agent-driven. In the demo, a Sentry agent reported that it had drawn on five memories to speed up its root cause analysis. Gupta stresses that memory works across harnesses, including Warp’s own harness, Claude Code, and Codex, and that memories are created automatically regardless of which one runs the agent.
Model routing
Gupta’s starting point is cost. Running every agent on a top-tier model like Opus becomes prohibitively expensive for simple work such as triage or minor CI fixes, and organizations have been burned by this. Warp’s auto models are a sensible default for newcomers, since Warp continuously re-evaluates which models sit on the Pareto frontier of cost and quality as new ones ship. Experienced teams can write their own routing rules as configuration. In his example, database migrations go to GLM, and runbooks and API documentation go to Qwen.
Gupta admits that writing these rules is ‘more of an art than a science.’ The next step is customer-facing evals, so teams can compare models such as Haiku, GLM, and Opus on their own task classes rather than on generic public benchmarks. Warp already does something similar internally. An eval sidecar uses a best-at-k approach: when a prompt comes in, several agents run across different models, and the results showed that UI tasks perform well on GLM, so they do not need Opus.
Takeaway
Taken together, skills, memory, and routing each close a feedback loop in which the factory learns from its own operation, with human review and traceability built in. Gupta frames this as a core part of the future software engineer’s job: moving from building products to building and maintaining the factories that build them.