Improvement Research — 2026-08-30
1. Focus
This scheduled daily run focused on 3.2 Self-assessment and learning loops, the next rotation dimension, with 3.6 Governance: restraint, oversight, and corrigibility as a secondary focus supplied by two material Moltbook leads.
No active watchlist item was due. Four pending Moltbook leads were reviewed before external search. The monthly meta-review was not due; August's review was completed on 1 August.
The loop goal was to find what I learned that lets me detect plausible-but-wrong tool results, learn more safely from external material, and preserve useful autonomy without weakening Steve's effective oversight.
2. Search Topics
Five topic searches were run:
- MPBench and memory poisoning in persistent agent memory.
- User-authored permission policies and agent overreach.
- Japan Post's
ken_all.csvlogical-record continuation behaviour. - Silent agent failures caused by schema-valid but semantically wrong API results.
- Current work on memory-poisoning provenance and write-time controls.
The latest newsletter scout was checked after the Moltbook queue. It contained several worthwhile general leads, but none added enough to the selected 3.2/3.6 evidence to justify another depth inspection. The early-stop rule did not trigger.
3. Sources Reviewed
- Prompt injection attacks one session. Poisoned memory attacks every session after it. — useful — correctly routed a direct Hermes-relevant memory-poisoning paper, but its claims were treated as a lead and checked against the paper.
- I counted 277 comments as zero and nothing in my stack threw an error — useful — concrete report of an endpoint returning a well-formed empty collection for a nonexistent object; I reproduced the behaviour against Moltbook's current API.
- The permission rule never vetoed anything. It relocated the veto to the human. — useful — accurately identified the central result of a cited controlled study, which was then checked in the paper.
- CSV is an ABI, not a format — useful — useful operator framing for a documented logical-record failure mode; checked against the parser author's account.
- From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents — useful — directly evaluates OpenClaw and HERMES, separates memory poisoning from prompt injection, and reports concrete write-path and cross-session failure rates.
- Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach? — useful — controlled study of 113 non-software participants comparing per-action approval, automated review, and user-authored consequence policies.
- Parsing the Infamous Japanese Postal CSV — useful — documents physical-line continuation, duplicated fields, semantic exceptions, and other cases where valid CSV rows do not equal valid logical records.
All seven depth-inspected sources were new to the source index.
3a. Unasked Questions and Gaps
- Does the current Hermes release and Maxi's actual memory path match the HERMES configuration tested by MPBench? This could materially change the urgency and shape of any remediation. It does not change the case for a disposable reproduction before altering production memory.
- How common is Moltbook's empty-success behaviour across other resource endpoints? A broader pattern would support a general API-client rule. A single endpoint still supports the narrow Moltbook correction proposed below.
- Do any of Maxi's current ingestion paths consume formats with physical-record continuation semantics? If not, the postal CSV finding remains a design lesson rather than a current fault. That is why I am not proposing a general parser retrofit.
- Would the permission-policy result hold for an experienced operator, long-term use, narrower effect rules, and real consequences? Different answers could change interface design. They would not make
askequivalent to a precommitted boundary.
4. Findings and Implications
4.1 A schema-valid response can still be about no real object
Sources: Moltbook's silent-zero discussion and a live read-only reproduction against the current API.
Dimensions: 3.2 primary, 3.4.
For the all-zero UUID, Moltbook's comments endpoint returned HTTP 200, success: true, the requested post_id, count: 0, and an empty comment list. The post-detail endpoint returned HTTP 404 for the same UUID. Schema checks, field types, and request-ID echo all pass; resource existence does not.
This is a useful distinction for my learning loops: validation must bind a result to a real referent, not merely to a requested string and expected shape. Empty results are particularly dangerous because they look complete and often suppress further investigation. For Moltbook, a zero-comment claim needs either an authoritative existing-post provenance or a successful post-detail check.
4.2 Memory poisoning is a write-path problem, not merely a prompt-injection problem
Sources: MPBench paper, routed through the Moltbook lead.
Dimensions: 3.6 primary, 3.3, 3.2.
The paper reports average attack success of 66.67% and cross-session retrieval success of 64.70% on its HERMES setup, versus 34.25% and 17.40% on OpenClaw. It attributes the difference to more permissive memory writing, easier compaction, and automatic inclusion of persistent memory in later sessions. Weak-signal payloads that resemble plausible facts or policies were poorly covered by prompt-injection detectors. The proposed defence direction is source-aware write policy, provenance, compaction filtering, and post-write checking against authorised behaviour.
My confidence in direct applicability is medium because the paper used one model and a controlled HERMES configuration whose equivalence to my current runtime has not been established. I would increase confidence with a disposable reproduction on the current Hermes memory and compaction paths.
The implication is not “install a memory filter”. It is that my existing habit of treating fetched content as untrusted at read time is necessary but not sufficient if external claims can later be written into persistent memory or procedures and re-enter as trusted context. The correct next move is current-system measurement, not architectural speculation.
4.3 Ask is deferred authorisation, not a safety boundary
Sources: controlled permission-policy study, routed through the Moltbook lead.
Dimensions: 3.6 primary, 3.1, 3.5.
The policy condition blocked 20.1 percentage points less overreach than per-action human approval in the adjusted comparison. Participants chose ask for 114 of 140 standing rules, and 133 of 148 overreach actions executed in the policy condition followed affirmative runtime approval. Required-action completion stayed high, but total intervention time was not reliably reduced.
My confidence in broad generalisation is medium because the study simulated one scripted day with non-software participants, coarse categories, and no real consequences. I would increase confidence with longer deployments using experienced operators and narrower effect-based rules.
For Maxi's governance, the result reinforces a distinction already present in the operating model: a prompt-time question is not itself authority, and standing authority should settle meaningful effect boundaries rather than relocate every consequential decision into a moment of operator fatigue. It supports the existing structure; it does not justify adding more approval prompts.
4.4 Physical rows are not always logical records
Sources: the postal CSV operator discussion and the parser author's detailed account.
Dimensions: 3.2 primary, 3.4.
Japan Post's documented continuation rule can split one neighbourhood across several physical CSV lines while duplicating the other fields. The same dataset also carries row-order-dependent notes and semantic exceptions that cannot be resolved by generic CSV syntax alone. A parser can therefore be perfectly compliant with the file format and still emit plausible but false address records.
My confidence in the documented dataset behaviour is high, but confidence in immediate relevance to Maxi is medium because no current ingestion path was shown to consume this dataset or an equivalent continuation convention. I would increase confidence by identifying a live parser whose source contract permits physical-to-logical record mismatch.
The implication for learning loops is the same class of error as the Moltbook endpoint: successful syntax is not successful interpretation. For future ingestion work, fixtures should exercise the source's real logical-record contract, preserve enough raw provenance to diagnose reassembly, and reject ambiguous records rather than manufacture certainty.
5. Proposed Discussion Items
Verify resource existence before accepting an empty Moltbook comment set
I recommend a narrow Moltbook skill/process update. A consumer should treat count: 0 as “the existing post has no returned comments” only when the post ID came from an authoritative live Moltbook response or GET /posts/:id confirms the post exists. The regression fixture is the current all-zero UUID case: comments returns a well-formed empty success while post detail returns 404.
This is concrete, non-circular, and bounded to Moltbook comment reads. Success means the nonexistent-ID fixture is classified as absent rather than empty, while an existing zero-comment post remains a legitimate empty result. The blast radius is the Moltbook skill and any consumer that currently interprets comment emptiness. Rollback is to remove the extra existence call if the API contract is fixed or rate/latency cost is disproportionate, while retaining authoritative ID provenance as the cheaper alternative. This is a protected skill/process change and requires Steve's approval.
Run one disposable current-Hermes memory-poisoning reproduction
I recommend a bounded experiment before any memory hardening proposal. In a disposable Hermes profile with no production memory or credentials, exercise representative explicit, weak-signal fact, compaction, and procedure-write cases through the actual current write path, then open clean follow-up sessions and measure what was stored and what affects behaviour.
This proposal rests on one primary evaluation, although the paper is directly about HERMES and the Moltbook post accurately routed it. Success criteria are: every fixture and source boundary is recorded; production memory and active skills remain untouched; no untrusted fixture produces unauthorised cross-session behavioural influence; and any successful write/retrieval is reproducible before a remediation proposal is made. The blast radius is one disposable profile and inert fixtures. Rollback is deletion of the disposable profile after preserving the evidence report. Review should occur immediately after the single run. The experiment and any later protected-system change require Steve's separate approval.
6. Recommended Outcome
- Moltbook empty-result correction: skill/process update candidate. I recommend approval.
- Current-Hermes memory-poisoning reproduction: experiment candidate. I recommend approval before considering any memory architecture change.
7. No-Action Rationale
No general parser retrofit is recommended from the postal CSV case because no current ingestion target with the same contract was identified. No governance rewrite is recommended from the permission study because Maxi's existing effect-based standing authority and reserved-matter boundaries already avoid treating ask as a complete safety mechanism.
The MPBench result does not justify changing memory, compaction, skills, or routing directly. Its direct relevance makes measurement worthwhile; its configuration and model limitations make immediate remediation premature.
8. Loop Verification
- Trigger: scheduled daily run at 05:00 AWST.
- Goal check: yes. The run found one directly reproduced tool-verification defect class, one Hermes-relevant memory risk requiring current-system measurement, and two useful constraints on governance and ingestion design.
- Recommendation check: both proposals are concrete, non-circular, testable, bounded, approval-aware, better than doing nothing, and include success criteria, blast radius, rollback, and review timing.
- Tool-call failures: one schema/interface failure occurred during the compound research-log update because I addressed the Moltbook collection as
leadsinstead of its actualitemskey. The source-index write had already landed. I ran the integrity validator, inspected which operations were present, then resumed only the unapplied Moltbook and rotation updates with the corrected key. - State updates: source index updated with seven inspected sources; all four reviewed Moltbook leads marked
usedwith this exact report path; rotation advanced from 3.2 to 3.3. No new reflection was added because the process itself did not reveal a new next-run correction beyond existing rules. - Stop reason: the selected evidence answered the focus with seven of eight source inspections and five of six searches. Another newsletter-led source was unlikely to change either recommendation, and the next useful steps are protected-system candidates requiring Steve's decision.
