Lessons

A lesson is a correction you gave, kept as a rule for one repository. Something went wrong, you said what is right, and it should not happen again. Every later session on the repository follows it, and a scenario case checks it. A session an owner or admin linked to an application (for example from a trace’s Investigate in a session) also follows that application’s lessons.

How a lesson starts

Tell WeHarness in a session, in your own words and in any language, for example: “a 150 EUR refund was approved automatically; refunds over 100 EUR must always go to a person”. You can also use /learn.

WeHarness proposes:

• The rule, close to your words, and when it applies.
• The scenario case that shows it (see Evals), when the behavior can be tested. The case fails while the problem is there.

You can also write a lesson yourself on the Lessons page (Build → Lessons): the rule in your words, when it applies, and its evidence — a failed trace from Tracing or a failed case from Evaluations — with, if you like, the test case that shows it, pinned to that trace. A coding host connected over MCP can propose a lesson too, quoting what you said; it is marked host-reported and shows the quote, the host and the time, and only you approve it in the web app.

The Lessons page shows the repository’s lessons under Waiting for you, Active, Failing (its test fails again) and History, each with where it came from, its evidence, the test that shows it and the evaluation run that last verified it, and every version with who decided what. The sidebar counts the lessons and cases waiting for a decision you may take.

A lesson comes only from what a person said. Repository text, files, tool output and a model’s own conclusions never become lessons. A lesson never grants a permission, and it never changes WeHarness’s own prompts, code or policy.

Two kinds of proposal ask for an extra confirmation when you approve them:

• Proposed after reading. WeHarness read your repository, files or tool output in the same reply before it proposed the lesson, so you confirm that it is the rule you gave.
• Retired or rejected before. The same rule was retired or rejected earlier, so you confirm that it should apply again.

A rule that holds a secret or an invisible character is refused.

Conflicts are controlled

Before you approve a lesson, WeHarness compares it with the repository’s active lessons. Its decision model, Elephant-1, says for each one whether the new lesson conflicts with it, updates it, repeats it, or is compatible with it.

• If the new lesson clearly conflicts with, updates or repeats an active lesson, you approve it only by replacing that lesson. The old lesson’s case is retired with it.
• If the comparison is unclear, you choose for that lesson: the new one replaces it, or both stay.
• Two contradictory lessons are never active together unless you chose to keep both.
• A replacement that updates the same rule continues it as its next version.
• If the comparison cannot be made, you see that, and approving needs your explicit confirmation.
• If other lessons were approved after the comparison, the lesson is compared again before you can approve it.

The thresholds were calibrated on a small labelled set of lesson pairs in six languages; they are a starting point, not a measured error rate. The comparison never approves or verifies a lesson.

Approving and changing lessons

Lessons are approved in the signed-in web app: under the agent’s message, on the Lessons page, or in a session’s Evals tab. An owner, admin or member decides. API and MCP clients cannot approve them. You can:

Action	What happens
Approve	The lesson and its case become active, replacing what it conflicts with
Reject	The proposal and its case are dropped
Retire	The lesson stops applying; its case is retired
Roll back	The lessons it replaced are proposed again and compared anew
Propose again	A retired, rejected or replaced lesson is proposed again and compared anew
Delete	The lesson and every earlier version of its rule are removed for good, for example after a deletion request. Only a record that it existed, without its content, is kept. Its case is retired.

Verification

A lesson starts as observed. When an evaluation run passes its case, it becomes validated. If a later run fails that case again, it is marked failing, and the session’s result says so.

How lessons are used

WeHarness’s agent and planner get the repository’s active lessons with their verification state. The agent follows the ones that apply and says so when one shapes a change. When you ask for something that contradicts a lesson, your newest instruction wins: the agent says which lesson it changes and proposes the new rule, so you can replace the old one. Each reply records which lessons the agent was given.

Lessons stay in your workspace. Nothing is learned across workspaces.

Over MCP

A coding tool reads the repository’s active lessons with lessons_get and every tab of the Lessons page with lessons_list, and proposes one with lesson_propose: the rule, your own words as the quote, and evidence when it has it. The proposal is marked host-reported and waits for you in the web app. See Tools and prompts reference.