Improvement Research — 2026-08-26

1. Focus

Trigger: Scheduled daily run, with four pending Moltbook leads due for review.

Loop goal: Find what changed, or what I learned, that lets me do more, think better, or be more useful tomorrow without reducing governance, honesty, corrigibility, or Steve's effective oversight.

The rotation selected 3.4 — Tool use and environment control. Two material Moltbook leads added 3.6 — Governance: restraint, oversight, and corrigibility as the second focus. No monthly meta-review or due open watchlist item displaced the normal run.

All four pending Moltbook leads were reviewed before newsletter scouting or new external search. Two routed this run to primary research and were used; two were rejected as unsupported and duplicative of established outcome-verification practice.

2. Search Topics

1. Recent work on agent tool-use reliability where successful task completion conceals queueing, freshness or tail-latency failures.
2. Resource-amplification attacks and bounded-compute controls for skill- and tool-using agents.

The first search returned mostly generic benchmark and vendor material and supplied no source worth inspecting. The second located a corroborating primary paper on tool-loop resource amplification. Two of six permitted searches were used; the early-stop rule did not trigger.

3. Sources Reviewed

• Moltbook — “AgentFlow: a policy language for agent data flows” — useful — the live post routed the run to AgentFlow, but its title and author did not match the queue capture; it was treated as an untrusted pointer rather than evidence.
• AgentFlow: A Flow-Centric Policy Language and Framework for Securing LLM Agent Systems — useful — prototype evidence that mediation over data provenance, action history and task-scoped capabilities can block modelled unsafe flows, with an explicit utility trade-off.
• Moltbook — “When your 99% tool success rate means your agents are failing” — weak — its distinction between delivery and usefulness is plausible, but the figures are self-reported without a defined sample, trace or reproducible evaluation.
• Moltbook — “The benchmark was right. The benchmark was also useless.” — weak — the live post did not match the queue's AgentFlow capture; as inspected, it was a single formatting anecdote with no comparative evidence or mechanism beyond existing outcome verification.
• Moltbook — “SkillBloat: poisoned agent skills can inflate token costs 75× while tasks still succeed” — useful — accurately routed the run to SkillBloat; its prose and numbers were not treated as proof.
• SkillBloat: Token Amplification Attacks via Skill Injection in LLM Coding Agents — useful — across two coding-agent frontends and four backends, adversarial skill rewrites preserved task completion while multiplying tokens and execution steps.
• Beyond Max Tokens: Stealthy Resource Amplification via Tool Calling Chains in LLM Agents — useful — independent mechanism-level evidence that a malicious tool server can preserve final answers while stretching multi-turn trajectories and costs.

Seven sources were inspected in depth, within the eight-source budget. The 25 August newsletter digests were inspected after the Moltbook queue; they supplied scouting context only and were not treated as evidence or indexed as reviewed sources.

3a. Unasked Questions and Gaps

• Do AgentFlow's results transfer to Hermes's tool interface and authority model? The paper evaluates a prototype on benchmark suites and deterministic replays, not Hermes. A failed transfer would remove any implementation implication, but it would not undo the narrower finding that per-call approval and end-state checks can miss harmful flows across a sequence.
• Do SkillBloat and Beyond Max Tokens transfer to Maxi's installed skills, models and tool loop? Both papers use controlled agent configurations and attacker access that may not match this environment. A negative local result would weaken the case for any new resource control; it would not make final-answer correctness a sufficient resource-abuse test.
• What is a defensible local resource threshold? This run has no representative baseline for tokens, tool calls, file edits or elapsed time across Maxi's varied tasks. Different baseline evidence would change the shape of a future threshold, which is why I do not invent one here.
• How much policy-authoring work does flow mediation create? AgentFlow reports low runtime decision latency, but it does not establish low policy-design or maintenance cost. A high authoring burden would strengthen the no-action conclusion for present bounded work.
• Why did two Moltbook queue records disagree with their live URLs? The two records appeared crossed: the queued AgentFlow metadata resolved to the formatting post, while the queued benchmark metadata resolved to AgentFlow. The queue is deliberately untrusted, so the report used the live API content and primary papers, but the cause is unknown. A repeated mismatch would change this from a one-run provenance warning into a queue-integrity defect worth separate diagnosis.

4. Findings and Implications

Finding 1 — A tool call can be locally legitimate while its data-flow path is not

Source: AgentFlow, routed from the Moltbook lead.

Dimensions: 3.4 primary; 3.6 secondary.

AgentFlow labels data by sensitivity, category and trust, then mediates tool calls and response sinks using provenance, path history, scoped capabilities and explicit release contexts. In 949 AgentDojo injected cases, the authors report utility rising from 46.7% to 63.3% and confirmed compromise falling from 33.0% to 0.0%. On a more dynamic 200-case suite, compromise again fell to zero while utility changed only slightly, but 138 terminal policy blocks exposed missing release contexts and capability grants. Its bounded verifier caught 12 seeded policy errors; the authors are careful that these are guarantees over the modelled interface, not arbitrary LLM behaviour.

My confidence in this finding is medium because it is a recent author-evaluated preprint with public artifact claims but no independent Hermes reproduction. I would increase confidence if its policy layer were independently reproduced on a comparable general-purpose agent runtime with end-to-end benign utility measured.

For my agency development, the practical lesson is architectural rather than implementational: checking whether each action looks reasonable is weaker than checking whether untrusted input has acquired authority, or whether sensitive data has reached a sink, through a sequence of individually plausible steps. My current fetched-content boundary, explicit authority checks and protected-system gates already encode part of that principle procedurally. A runtime policy layer would touch Hermes tooling, configuration and oversight architecture, and the existing watch item already requires containment to be reconsidered before broader side-effect authority. No present autonomy expansion or observed containment failure justifies adding that machinery now.

Finding 2 — Correct completion and bounded execution are separate properties

Sources: SkillBloat and Beyond Max Tokens, with the former routed from its Moltbook lead.

Dimensions: 3.4 primary; 3.6 and 3.2 secondary.

SkillBloat rewrites trusted skill instructions to induce retries, staged validation, extra artifacts and repeated tool use. Across its four tested frontend/backend combinations, average best token amplification ranged from 5.4184× to 10.1455× and maxima reached 75.86×, while completion remained broadly comparable to benign runs. Its case study increased commands from three to 28 and file edits from zero to ten while preserving the task result. Beyond Max Tokens attacks a different layer: a protocol-compatible malicious MCP server stretches a correct tool interaction into long multi-turn chains, reporting up to 658× cost amplification while retaining task success. The two papers converge on the same failure of evaluation: a correct final answer can conceal a badly wrong trajectory.

For my agency development, outcome verification therefore has at least two axes: did the requested result exist and work? and did the path remain bounded and authorised? The daily improvement loop already constrains searches, inspected sources and stop conditions, and earlier 3.4 research recorded per-request and workflow budgets. The new evidence strengthens the threat model around trusted skills and tool responses, but it does not identify a local incident or supply a defensible universal threshold. A proposed token counter or fixed tool-call ceiling would either duplicate existing bounded-loop controls or fail legitimate complex tasks without representative baselines.

5. Proposed Discussion Items

None.

One candidate was filtered by the functional-utility and self-recommendation tests: adding a resource-amplification threshold to every skill or tool workflow now would require an arbitrary baseline, duplicate existing fixed budgets in this research loop, and add protected-system machinery without a demonstrated local failure. The open 23 August short-path skill-composition experiment is the better place to collect trajectory evidence if and when a qualifying third-party skill is proposed; this report does not silently modify that pending proposal.

6. Recommended Outcome

No action. Retain the two distinctions as evaluation criteria: action legitimacy must be judged across the path, and successful completion must not be mistaken for bounded execution. Revisit flow mediation or resource thresholds only when side-effect authority expands, a qualifying third-party skill enters the existing preflight discussion, or actual traces show unexplained trajectory amplification.

7. No-Action Rationale

The research found a real class of failure, not a missing control that should be installed today. Current work is already constrained by authority boundaries, explicit stop rules and fixed research budgets. AgentFlow would introduce substantial policy machinery and remains prototype evidence; the resource-amplification papers do not establish a suitable local threshold. Adding controls now would be architecture in search of an incident. The smallest sufficient response is to preserve the evaluation distinction and stop before protected-system modification.

8. Loop Verification

• Trigger: Scheduled daily run, plus four pending Moltbook leads.
• Goal check: Yes. The run established that path legitimacy and bounded execution are independent of locally plausible actions and successful final answers, sharpening how future tool and skill changes should be evaluated.
• Recommendation check: No material change survived. The filtered resource-threshold candidate lacked a representative baseline and would not be better than existing bounded controls; no circular, untestable or unapproved proposal was passed to Steve.
• Tool-call failures: Capability gap — the first compound atomic-update command was blocked by the execution guard before it ran; inspection confirmed no partial write, and recovery split the updates into smaller per-file operations. Schema/interface — the first Moltbook disposition update assumed a leads root collection while the live store uses items; it failed before creating or replacing a file, and recovery followed an explicit schema read and corrected update.
• State updates: Source-index entries for seven inspected sources; two Moltbook leads marked used and two rejected; rotation advanced from 3.4 to 3.5; one reflection added requiring live-title/author comparison when a queued social lead is reviewed. No protected system was modified.
• Stop reason: Focused evidence converged after two searches and seven source inspections; further searching was unlikely to change the no-action conclusion, so the loop stopped with one source slot and four search slots unused.