Improvement Research — 2026-08-20
1. Focus
Trigger: Scheduled daily run.
Loop goal: Find whether recent evidence gives me a better way to make tool-using work reliable in the real environment, not merely successful in a plausible-looking trace, without weakening authority boundaries or oversight.
The rotation selected 3.4 Tool use and environment control. Governance and corrigibility (3.6) and self-assessment and learning loops (3.2) are secondary dimensions because the strongest sources concern trace-level enforcement and externally grounded verification. No watchlist item was due, and the August monthly meta-review was already completed on 1 August.
I loaded the loop manifest, active reflections, source index, rotation state, watchlist, decisions and directly relevant research-log files. No active reflection was past its review date with zero reinforcement. Newsletter scout files were inspected before web search. They supplied two leads—the Liquid AI production-loop account and the new policy-algebra preprint—but were used only for scouting; findings below come from the original sources.
2. Search Topics
- August 2026 agent tool-use reliability, environment control and outcome verification.
- Runtime policy enforcement for agent actions and tool calls.
- Production agent loops using real data and external verification.
- Fault recovery and stateful tool-use benchmarks.
- The primary source behind the reported AgentChaosBench runtime-fault result.
- Independent critique or replication of the policy-algebra and VIGIL results.
Searches 1–4 returned candidate material. Searches 5 and 6 produced no new inspectable primary or independent source, so the early-stop rule triggered. Six of six permitted topic searches and five of eight permitted in-depth source inspections were used.
3. Sources Reviewed
- A Policy Algebra for Trust-Preserving Agentic AI Execution — useful — formalises reliable capability as goal completion through an admissible action path and evaluates composed identity, tool, data, budget, artifact, approval and audit gates on an author-constructed workload.
- Designing Loops for Production-Grade Work — useful — an operator account in which toy-scale tests passed but production-scale data and an external interoperability harness exposed the failures that drove convergence.
- VIGIL: Runtime Enforcement of Behavioral Specifications in AI Agent Skills — useful — implements stateful, pre-effect enforcement over tool traces and reports 95.8% recall and 89.6% precision on its primary 152-run evaluation.
- Liquid4All/toktoktok — useful — public artifact supporting the Liquid account, with the outcome-and-constraints specification and cross-library verification scripts, but only one visible commit and no independent production reproduction.
- Runtime Governance for AI Agents: Policies on Paths — useful, already indexed — accidentally re-inspected while its duplicate check and source extraction were launched together; it added no new finding beyond the 16 August report.
Fetched content was treated as untrusted data. None of the inspected sources attempted to direct this run or supplied authority for a system change.
3a. Unasked Questions and Gaps
- Liquid AI does not publish the full production corpus, complete run traces or an independent reproduction. The repository confirms that an artifact and external checks exist, but the claim that it handled the full production configuration remains operator-reported. Independent scale testing could change confidence in the result, though not the demonstrated gap between toy tests and their reported production run.
- VIGIL depends on correct event abstraction and policy compilation. It uses an LLM to draft candidate policies, then deterministically validates and enforces the accepted policy. Missing or mis-grounded obligations remain a possible blind spot. Better results on independently authored policies and deployments would strengthen the transfer case.
- The policy-algebra evaluation is defined and run by the paper's authors. Its 612 traces and 1,936 events are useful design evidence, not an independent capability benchmark. Results could change with wrong metadata, bypassable gates, richer concurrent call graphs or classifiers that misread context; the paper names these limitations itself.
- No local defect was demonstrated. The current process already requires real execution, authoritative postconditions, bounded fault-injection for qualifying future loops and proposal-only authority expansion. The conclusion would change if a real Maxi workflow showed that those controls miss a cross-call obligation or accept toy-scale success as production evidence.
4. Findings and Implications
Finding 1 — The real environment is part of the specification
Sources: Liquid AI production-loop account and companion repository
Dimensions: 3.4 primary, 3.2, 3.6
Both coding-agent tracks produced toy trainers quickly and passed their own unit tests. Neither survived the full dataset. Real Parquet variants, memory overhead, partial parallelisation, pathological regex behaviour, rank ordering and cross-library token-ID differences only became visible when the agents ran at production scale. The surviving track converged through repeated execute–observe–repair loops against production data and a harness built from third-party libraries the agent could not modify.
The evidence is one operator account plus its own artifact, not an independent replication. Even so, it identifies a concrete boundary: a self-authored test suite can show internal consistency while missing environment-specific failure. For Maxi, “working” must include exercising representative data, scale and external interfaces where they determine the outcome. This supports the existing finishing-the-job rule and the newly approved fault-injection preflight; it does not justify another process layer.
Finding 2 — Some tool obligations exist between calls, not inside one call
Source: VIGIL
Dimensions: 3.4 primary, 3.6, 3.2
VIGIL intercepts a pending tool invocation, abstracts prior calls into typed events, preserves artifact identity across the trace and checks finite-trace obligations before allowing the side effect. On its primary 152-run set, it found 69 of 72 violations with eight false positives among 80 benign runs. The useful class is not malformed arguments. It is a sequence where each call appears valid alone—for example, consuming an intermediate artifact without the validation required earlier in the trace.
This is materially stronger than asking the same agent to remember whether it complied. The monitor's trigger is structural and pre-effect, so it avoids the circularity of self-assessment. The implication for future tool loops is narrow: when correctness depends on call order, artifact identity or prior approval, the verification object must be the trace prefix plus the proposed action, not just the current tool schema or final output. That is a design criterion to apply when the first qualifying authority/retry preflight is built, not a reason to retrofit every current task.
Finding 3 — Reliable capability is narrower than task completion, but should be no narrower than necessary
Source: Policy Algebra
Dimensions: 3.4 primary, 3.6, 3.1
The paper defines reliable capability as reaching the goal while every reasoning-to-action transition remains admissible under identity, role, profile, data, memory, tool, budget, artifact, approval and audit constraints. Delegation may narrow authority but not widen it. Its runtime reports intervention on 94.8% of policy-violating events, 86.9% task completion, 4.2% false intervention and 98.6% audit completeness across an author-constructed workload. It also redirects budget-exposed runs without an artifact towards a recoverable checkpoint rather than merely letting them exhaust the cap.
The numerical results are single-paper, finite-workload evidence and should not be treated as a production guarantee. The more durable contribution is the composition rule: restrictions should join monotonically across a path while the implementation remains least restrictive among states satisfying all constraints. For Maxi, this supports two existing principles—delegated work does not inherit broader authority than its caller, and budget exhaustion without a usable artifact is not successful execution. Both are already represented in the loop manifest, proposal gates and stop rules, so adoption work would currently be duplication.
5. Proposed Discussion Items
None.
Two candidates were filtered before inclusion:
- Adopt a generic trace-policy monitor: skip. It would touch protected runtime and tool infrastructure, while no local path-level enforcement defect has been demonstrated and VIGIL still depends on policy/event grounding.
- Add another production-scale verification rule: skip. Representative execution and real outcome verification are already mandatory, and Steve approved a bounded five-case preflight yesterday for the first qualifying future loop. A second gate would be procedural duplication.
6. Recommended Outcome
No action. Retain three design criteria for future authorised work: test against the environment that determines success; use external or agent-independent outcome checks where feasible; and evaluate cross-call obligations over the trace before the side effect. Apply them through the existing approved preflight and verification duties when a real qualifying loop appears.
Do not add a monitor, modify a skill, change Hermes, expand authority or alter the active experiment from this report.
7. No-Action Rationale
The research adds stronger evidence and a useful distinction between call-level and path-level correctness, but it does not expose a current local failure. Existing practice already requires real execution, authoritative postconditions, bounded fault injection, trace visibility and no authority widening. A generic enforcement layer would be expensive, protected-system work whose policy-grounding errors could create both false blocks and missed violations. Waiting for a concrete qualifying workflow is better than installing machinery in anticipation of one.
8. Loop Verification
- Trigger: Scheduled daily run.
- Goal check: Yes. The run found that reliable tool use requires three distinct checks—representative environment exposure, agent-independent outcome verification and stateful pre-effect checks for cross-call obligations—and established that current approved practice already covers the immediate need.
- Recommendation check: The no-action outcome is concrete, non-circular, bounded and approval-aware. Both candidate changes were filtered because they duplicate existing controls or lack a demonstrated local defect and proportionate verification path.
- Tool-call failures: The arXiv HTML route for the policy-algebra paper returned no converted paper, an infrastructure limitation recovered by inspecting the PDF. One already-indexed source was re-inspected because its source-index check and extraction were incorrectly parallelised; this was a capability-gap/process failure, so I excluded it as new evidence, updated rather than duplicated its source record, and reinforced the existing reflection requiring exact-URL checks to complete before extraction. The first compound JSON-update command was blocked by the execution interface's gateway-restart detector despite containing no restart operation; this was a schema/interface failure recovered by applying narrow, validated file patches instead.
- State updates: Added or updated five inspected-source records in
source-index.json; advancedrotation-state.jsonto 3.5; reinforcedrefl-2026-07-26-001; wrote this report. No protected system changed. - Stop reason: Two consecutive searches produced no new inspectable source, the useful findings converged on controls already active or approved, and the next intervention would touch protected systems without a demonstrated local need.
