feat: localize recurring failures to memory components and gate their repair (Recuris)

[AlexStocks]

Feature description

Record recurring task failures as structured negative knowledge that carries three things Experience does not have today:

1. a machine-matchable trigger signature, so that a recurrence of the same failure can be recognized at recall time instead of being re-learned as a fresh lesson;
2. a repair-routing attribution, naming which layer of the harness the fix must touch, so the response is "patch the broken layer" rather than "write another lesson";
3. an avoided-recurrence ledger, so an entry that keeps being recalled but never actually helps becomes visible for Review instead of persisting silently forever.

PowerContext covers the positive case well: ExperienceContent captures reusable judgment as situation / action / outcome / lesson. What is missing is the negative counterpart with a stable identity: there is currently no way to express "this failure has happened before, here is how to recognize it, here is which layer is broken, and here is the evidence that we stopped making it".

Problem and proposed solution

Research basis

Zhaochen Yu, Yingcheng Wu, Zhenfei Yin, Kaiyuan Chen, Zhe Zhao, Mengdi Wang, Shuicheng Yan, and Ling Yang. Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses (Recuris), arXiv:2608.24876v1, August 25, 2026.

• Abstract and publication metadata
• Full paper
• PDF
• Code (Apache-2.0)

Recuris models the harness memory-control layer as a four-component tuple M_k = (E_k, W_k, rho_k, C_k) and defines that tuple as the patch space: failures are localized onto components, not merely summarized.

Component	Definition in the paper (Sections 2.1.1, 2.3.1)	Failure localized to it means
E Experiential Memory	stores reusable skills in the agent-skill format	missing or flawed skill
W Working-Memory Specification	defines the state schema and update proposal for its task-specific instance	omitted goal, unsuitable state field, or incorrect state-update proposal
rho Invocation Policy	decides at which execution events skills are retrieved and which entries enter the context	missed, late, or irrelevant skill invocation
C Checker Set	tests whether observations support proposed state changes	a supported transition was rejected, or an unsupported transition was accepted

Two properties are worth carrying over directly:

• Attribution is a repair decision, not a causal claim. The paper states: "This is a repair decision rather than a claim of causal identification... Recuris attributes each diagnosed failure to the component on which a localized intervention is most likely to help." That framing is compatible with PowerContext's evidence discipline, and is the opposite of writing a confident but unfalsifiable lesson.
• Admission is validation-gated and bounded (Section 2.3.3). A candidate patch is accepted only when it repairs the target failure and satisfies a preset regression criterion evaluated on the failed task plus a held-out development set of anchor tasks the current memory already solves. Test tasks, trajectories, and scores never enter localization, patch generation, or admission. The base model, Meta-Agent, localization/patching procedures, and the gate itself stay fixed.

Reported results, not reproduced PowerContext results. The authors report +17.8 points on tau-bench for GPT-5.6 Sol and +15.6 for Claude Opus 5 (to 87.9%), +16.6/+13.5 on SkillFlow for Qwen3.6-27B/35B, +32.2 points on the longest tasks, and up to 80% fewer common long-horizon failures across four benchmarks and ten models. These are author-reported single-paper numbers.

Known limits of the paper, which bound what we should copy. Recuris has no per-failure recurrence counter. It measures reuse and avoidance through aggregate proxies only: Reach (share of held-out tasks where the memory was invoked at least once), held-out success gains, and the dev-set regression rate (e.g. gated updates broke 4 of 42 dev tasks the base already solved). It also targets skill/memory patches admitted against a held-out dev set, which is a stronger validation budget than a per-turn production recall loop can assume.

Reference implementation

claw-mem v7.6.0 (Apache-2.0, small community project) operationalizes the E-adjacent diagnosis into a per-item "Error Pattern Card". Its card format is a useful concrete starting point:

• src/types.ts — RootCauseCategory = "skill-defect" | "state-defect" | "invocation-timing" | "transition-judgment", whose doc comment states the semantics are mapped from Recuris E/W/rho/C onto "the layer the fix must touch"; and ErrorSignature { trigger, symptom } (when to recall the card, and how the error looks).
• Card fields: stable semantic id cardId (epc:<trigger>, so re-storing the same id is an edit rather than a new entry), errorSignature, rootCauseCategory, resolution (minimum 20 characters), optional verification, server-owned effectiveness, provenance. A near-duplicate trigger (normalized bigram overlap, threshold 0.8) only suggests editing the existing card; it does not hard-reject.
• Effectiveness ledger: per-card hitCount / avoidedCount / lastHitAt; 5 consecutive non-avoided hits move the card to inactive, and the first avoided hit revives it. Every rejection and warning is appended to an append-only audit file.

Two honest caveats about using it as a source: its README claims 100% on LoCoMo, ConvoMem, and LongMemEval simultaneously and a "subagent memory merge" that does not exist in its source, so its published numbers should not be treated as a baseline. The card format and constants above are verifiable in code, and those are the only parts cited here.

Existing foundations and precise gaps

Code references are pinned to source master at c2016666, inspected on September 10, 2026.

Existing capability	Gap this proposal addresses
ExperienceContent holds situation / action / outcome / lesson, all free text.	Free text is not a match key. Two encounters with the same failure cannot be reliably recognized as the same failure, so recurrence cannot be counted and a "lesson" cannot be falsified.
Candidate Review validates evidence, content, and revision consistency before committing.	Review validates before publication. Nothing observes after publication whether the recorded knowledge did anything.
#1508 connects recurring Task Outcomes to an existing Experience and evaluates a proposed Skill revision under a paired comparison.	#1508 consolidates failures into Experience and gates Skill revisions. It does not type the failure against a repair space, and does not track per-entry avoided recurrence in production.
#1509 / #1510 (Dream) provide bounded, evidence-backed Memory-to-Experience-to-Skill refinement behind Review.	Dream decides which artifact to propose. It assumes the input concept already exists; there is no negative-knowledge type with a trigger identity to consolidate in the first place.
#1422 defines the governed evaluation loop with validation_status independent of Candidate review.	The loop has no named outcome category for "a previously recorded failure did not recur". That is the metric this feature needs to be evaluated by.
Task Outcomes (builtin/work/models.py) and keyed Sources carry exact provenance.	Provenance is already stronger than the reference implementation's. The gap is only the negative-knowledge concept and its ledger, not evidence plumbing.

A search of master for recurrence, effectiveness, and avoided returns no matching concept in source, so this is not partially implemented under another name.

Proposed design direction

1. A trigger signature as the identity, not free text. Store a structured error_signature (trigger: when the entry should be recalled; symptom: the observable shape of the error) alongside the entry. This is the only field that makes recurrence detectable, and therefore the only field that makes an avoided-recurrence ledger possible. Following the reference implementation, the signature should be the entry's stable match key so that re-recording the same failure edits the entry rather than duplicating it.

2. Repair-routing attribution, mapped onto PowerContext's actual control layer. Do not copy the four enum names. Map the paper's patch space onto the surfaces PowerContext would actually patch:

Recuris component	PowerContext surface the fix must touch
E Experiential Memory	Memory entry text, ExperienceContent, or a Skill package
W Working-Memory Specification	Handoff objective / state[] / next_action, or the Task Outcome fields being recorded
rho Invocation Policy	Scope recall configuration, how the prepare query is constructed, assembly.sections selection
C Checker Set	Handoff disposition / acceptance criteria, or a verification instruction attached to Experience or a Handoff

The point of the enum is to route the repair, and to make "the card is right but recall never fires it" a distinct, expressible diagnosis (rho) rather than an invisible bug. Attribution should stay a human Review decision; it should not be inferred automatically and then treated as fact.

3. An avoided-recurrence ledger, with Review-gated degradation instead of automatic deactivation. When an entry is selected into prepared context, record the selection. When a later Task Outcome carries the same trigger signature, record whether the failure recurred. That gives selected / avoided / recurred per entry.

This is the one place where the reference implementation must not be copied literally: claw-mem deactivates a card automatically after 5 non-avoided hits. PowerContext's immutable revisions and the boundary recorded in RFC 0051 ("no automatic decay, importance, or retirement in the first release") make automatic deactivation unacceptable. The equivalent behavior should be: a low-yield entry is marked as needing review and surfaced through the existing Candidate Review path, where a human decides whether to revise or retire it through explicit revision. Revival on first avoidance can be retained, since it only moves an entry back into normal recall.

4. A write-time structural validation gate with an append-only record. Minimum required fields, a minimum-resolution-length rule, and a confidence floor below which the entry is dropped rather than stored ("missing is better than wrong"). Near-duplicate triggers should suggest editing the existing entry rather than silently creating a near-twin. Every rejection and warning should be persisted append-only, which fits PowerContext's Source/Observation model directly.

5. One new metric for the evaluation loop. An "avoided recurrence" outcome category, consumed by the protocol in #1422. Without it, this feature cannot be evaluated, and the ledger has no purpose. Note the paper's own honest limitation here: it does not have this counter either, so PowerContext would be going past the published baseline rather than reproducing it.

Explicit non-goals for a first scope. No automatic attribution inference. No automatic retirement or decay. No model calls added to prepare (the constraint already recorded in RFC 1489 applies). No cross-Scope learning.

Open questions

1. Where should this live? Three options, with different costs:

   • extend ExperienceContent with optional error_signature / attribution fields — cheapest, but mixes positive and negative knowledge in one content shape and still leaves the ledger homeless;
   • keep it in Memory under a reserved kind — also cheap, but the match key and counters are not MemoryEntryVersion fields, so the schema grows anyway, and Memory's admission rules are written around statements that change future judgment rather than around recognizable failures;
   • a new Artifact family — cleanest for a stable match key plus a ledger, and consistent with how Experience and Skill were separated, but it carries API, review, Dashboard, and documentation cost.

   A fourth option may be the sharpest: split the two concepts the reference implementation conflates. A rejected approach or an API pitfall is decision knowledge and has no need for a ledger; only a recurring failure needs a match key and an avoided-recurrence counter. The first might belong in Memory or an Experience applicability note, the second in its own type.

2. When is the ledger written? Writing on every prepare adds a mutation to a read path. Writing only from Task Outcome linkage is later and sparser but keeps prepare read-only.

3. Does attribution belong in the artifact or in a Review annotation? Putting it in the artifact makes it durable and queryable; putting it in Review keeps the artifact immutable and the judgment auditable.

4. How does this interact with feat: consolidate Experience and evaluate Skill revisions (WikiSkill) #1508? Should an entry with an E-class attribution feed Skill revision proposals, and should a rho-class attribution feed recall-policy evaluation instead? If yes, the attribution enum becomes the routing key between two different downstream loops.

Alternatives considered

• Rely on feat: consolidate Experience and evaluate Skill revisions (WikiSkill) #1508 consolidation alone. It genuinely covers recurring failures becoming Experience, and it is a prerequisite-level capability rather than a duplicate. But it has no match key, so recurrence stays uncountable; no repair typing, so "the recall policy is broken" can only be written as prose; and no per-entry yield signal after publication.
• Adopt the reference implementation's card format as-is. Rejected: its automatic deactivation after 5 non-avoided hits contradicts RFC 0051 and the immutable-revision model.
• Rules-based extraction of the same three classes from a free-text history. This is a related pattern in the same ecosystem (protected-zone extraction of confirmed facts, rejected approaches, and API pitfalls, with a confidence floor and mandatory provenance). It is attractive for provenance discipline but it is extraction from a transcript, not an identity and ledger for a known failure, so it solves a different problem. The one rule worth borrowing is the confidence floor.
• Do nothing until the evaluation loop in Tracking Issue: build a governed evaluation and improvement loop #1422 lands. Reasonable sequencing argument, and one reason this issue is filed before an RFC. But the metric this feature needs has to be requested from Tracking Issue: build a governed evaluation and improvement loop #1422, otherwise it will not exist when the loop is built.

Relationship to existing work

This is not a duplicate of #1508, #1509/#1510, or #1422. The delta is narrow and specific: a negative-knowledge identity (trigger signature) plus a repair-routing attribution plus a per-entry avoided-recurrence ledger, all gated by the existing Review path. If maintainers judge that #1508's Experience consolidation should absorb the identity, or that #1422 should own the ledger as a generic per-artifact outcome signal, that is a better outcome than a new family, and I would rather reframe this issue than add a parallel concept.

If the direction is accepted, I am ready to open a pull request with a bilingual RFC under docs/en/rfcs/ and docs/zh/rfcs/, plus the corresponding website documentation.

Contribution

• I am willing to contribute the bilingual RFC, documentation, and implementation.

[Teingi]

Thanks for writing this up. Tracking whether a recorded lesson helps on later tasks seems worth exploring. Experience can already hold failure lessons, so I'd focus the first implementation on recognizing a repeat failure and connecting it to an outcome we can check.

The part I'd want to pin down first is avoided. Selecting a reminder into prepared context doesn't tell us whether the agent used it. A later Task Outcome that doesn't mention the failure isn't enough either. We need evidence that the same risky situation came up and that the agent handled it correctly. Missing evidence should stay unknown, and even a successful attempt wouldn't by itself prove the reminder caused the improvement.

For example, an agent repeatedly edits the OpenAPI spec but forgets to regenerate the code. On the next relevant task, we recall that lesson and check whether regeneration happened and the contract checks passed. That gives us a small case we can actually try and inspect.

I'd start the RFC with that flow, using the existing Experience and Task Outcome paths where possible. I'd also keep prepare read-only and record the result when the outcome is reported. The proposed human Review boundary makes sense. Once this works for a concrete case, we'll be in a better position to decide whether a separate Artifact family is needed.

[AlexStocks]

Read the reference implementation you cite; three additions worth folding in.

1. candidate_not_selected is the signal that makes rho attribution detectable

Your ledger defines selected / avoided / recurred. That covers "the entry was recalled and did or did not help". It does not cover the failure mode you name in §2 as the reason rho exists at all — "the card is right but recall never fires it".

To detect that, you have to record the negative case: the entry entered the candidate pool and lost. Without candidate_not_selected, a rho-class misdiagnosis is indistinguishable from "no relevant knowledge exists" — which is exactly the invisible bug the attribution enum is meant to surface. Put differently, your ledger as written can falsify a lesson but cannot falsify the recall policy.

The losers are already known at prepare time: prepared_text.py fits items until the byte budget is exhausted, so everything after the last item that fits is a known drop. Recording them is an append, not a new retrieval pass.

2. Note on the reference implementation: claw-mem has a second, newer mechanism than the Error Pattern Card counters

claw-mem v7.6.0 still ships src/decay/, but it only re-exports src/deprecated/decay — the age-based path (exponential, per-type half-lives 7/90/180 days) is dead code. The live mechanism is src/retention/retention-engine.ts: a per-item utility score in [0,1] that moves on retrieval events, not on time —

• selected: u += 0.1, miss streak reset
• candidate-but-not-selected: u *= 0.85^min(m,5)
• store initializes from write-time outcome (0.75 success / 0.30 failure)
• search feeds it back as a fusion weight next to semantic 0.4 and keyword 0.4

Two things follow. First, an independent implementation arrived at access-based scoring after abandoning age-based decay — the same direction as the boundary already recorded in #1425 ("Automatic importance decay should not silently delete... independently configurable from retrieval ranking"). Second, as you say, their published numbers are not usable; but the mechanism is verifiable in source and is useful precedent that the scoring shape you need already exists in the wild.

This also gives a concrete answer to your open question about the ledger's shape: selected / candidate_not_selected is precisely the input that mechanism consumes, so the ledger doubles as the ranking signal rather than being a parallel structure.

3. On open question 2 (when the ledger is written)

I would write both signals from prepare, but asynchronously and off the response path. The objection to mutating a read path is right about the response, not about a trailing append — the caller should never wait on it.

Precedent that prepare is not currently a pure read: RelationalRecallTokenEstimator (src/powercontext/builtin/runtime/recall.py:106) already resolves exact recall lineage and estimates baseline-vs-recalled tokens inside a prepare. An outcome append fits that existing shape.

Task-Outcome linkage alone would be too sparse to ever answer the question the ledger exists to answer — "was this entry a good use of a bounded budget" — because most prepares never produce a Task Outcome with a matching trigger signature.

Constraint to keep, consistent with your non-goals

This stays an observation plus an optional fusion weight. It must never auto-retire or auto-reorder by default. That is #1425's rule as much as RFC 0051's, and the reference implementation's auto-deactivation after 5 non-avoided hits is the part to reject.

---

Related: I filed #1556 (recall sufficiency gate with bounded expansion in prepare_context). If that lands, the gate's trace is a natural third input to this ledger: "we widened recall and still nothing matched" is itself a rho signal, and it is only observable if the expansion rounds are recorded.

[AlexStocks]

@Teingi — folded your guidance into the RFC, and one question below needs your call.

What changed in #1557 (commit 055cca64)

• avoided is now evidence-gated. It requires the record's bound check to have run and passed under that Task Outcome, with the check result cited. Selecting a record into prepared context is not use, and a Task Outcome that does not mention the failure is not avoidance. Your OpenAPI example is now the flow the RFC opens its guide-level section with.
• unknown is now a first-class verdict. Where the risky situation cannot be shown to have occurred, or the check produced no result, no ledger event is written and the verdict stays unknown. It is derived — a revision's selected events minus those that acquired a verdict — rather than an event, so the ledger stays evidence-only and prepare stays write-free. ScopeStatistics.recurrence reports the unknown count next to the verdicts, so a record whose check never fires surfaces there instead of looking healthy.
• verification is now required inside FailureRecord: condition (when the check is meaningful, so a pass on an unrelated task is not read as avoidance) and check_subject (which TaskCheck evidences it). A record with no check can only ever accumulate recurred, so requiring the field is what stops avoided from degrading back into "nothing was reported".
• Family placement is deferred, not argued. The RFC lands the record in ExperienceContent per your guidance, and records the concrete trigger for revisiting separation: if the failure block turns out to be carried by only a minority of Experience revisions.

The gap that needs your decision

The ledger records selected / recurred / avoided. It does not record the negative selection case: a record that entered the candidate pool and lost. Without it, a rho-class misdiagnosis — "the record is right but recall never fires it" — is indistinguishable from "no relevant knowledge exists at all", which is exactly the invisible bug the attribution exists to surface. The losers are known at prepare time (prepared_text.py packs items until the byte budget is exhausted, so everything after the last item that fits is a known drop), and recording them is an append rather than a new retrieval pass.

The problem is where it would be written. Losers are only visible at prepare time, and RFC 0028 states that Context Pack "writes no database or file, enters no Source journal or Memory evidence, starts no scheduler work, and is not persisted as telemetry". So this is a real conflict, and it is the one place where the ledger and the write-free read path cannot both hold as currently specified.

(a) Keep prepare write-free, and derive the rho signal from what the ledger already holds.
The ledger can already express it: a record that acquires recurred events while never acquiring a selected event is a record whose recall is not firing. No prepare-side write, no RFC 0028 amendment, and the boundary you stated stays untouched.
Cost: it cannot separate "was retrieved and lost to the byte budget" from "was never retrieved at all". Both are rho-class, so the diagnosis still points at the right layer, but it cannot tell a recall engineer which of the two to fix. It also only fires after the failure has already recurred, so it is a lagging rather than a leading signal.

(b) Amend RFC 0028 to permit one append-only observation event from prepare.
Narrow the "writes no database or file" and "starts no scheduler work" clauses to allow a single append-only RecurrenceObservation for the non-selected set, written asynchronously and off the response path so no caller ever waits on it.
Cost: this changes a foundational RFC rather than adding to it, and it needs its own review. It also weakens a boundary that has been load-bearing elsewhere.

One correction for accuracy, since it bears on (b): the argument that prepare is already not a pure read does not hold as precedent. RelationalRecallTokenEstimator (src/powercontext/builtin/runtime/recall.py:106) does resolve lineage inside prepare, but resolve() and estimate() are both reads — RFC 0028 constrains writes, not work. So (b) has to rest on amending the clause, not on that precedent.

If (b) is chosen, the expansion-round trace from #1556 becomes a natural third input to the ledger: "we widened recall and still nothing matched" is itself a rho signal, and it is only observable if the rounds are recorded.

Either way, the constraint from earlier holds and is already in the RFC: this stays an observation plus an optional fusion weight. It must never auto-retire or auto-reorder by default — that is #1425's rule as much as RFC 0051's, and the reference implementation's automatic deactivation after 5 non-avoided hits is the part this proposal rejects.

My default absent a steer is (a), since it is the only one of the two that leaves the read path exactly as specified today. But (b) is the only one that answers the question the ledger exists to answer at the granularity a recall engineer would need. Tell me which and I will fold it in.

[Teingi]

Thanks for updating the RFC. Let's go with (a) for this first scope and keep prepare read-only. The check binding and explicit unknown handling are the direction I had in mind.

One qualification: I wouldn't conclude that recall isn't firing just because a record has recurred events and no selected events. The RFC reconstructs selection through Task Outcome and Handoff citations, which doesn't cover every prepare. A missing selection event could also mean the relevant Handoff or outcome was never recorded. That pattern can flag something to investigate, but it doesn't establish a recall_policy diagnosis. Please make that coverage limit explicit in the RFC and the statistics description.

Similarly, candidate_not_selected would be useful diagnostic data, but being dropped under a byte budget is normal. We'd still need evidence that the omitted record was relevant and would have been a better use of that budget before treating the omission as a problem. The event alone shouldn't count against the record's usefulness.

For #1557, I'd keep the counters observational and focus on making the OpenAPI example work with evidence we can inspect. We can design per-candidate tracing and any feedback into ranking separately if that work shows we need them. There's enough here to test the recurring-failure flow without amending RFC 0028.