Stop Teaching Your AI Agent the Wrong Lessons

Suppose your coding agent tries to run integration tests and discovers that the local test database is unavailable. It completes the checks it can, explains the gap, and leaves an accurate session report.

Then an automatic learning step saves this:

Integration tests cannot run in this environment.
Use unit tests to validate changes.

The next morning, the database is back. You ask for another change. The agent reads its saved guidance, runs the unit tests, and confidently stops there.

Nothing needed to be hallucinated for this to go wrong. The original failure was real. The report was honest. The memory worked. A temporary obstacle acquired the authority of a standing instruction.

This is a hypothetical example, but it gets at what I want from a self-evolving agent harness. I want it to adapt to the person and project it works with. An impressive single task tells me very little about whether that adaptation will happen. What matters is what the agent carries into the next relevant task, and whether I have to correct it again.

Memory, skills, and personalization already exist in current tools. The difficult decision happens inside that machinery: which part of an experience deserves to influence future work?

A Saved Lesson Changes the Job

There are several things an agent might preserve after a session. A record explains what happened. A project note describes the environment. A skill tells the agent how to approach a class of tasks. A personal preference shapes how it works with you.

Those uses overlap, but moving information between them changes its meaning. A report can say that the database was unavailable without telling anyone to avoid integration tests tomorrow. Put the same conclusion in a procedure, remove its date and conditions, and it starts making decisions for the next session.

That promotion deserves attention even when every sentence is factually accurate.

You can see the competing pressures in a real implementation. The current Hermes background-review prompt encourages active skill maintenance, including the sentence: “A pass that does nothing is a missed learning opportunity, not a neutral outcome.” The same code also rejects transient setup failures, unverified recipes, and one-off narratives, and explicitly allows an empty result. These are meaningful safeguards alongside a strong invitation to make changes. The review prompt is available in the source.

Reading that prompt doesn’t tell us how often the reviewer chooses well. It does make the design question concrete. If a session contains nothing worth promoting, the reviewer needs to be able to finish successfully without adding another instruction.

Consider a routine typo fix. The agent found the typo, changed it, and checked the result. Perhaps the existing procedure already covered everything. Saving a new lesson about inspecting text before editing it would make the library larger without giving the next task a useful advantage.

Or consider an unsuccessful experiment. Its details may be valuable enough to preserve so the next investigation doesn’t repeat it blindly. That still doesn’t make the attempted solution a recipe someone should follow.

“Save nothing” has to be a useful outcome of learning. Otherwise the system has an incentive to find a permanent lesson in every temporary event.

Preserve the Decision and Its Conditions

Return to the unavailable database. There are at least three useful ways to describe that session, and each answers a different question.

The session record can say that integration tests were blocked at a particular time and identify which checks did run. That helps someone review the work or resume it.

A current project note can say that the integration suite needs the local test database, with a pointer to the repository’s setup instructions. That helps someone prepare the environment. If the repository already documents this clearly, a link may be enough.

A reusable procedure can explain what to do when a required dependency is unavailable: identify the missing prerequisite, report which checks were blocked, and try again after the condition changes.

The original wording compressed all three into an exemption from testing. The useful revision preserves the branch in the decision:

For changes covered by the integration suite, use the project's
documented test setup. If the test database is unavailable,
report the blocked checks and the missing prerequisite.
Recheck after the database is restored; the earlier blocker
does not waive integration testing.

This is illustrative wording, not a universal testing policy. Your project decides which changes need which tests and how its database should be started. The point is that the instruction now contains enough conditions to become inapplicable when the environment changes.

That ability to stop applying is easy to overlook. We tend to ask whether an agent remembered the instruction. With temporary facts, remembering it too literally can be the failure.

Adding a date helps a reader recognize the age of a note, but a date alone doesn’t resolve anything. A database can remain unavailable for a week or return five minutes later. The useful question is what observation would supersede the note. Here, a successful connection check can settle a fact that yesterday’s report cannot.

The same reasoning applies to a workaround for an old library version, a missing command, or an API that was temporarily inaccessible. Preserve the condition that made the workaround necessary. When that condition disappears, the next agent should have a reason to reconsider it.

You also don’t need to save everything at every level. A session report can remain a session report. A project can point to its existing setup documentation. The reusable procedure only needs the part that changes how a future problem is handled.

Give Each Instruction a Home

An instruction can be useful and still belong in the wrong place.

If I prefer concise progress updates, that can reasonably follow me across projects. If one repository requires a particular database setup, that belongs with the repository. If a migration procedure only applies when changing a schema, it should become relevant when that work begins.

Putting all three into a global memory file means every project inherits decisions made somewhere else. It also makes later corrections harder. You change the project instructions, but an older copy remains in personal memory and continues to influence the agent.

Current tools already expose ways to separate these scopes. Claude Code, for example, documents user instructions, shared project instructions, local project instructions, conditional rules, and skills. Its documentation also makes a useful limitation explicit: instruction files guide the model as context; they aren’t enforced configuration. Its memory documentation explains the available locations and loading behavior.

The practical choice is which decision you want to own where. For the database example, the project’s test requirements need one authoritative home. The temporary outage needs a dated record. A broader troubleshooting procedure might belong in a skill used across repositories, provided it asks for the current project’s setup rather than carrying one project’s commands everywhere.

This doesn’t require a new metadata scheme for every sentence. An ordinary project file, a link to the relevant documentation, and a clear condition can do the job.

It does require restraint when a correction arrives. Before appending another instruction, inspect the one already responsible for that behavior. Maybe it says the wrong thing. Maybe two copies disagree. Maybe the agent never received it. Adding a third version can leave the original problem intact.

A useful review question is: which future decision will this sentence change? If the answer is simply that it describes the completed task, you probably have a record. If it changes an action, its audience and conditions should be clear enough that another project won’t inherit it by accident.

Watch the Next Relevant Task

Once a rule is saved, several things still have to happen. The next session must be able to find it. The relevant contents must reach the model. The agent must apply them appropriately. Following them must contribute something useful to the task.

You can investigate those transitions separately.

In Claude Code, /context lists loaded memory files. That gives you a way to check whether the relevant instruction file loaded. It does not prove that the model followed a particular sentence, understood its conditions, or produced a better result.

For those questions, inspect the actual work: the patch, commands, tool results, and remaining gaps. An agent saying it remembered to test is weaker evidence than the command and its result.

There is an empirical reason to avoid equating more guidance with better work. In Evaluating AGENTS.md, researchers tested repository context files on coding tasks. Generated files did not significantly improve task resolution in their comparisons and increased average inference costs by 20% and 23% on the two benchmarks. Developer-provided files performed better than generated ones. This was a study of particular coding agents and tasks, not personal memory or a verdict on every instruction file. It does show why an instruction’s influence and its benefit deserve separate checks. The paper reports the comparisons and limitations.

For your own setup, choose one recurring correction with an observable consequence. Keep the original evidence if you have it, revise the appropriate instruction, then watch a fresh session tackle the next comparable piece of work. Don’t repeat the entire correction in the new task prompt if you’re trying to find out whether persistence supplied it.

In the database example, that means a change which genuinely needs integration testing. Check whether the agent consults the current setup, identifies the database state, and reports the actual test coverage. Record any correction you still had to make.

Then consider the more revealing case: the database is available again.

Does the agent run the required tests, or does the remembered outage still excuse skipping them? An instruction that handles only the original failure hasn’t demonstrated that it can handle recovery. The changed condition is what distinguishes a useful conditional procedure from a memorized outcome.

One successful task gives you evidence about that task. If the agent already behaved correctly before the change, the later success doesn’t establish an improvement. If the new rule adds unnecessary checks, that also belongs in the assessment.

Recovery Has to Change What Happens Next

A blocked operation can teach a useful lesson if the agent preserves a way forward.

In the database case, “the tests failed” is too ambiguous. Did test execution reach the application and find a defect, or did the test runner stop before the relevant tests could run? Those situations demand different next steps. A useful report identifies what executed, what remained blocked, and which prerequisite needs attention.

Once that prerequisite changes, another attempt has a reason to happen. Repeating the identical operation while nothing has changed gives you little new information. Saving that repetition as a troubleshooting procedure would preserve the wasted work.

This is also where a sentence may be less useful than a small tool. If the environment has a documented readiness check, let the agent use it. If a targeted test can verify the correction, give it a direct way to run that test. The instruction should connect the decision to evidence the agent can obtain.

Mitchell Hashimoto describes this combination in his account of adopting coding agents: recurring mistakes become project guidance, while tools such as focused tests and screenshot scripts give the agent feedback about its work. He reports substantial improvement in his own setup. That is a practitioner’s experience, rather than a controlled comparison, but it offers a concrete model for connecting a correction to something observable. His account explains both parts.

I want a harness to make those connections for the particular project and person. A shared platform can support that. A custom system can get it wrong. The size of the framework doesn’t decide whether its saved advice recognizes a repaired environment.

Nor should every correction become another permanent check. If a rule already expresses the right requirement and the missing dependency has been restored, there may be nothing more to add. Recovery can leave the instruction library exactly as it was.

Retire Advice When Its Job Is Done

A growing library needs a way to change its mind.

Suppose the project replaces its local database with a managed test fixture. The old prerequisite note now sends the agent toward setup work the project no longer needs. Keeping the note because it once prevented a mistake would preserve the mistake in a new form.

The useful trigger for review is the change itself: a dependency replaced, a command removed, a workflow revised, a preference corrected. Some notes will remain valuable for years. Others should lose authority after the next successful check. A universal expiry timer can’t decide that for you.

When advice becomes obsolete, correct or remove it at the location future sessions actually use. Keep its history if that history helps explain the project. Check for duplicate instructions that could continue to revive the old behavior.

There is a maintenance cost here, and it belongs in any assessment of self-improvement. A system that saves you a correction today while creating three conflicting instructions to sort out next month has deferred some of the work.

You can start much smaller than an audit of the whole harness. Open one recently saved lesson. Identify the decision it changes, the conditions where it applies, and the next task where you could observe its effect. Include a case where those conditions no longer hold.

If you can’t identify a future decision, keep the material as a record. If the instruction already exists, improve its existing home. If the condition has expired, retire the advice.

Then let the next relevant task tell you something. In our example, the database comes back, the required tests run, and yesterday’s obstacle stays in yesterday’s report. That’s the kind of remembering I want.

---

I’m Kenny, the developer behind Atomic Agents and Eigenwise. I build AI tooling and help teams adapt coding workflows, project context and review processes to their own codebases. You can find my work at Eigenwise.