When does an AI agent actually learn from experience?

The added note produced no extra passed checks.

Both conditions met 32 of 32 predefined checks across two sessions each. The baseline reached the rubric ceiling.

Four author-designed fictional cases, sixteen real task responses. This is neither a general success rate nor evidence of equivalence.

The system can change while model weights stay fixed.

Harness² refines the execution setup and retains improvement experience for subsequent tasks.

Provider-affiliated preprint; reported benchmark gains do not establish general production reliability.

A useful old procedure can interfere with a new task.

An NTU study found that experience representation and retrieval affected transfer in two simulated environments.

Two task pairs in ALFWorld and BabyAI; results are not a universal ranking of memory systems.

Reusable context needs a policy for updating it.

ACE separates producing work, extracting lessons and curating incremental context updates.

The authors also identify weak reflection and unnecessary context as limitations.

Training is a different route to better correction.

SCoRe trains self-correction through reinforcement learning.

Historical research on specified Gemini models; not a current-model comparison or a feature of this Atlas trial.

The same model can start with different guidance.

An agent is a model working within a system of instructions, tools, saved state and a program that coordinates its steps. This surrounding system is often called a harness. A stored experience can enter the next prompt, suggesting which source to check, which tool to call or which shortcut to avoid.

Saving where a task stopped supports continuity. Remembering a customer’s preference supports personalisation. Reusing a tested procedure can change how future work is done. None of these operations requires the model’s weights to change.

Training is another route. SCoRe, for example, used reinforcement learning to train better self-correction. In this article we examine changes outside the model: what the system records, loads and permits to influence its next action.

A finished task and an improved method are different outcomes.

Consider a research agent that finds a comparison between results obtained with different attempt budgets. It can fix the current sentence immediately. Reusing that experience requires another decision: what should a future agent check, and when?

Our recommended design separates those decisions. The work loop produces an answer or artifact. The improvement loop proposes a change and asks whether it earns its place. A runtime must read the files and execute the loop; a Markdown instruction alone does not enforce tool permissions or run a process in the background.

Our baseline already passed every check.

We tested a small part of that mechanism. One agent distilled earlier, editor-supplied research observations into a reusable note: distinguish metrics and check whether experiments can fairly be compared. It never saw the evaluation cases. The note came from supplied feedback; its author had not made and corrected those mistakes itself.

We then ran four fresh-context sessions: two with the common task instructions and two with the same instructions plus the note. Each answered four fictional research comparisons. The cases covered different units, extra attempts, a genuinely comparable result and a misleading task mix. We fixed the tasks and scoring criteria before running them.

A separate AI grader, unaware of which condition produced each response, found that both conditions met all 32 checks. Neither missed a scored distinction; neither falsely rejected the valid comparison. Under our predeclared rule, this gave us no reason to adopt the note, so we left it inactive.

The tie exposes a limit in our test.

The baseline already handled every distinction in the rubric. Once it reached the ceiling, the candidate could only match its score or fall below it. The tie does not establish that the note was ignored or had no value. It shows no difference on the checks we chose.

The cases were compact and self-contained. We did not test remembering unfamiliar facts, finding a note in a large library or recovering a long tool-based workflow. Exact backend version, inference budgets, latency and cost were not exposed; we cannot claim equal compute or an efficiency gain.

A useful next test would start from a recurring failure on unfamiliar work, then hold out new tasks for evaluation. Retesting the same examples until a favourite method wins would answer a different question.

Published systems change more than a single reminder.

Harness², a 2026 preprint from Google Cloud AI Research and Northwestern, proposes changes to the execution harness, runs them and combines changes supported by the resulting behaviour. A persistent improvement library helps guide later adaptations. The model weights remain fixed. Its reported benchmark gains involve more machinery and additional executions than our note-loading trial. The authors acknowledge extra inference cost, variable executions and shared model biases; transfer is not guaranteed.

ACE, from Stanford, UC Berkeley and SambaNova, separates generating work, reflecting on experience and curating a reusable playbook. It adds local updates rather than repeatedly rewriting the entire context. Its authors also identify a dependency: poor reflection can produce noisy or harmful guidance, while tasks that already have a simple adequate strategy may gain little from richer context.

A similar memory may leave out the crucial step.

Researchers Qisheng Hu, Quanyu Long and Wenya Wang at Nanyang Technological University studied experience reuse in ALFWorld and BabyAI. One task pair is revealing: “put X in Y” and “put a clean X in Y”. The wording is close; the required procedure differs.

In their experiments, transferring detailed old trajectories could carry over the simpler routine and harm the harder task. Abstract procedural insights transferred more reliably in the tested direction. Those findings concern two simulated task pairs, not every memory product.

For a builder, this suggests a distinction between finding a similar memory and finding one that applies. A useful record needs conditions: what was true, which action worked, how it was checked and when the lesson would be unsafe to reuse. A previously successful recipe still has to fit the present request.

Build the feedback path before growing the memory library.

For a first implementation, we would use a runtime, a small versioned store and checks tied to observable outcomes. Keep the user’s decisions, current task state and candidate methods separate. Load only records that apply to the task. Save actions and results with their source and date, then propose a reusable method when there is a concrete problem to investigate.

This keeps the learning decision open to inspection. A proposed note can remain a proposal; a check can fail; a method can be retired. Budget and action permissions belong outside the part of the system that proposes its own improvements.

An improving system must be able to keep less.

Anthropic engineer Prithvi Rajasekaran describes simplifying a long-running coding harness by removing components individually and checking what changed. His account treats each component as an assumption about a model limitation—an assumption that may become outdated. It is a provider’s engineering experience, not an independent universal recipe.

Our own comparison supports a narrower decision: keep the baseline under this protocol. The ceiling leaves the note’s value on harder work unresolved. A useful improvement process can keep a candidate inactive while identifying the test that would make the next decision informative.

The added note produced no extra passed checks.

Both conditions met 32 of 32 predefined checks across two sessions each. The baseline reached the rubric ceiling.

Four author-designed fictional cases, sixteen real task responses. This is neither a general success rate nor evidence of equivalence.

The system can change while model weights stay fixed.

Harness² refines the execution setup and retains improvement experience for subsequent tasks.

Provider-affiliated preprint; reported benchmark gains do not establish general production reliability.

A useful old procedure can interfere with a new task.

An NTU study found that experience representation and retrieval affected transfer in two simulated environments.

Two task pairs in ALFWorld and BabyAI; results are not a universal ranking of memory systems.

Reusable context needs a policy for updating it.

ACE separates producing work, extracting lessons and curating incremental context updates.

The authors also identify weak reflection and unnecessary context as limitations.

Training is a different route to better correction.

SCoRe trains self-correction through reinforcement learning.

Historical research on specified Gemini models; not a current-model comparison or a feature of this Atlas trial.

The same model can start with different guidance.

An agent is a model working within a system of instructions, tools, saved state and a program that coordinates its steps. This surrounding system is often called a harness. A stored experience can enter the next prompt, suggesting which source to check, which tool to call or which shortcut to avoid.

Saving where a task stopped supports continuity. Remembering a customer’s preference supports personalisation. Reusing a tested procedure can change how future work is done. None of these operations requires the model’s weights to change.

Training is another route. SCoRe, for example, used reinforcement learning to train better self-correction. In this article we examine changes outside the model: what the system records, loads and permits to influence its next action.

A finished task and an improved method are different outcomes.

Consider a research agent that finds a comparison between results obtained with different attempt budgets. It can fix the current sentence immediately. Reusing that experience requires another decision: what should a future agent check, and when?

Our recommended design separates those decisions. The work loop produces an answer or artifact. The improvement loop proposes a change and asks whether it earns its place. A runtime must read the files and execute the loop; a Markdown instruction alone does not enforce tool permissions or run a process in the background.

We gave Atlas a sensible note. It added no measured benefit.

We tested a small part of that mechanism. One agent distilled earlier, editor-supplied research observations into a reusable note: distinguish metrics and check whether experiments can fairly be compared. It never saw the evaluation cases. The note came from supplied feedback; its author had not made and corrected those mistakes itself.

We then ran four fresh-context sessions: two with the common task instructions and two with the same instructions plus the note. Each answered four fictional research comparisons. The cases covered different units, extra attempts, a genuinely comparable result and a misleading task mix. We fixed the tasks and scoring criteria before running them.

A separate AI grader, unaware of which condition produced each response, found that both conditions met all 32 checks. Neither missed a scored distinction; neither falsely rejected the valid comparison. We retained the baseline and left the note inactive.

A good reminder can be redundant.

The baseline already handled these distinctions. Loading an accurate reminder therefore added no observable value under our rubric. The changed input did not produce a better checked answer. That is the limit of what we observed—not proof that the note was ignored, or that memory cannot help.

The trial was deliberately small and used compact, self-contained cases. It left no headroom above the baseline’s full score. We did not test remembering unfamiliar facts, finding a note in a large library or recovering a long tool-based workflow. Exact backend version, inference budgets, latency and cost were not exposed; we cannot claim equal compute or an efficiency gain.

A useful next test would start from a recurring failure on unfamiliar work, then hold out new tasks for evaluation. Retesting the same examples until a favourite method wins would answer a different question.

Published systems change more than a single reminder.

Harness², a 2026 preprint from Google Cloud AI Research and Northwestern, proposes changes to the execution harness, runs them and combines changes supported by the resulting behaviour. A persistent improvement library helps guide later adaptations. The model weights remain fixed. Its reported benchmark gains involve more machinery and additional executions than our note-loading trial. The authors acknowledge extra inference cost, variable executions and shared model biases; transfer is not guaranteed.

ACE, from Stanford, UC Berkeley and SambaNova, separates generating work, reflecting on experience and curating a reusable playbook. It adds local updates rather than repeatedly rewriting the entire context. Its authors also identify a dependency: poor reflection can produce noisy or harmful guidance, while tasks that already have a simple adequate strategy may gain little from richer context.

A similar memory may leave out the crucial step.

Researchers Qisheng Hu, Quanyu Long and Wenya Wang at Nanyang Technological University studied experience reuse in ALFWorld and BabyAI. One task pair is revealing: “put X in Y” and “put a clean X in Y”. The wording is close; the required procedure differs.

In their experiments, transferring detailed old trajectories could carry over the simpler routine and harm the harder task. Abstract procedural insights transferred more reliably in the tested direction. Those findings concern two simulated task pairs, not every memory product.

For a builder, this suggests a distinction between finding a similar memory and finding one that applies. A useful record needs conditions: what was true, which action worked, how it was checked and when the lesson would be unsafe to reuse. A previously successful recipe still has to fit the present request.

Build the feedback path before growing the memory library.

For a first implementation, we would use a runtime, a small versioned store and checks tied to observable outcomes. Keep the user’s decisions, current task state and candidate methods separate. Load only records that apply to the task. Save actions and results with their source and date, then propose a reusable method when there is a concrete problem to investigate.

This keeps the learning decision open to inspection. A proposed note can remain a proposal; a check can fail; a method can be retired. Budget and action permissions belong outside the part of the system that proposes its own improvements.

An improving system must be able to keep less.

Anthropic engineer Prithvi Rajasekaran describes simplifying a long-running coding harness by removing components individually and checking what changed. His account treats each component as an assumption about a model limitation—an assumption that may become outdated. It is a provider’s engineering experience, not an independent universal recipe.

That is the decision our own trial made tangible. We had a plausible note, real executions and a way to check them. The evidence did not justify adding the note to normal work. A useful improvement process must be able to reach that conclusion as readily as “keep the new method”.