The Model Stayed Frozen. The Agent Got Better.

TL;DR for operators

Designer-RSI shifts one production decision: improving an agent does not always require improving its foundation model. The paper keeps the model, tools, renderer, and evaluator frozen and instead changes an external library of reusable operating procedures.

The strongest evidence is not simply that the library grows. On a fixed 200-brief ablation, adding new procedures alone produced a 49.4% win rate against the base agent, while rewriting existing procedures reached 48.6%. Combining both reached 58.5%, with completeness rising to 74.04. The operational lesson is that continual adaptation looks less like accumulating prompts and more like maintaining a system with separate processes for coverage, repair, retrieval, testing, and release.

For teams using proprietary or externally hosted models, this creates a potentially auditable adaptation layer without weight updates. But its safety mechanism is local: a candidate procedure is rejected when it causes an observed replay regression, not when it can be proven safe across the full deployment distribution.

A deployed agent accumulates problems faster than model versions change

Consider a team running a capable software agent against real customer requests. New task variants appear. Certain workflows fail repeatedly. Some tool sequences work but are unnecessarily brittle. The team may not control the underlying model weights, and retraining the model for every operational defect would be costly even if access were available.

Designer-RSI asks whether the learning object can instead sit outside the model.¹

Its setting is unusually demanding for that question. The agent controls equivalents of Photoshop, Illustrator, and InDesign through more than 230 tools and must produce structured, editable design artifacts. A successful result therefore depends on more than generating a plausible image: the agent must satisfy brief requirements, choose operations, manipulate document state, and complete the workflow.

The paper freezes the underlying model and execution environment. What changes is an external library of reusable natural-language instructions describing how recurring operations should be performed. The initial library contains 76 procedures distilled from product documentation.

That library becomes the system’s adaptive layer.

Improvement required both adding procedures and repairing them

Designer-RSI separates maintenance into two processes.

Widening looks for recurring tasks that existing procedures do not adequately cover. Recorded trajectories are grouped into canonical task labels, and a new procedure becomes eligible after the uncovered task appears at least three times.

Deepening starts from a different signal: repeated failure. It identifies procedures associated with unsuccessful executions, contrasts those trajectories with successful uses of the same procedure, and proposes targeted revisions or larger rewrites.

Across five evolution rounds, 1,406 non-overlapping briefs generated 1,869 graded trajectories. The bank expanded from 76 to 139 procedures. The gate considered 231 rewrite proposals and 136 candidates for new procedures, accepting 131 rewrites and 69 mints; later merging or supersession explains why net growth was 63 rather than 69.

The ablation is the more consequential result because it tests what part of that machinery matters.

Neither isolated mechanism beat the base agent on pairwise win rate. The paper reports a +3.85 superadditive interaction in completeness when they are combined.

This changes the interpretation of procedural memory. A larger library is not automatically a better library. New coverage introduces procedures whose weaknesses subsequently become visible in use; repair, in turn, can expose failures that are actually missing capabilities rather than faulty instructions. Acquisition and revision form a coupled maintenance loop.

The release gate is part of the learning mechanism

Generating a plausible update is not the same as deciding to deploy it.

Designer-RSI inserts a matched replay gate between proposal and admission. Candidate and incumbent procedures are rerun with upstream assets and context held fixed. Pairwise judgments are order-randomized, and a candidate is accepted only when at least one replayed case improves and no replayed case is detected as worse.

Conceptually, the shipping rule is:

This matters because the system is learning under an imperfect multimodal evaluator rather than a reliable programmatic oracle for design quality. Matching the replay context reduces one source of noise: a candidate should not appear better simply because it inherited easier upstream conditions.

For production teams, the broader pattern is more valuable than this particular gate implementation. Behavioral adaptation needs admission control. Versioned procedures can be proposed, replayed against incumbent behavior, accepted or rejected, and rolled back independently of model releases.

The boundary is just as concrete. Passing the gate means no regression was detected on the sampled replay cases. It does not establish global monotonic improvement.

The experiments show why that distinction matters. Evolution was not monotonic: round 4 fell below Base at the completeness-at-least-0.3 threshold even while retaining improvements in the higher-quality tail. Round 5 recovered after evolution shifted more heavily toward rewriting.

Cross-backbone results suggest the memory is not model-specific

On the fixed 200-brief internal benchmark using Claude-Sonnet-4, the round-5 bank raised the share of briefs reaching completeness of at least 0.9 from 43% to 56%. Exact completeness of 1.0 rose from 24% to 32%.

External results extend the comparison beyond one frozen model. Average generation-quality changes on four general text-to-image benchmarks were +3.83 for Claude-Opus-4.6, +7.70 for Claude-Sonnet-4, and +9.67 for Qwen3.6-27B. Individual cells did regress, so these averages should not be read as universal improvement.

On four specialized graphic-design benchmarks, Evolve beat Base with overall pairwise win rates of 67.6% for Claude-Opus-4.6, 61.8% for Claude-Sonnet-4, and 62.8% for Qwen3.6-27B.

The gains also have a particular shape. They concentrate more strongly in completeness than in aesthetics or critique counts. That suggests procedural memory is primarily helping the agent satisfy requested requirements and execute workflows reliably, rather than substantially changing its underlying visual judgment.

For operations, that distinction is useful. External procedures appear better suited to correcting how work gets carried out than to substituting for improvements in the model’s perceptual or aesthetic competence.

Treat procedural memory as a governed production asset

Cognaptus infers a practical maintenance model from these results.

When deployment traffic reveals a recurring uncovered task, consider creating a reusable procedure rather than immediately escalating to model adaptation. When an existing procedure repeatedly co-occurs with failure, inspect successful and unsuccessful trajectories and revise the procedure. Before release, compare the candidate against incumbent behavior on matched cases. Keep versions and preserve rollback.

This is especially relevant when the model is externally hosted or proprietary. The organization may be unable to fine-tune it, while still controlling retrieval, tool access, procedural instructions, evaluation, and deployment policy.

The paper also reports only modest mean latency overhead—roughly 3.4% to 6.2% across the tested backbones—and the fully evolved bank used fewer prompt and output tokens than the documentation-derived cold-start bank in the ablation. That weakens the assumption that a richer procedural layer must simply accumulate context indefinitely.

The business value is therefore not “self-improvement” in the abstract. It is a separately governable behavior layer whose changes can be inspected and released on a different cadence from model changes.

Procedure files stop helping when the missing capability is elsewhere

The study also exposes where this strategy runs out of leverage.

Natural-language instructions sometimes fail to override a model’s established default procedure. Fine geometric tasks remain constrained by perception and verification quality. Long procedures lose fidelity as errors accumulate across annotation, distillation, and execution. The paper’s personalization cases similarly do not establish that inserting a user-specific skill reliably enforces preferences.

Those failures point to different interventions: preference-aware retrieval, deterministic tool primitives, stronger verification, explicit plan orchestration, human review, or eventually model-level adaptation.

Evaluation is another constraint. The same frozen automated judge helps drive evolution and measure much of its progress. Internal user-derived prompts and trajectories are withheld, limiting reproducibility, and the main study does not include a completed human user evaluation. Some Qwen3.6-27B completion results are also affected by local deployment timeouts and connection failures.

So the paper supports a narrower conclusion than globally safe self-improvement.

A frozen agent can improve materially when reusable operational knowledge is treated as a maintained external system. The consequential design choice is not merely to give the agent more instructions. It is to build the processes that decide what procedure is missing, what procedure is failing, which revision should replace it, and what evidence is sufficient to ship the change.

That turns procedural memory from configuration into infrastructure.

Cognaptus: Automate the Present, Incubate the Future.