Self-improving agent factories: outer-loop skill fixes, memory stores, model routing

The three patterns

1. Skills that improve (procedural memory). An inner-loop agent applies a skill, for example triaging new GitHub issues. A separate outer-loop agent watches the inner agent's runs, collects feedback (thumbs up or down, user comments, maintainer comments), synthesises what went wrong, updates the skill and opens a pull request. A human reviews it, so every change is tracked in git and the outer agent can't silently make the triage agent worse. Warp says its open-source client repository runs this way.
2. Persistent memory. A memory store is a fact store scoped to an agent. An outer-loop agent extracts facts, learnings and outcomes from the inner agent's runs so later runs don't re-gather context, for example root causes from past Sentry incidents. In Warp's Oz platform you can version, edit and delete memories, see which run produced each, and see which memories a later run used. They say memory works across harnesses, including Claude Code and Codex.
3. Model routing. Running every simple task (triage, CI failures) on the most expensive model is costly. Warp offers auto models and lets you define your own routing as a config file of rules: for example database migrations on one model, runbooks and API documentation on another. They run a best-of-k evaluation across models per task class (they report UI tasks do well on GLM) and plan customer-defined evals.

Caveats

• This is a vendor talk about Warp's Oz platform; the exact config syntax isn't shown in readable form, so copy the pattern, not the file.
• The speaker calls routing "more of an art than a science" today; don't treat any single model-to-task mapping as settled.
• The skill-improvement loop is only as safe as its review step: keep the pull request and human approval.