Improvement Research — 2026-08-02

1. Focus

Primary dimension: 3.4 — Tool use and environment control.

The rotation state pointed to 3.4. No watchlist item was due on 2 August, and the August monthly meta-review was completed on 1 August.

Trigger: Scheduled daily run, with active reflections loaded 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 newsletter scouts were inspected before web research. They supplied leads, especially Cursor's account of its cloud-agent environment, but were not treated as evidence.

Checkpoint: The focus remained on mechanical capability: how environment and tool-interface design alter reliable agent action. Governance appeared only where action surfaces affect control and blast radius; it did not redirect the run.

2. Search Topics

1. AI agent environment legibility, reproducibility, cloud coding-agent failures and testing.
2. Agent tool-interface design, error recovery, action surfaces and production evaluation.
3. Runtime validation, sandboxes and proof artifacts for coding agents.
4. Repository legibility, unified commands and supervision for long-running processes.
5. Tool-description quality, constrained action spaces and tool-use benchmarks.

Five of the six allowed searches were used. The first three searches returned relevant but mostly familiar reliability material; the fourth and fifth exposed new primary or worked sources. The early-stop rule did not trigger because there were not two consecutive searches containing only already-indexed or irrelevant results.

Checkpoint: Narrowing from generic reliability to environment legibility and tool-interface mechanics sharpened the original focus rather than replacing it.

3. Sources Reviewed

• Cursor — How we set up our cloud agent environment — useful — First-party account in which skills helped only at the margins until convoluted build paths were replaced by a unified CLI, supervised processes, inspectable environments and end-to-end verification.
• Agent behavior — useful — Separates a recurring behavioural standard from runtime prompts, task skills, tool manuals, evals and traces; useful against instruction-layer accretion, but not evidence for adding another Maxi artifact.
• Simon Willison — Stateless MCP has recaptured my interest — useful — Worked implementation examples of simpler stateless tool calls and narrow, inspectable capabilities.
• Guo et al. — Learning to Rewrite Tool Descriptions for Reliable LLM-Agent Tool Use — useful — Preprint reports better tool selection and execution when agent-facing descriptions are optimised, including harder multi-hop and cross-domain tests.
• OpenAI — Harness engineering: leveraging Codex in an agent-first world — useful — First-party case study of runnable isolated environments, directly legible logs and metrics, executable verification, progressive disclosure and repository-local context.
• Model Context Protocol — The 2026-07-28 Specification — useful — Primary release account for self-describing stateless requests, explicit state handles, header-visible routing and authorisation, deterministic lists and cache hints.

All six sources were new to the source index and have been added. I checked the first five exact URLs before depth inspection. I mistakenly fetched the official MCP release page before its exact-URL check; it was not indexed, so no duplicate research occurred, but the sequence still violated the source-index-first rule. I reinforced the existing reflection for that failure pattern.

Checkpoint: Every retained source bears on the action surface, environment legibility or separation between standards and implementation. None was allowed to turn a 3.4 run into generic protocol or product news.

3a. Unasked Questions and Gaps

1. How much of Cursor's and OpenAI's reported improvement was caused by environment simplification rather than stronger models, task selection or organisational investment? The accounts do not isolate those variables. A different answer would change the strength of the causal claim, but not the narrower conclusion that convoluted workflows impose avoidable mechanical burden.
2. Does Maxi currently have a recurring failure caused by an over-complex tool or command path? This run did not establish one. If a trace-backed local pattern exists, a bounded interface simplification could become actionable; without one, a general tool audit would be speculative work.
3. Do the tool-description paper's synthetic training and benchmark results transfer to Hermes tools and current frontier models? Unknown. Failure to transfer would weaken the description-optimisation claim, though the practitioner evidence for simpler action paths would remain.
4. Would stateless MCP improve any currently authorised Maxi workflow enough to justify migration cost? Not established, and no current-system migration assessment was authorised or needed. A negative answer would leave the protocol as design evidence only.
5. Would a separate behaviour-spec layer reduce review burden here, or merely duplicate the mandate, skills and report checks? No local failure case was identified. If duplication dominates, the correct outcome remains no action.

Checkpoint: These gaps materially constrain implementation. They do not erase the diagnostic lesson, but they block a system or process recommendation.

4. Findings and Implications

Finding 1 — Operational complexity can be an environment defect, not an instruction defect

Sources: Cursor; OpenAI; Guo et al.

Dimensions: Primary 3.4 — Tool use and environment control; secondary 3.2 — Self-assessment and learning loops; 3.6 — Governance.

Cursor reports that skills documenting its existing build commands helped only at the margins because the commands themselves were convoluted and full of footguns. Reliability improved after it replaced that path with one discoverable CLI, delegated long-running process supervision away from the model, and made end-to-end proof directly available. OpenAI independently describes its main engineering work as making capabilities legible and enforceable through isolated runnable environments, directly queryable observability and executable feedback loops rather than telling an agent to “try harder.” The tool-description preprint supplies narrower experimental evidence that the interface presented to the agent is itself a performance variable.

The case-study adoption and throughput numbers are self-reported and confounded, and the paper is not a Hermes evaluation. The justified conclusion is therefore narrower than “simpler tools will make Maxi better”: when an agent repeatedly fails along the same mechanical path, I should first ask whether the action surface is needlessly complex, hidden or unverifiable before proposing another instruction.

Implication for my agency development: This improves diagnosis tomorrow. More procedure is not automatically more capability. A better intervention order is: establish the recurring trace-backed failure, inspect the tool or environment path, simplify or expose the missing state if justified, then add minimal guidance only where the remaining interface genuinely needs it. That protects context, lowers error opportunities and makes verification more direct without expanding authority.

Finding 2 — Explicit, self-describing state reduces both mechanical and oversight burden

Sources: Model Context Protocol 2026-07-28 release; Simon Willison's worked implementations.

Dimensions: Primary 3.4 — Tool use and environment control; secondary 3.6 — Governance.

The new MCP core removes hidden transport sessions: each request carries its protocol version, client identity and capabilities, while application state can be represented by an explicit handle passed between tools. Method and tool names are exposed in headers for routing, metering and authorisation. Willison's worked examples show the practical difference: a single stateless call replaces handshake-plus-session bookkeeping, and a deliberately small read-only tool set is easier to inspect than unconstrained shell and network access.

This does not prove that MCP is universally safer, nor that Maxi should migrate anything. A narrow tool can still be badly designed or connected to unsafe data flows. The useful mechanism is explicitness: hidden state and open-ended capability make both recovery and oversight harder.

Implication for my agency development: For future tool or loop designs, I should favour explicit state passed in inspectable artifacts, narrow verbs, deterministic discovery and externally enforceable routing or authorisation over ambient session assumptions. This is consistent with “smallest sufficient freedom”: it can increase usable capability while reducing what must be inferred or trusted.

Finding 3 — A standard of behaviour is not the same artifact as its runtime implementation

Sources: Agent behavior; OpenAI.

Dimensions: Primary 3.2 — Self-assessment and learning loops; secondary 3.4 — Tool use and environment control; 3.6 — Governance.

Agent behavior explicitly distinguishes durable expectations from prompts, skills, tool documentation, evals and traces. OpenAI reports a related failure at the runtime layer: a monolithic instruction file consumed context, became stale and resisted mechanical verification, so it was reduced to a map pointing to deeper sources of truth.

The proposed behaviour format is new and has no demonstrated benefit in Maxi's environment. Its value here is conceptual, not adoptive: identify which layer failed before editing any layer.

Implication for my agency development: When conduct is wrong, the correction question should be specific. Was the standard absent, the runtime instruction unclear, the tool incapable, or the verification missing? Copying the same rule into every layer increases context and maintenance without necessarily increasing compliance. This reinforces simplicity before machinery and the existing separation between identity, procedure, subsystem facts and operational evidence.

Checkpoint: The findings answer the 3.4 question at mechanism level and preserve their evidential limits. They do not infer a Maxi implementation need from external success stories.

5. Proposed Discussion Items

None.

Two candidates were filtered before reaching Steve:

• A general audit of all Maxi tools and command paths — skipped by the self-recommendation filter because there is no trace-backed local failure or bounded target; this would be speculative maintenance rather than useful research.
• Adopt Agent behavior files — skipped because the current evidence does not show a missing artifact layer, and the format could duplicate existing mandate, skill, verification and reflection functions.

Neither candidate is circular or threshold-equivalent; both fail the stronger utility test of being better than doing nothing now.

Checkpoint: The section protects Steve's attention. No external source was allowed to manufacture a proposal without a local problem and verification path.

6. Recommended Outcome

No action. Retain the findings as an evidence-backed diagnostic preference: for a repeated mechanical failure, test interface and environment debt before proposing instruction growth. Any future implementation still needs a concrete local failure, a smallest-sufficient change, success criteria, rollback and Steve's approval where protected systems are involved.

Checkpoint: This outcome is bounded, approval-aware and better than a speculative audit or new artifact layer.

7. No-Action Rationale

The research changed my judgment but did not reveal a current defect that warrants intervention. Cursor and OpenAI provide strong practitioner convergence but weak causal isolation; the paper provides experimental support but no Hermes transfer evidence; the MCP material provides a design example but no local migration case.

Doing nothing to the system is therefore the rigorous choice. The immediate value is to avoid a common wrong turn: answering mechanical unreliability with more prompt or skill text before establishing whether the action path itself is the problem.

Checkpoint: No-action follows from the missing local failure and transfer evidence, not from lack of signal.

8. Loop Verification

• Trigger: Scheduled daily run; active reflections reviewed.
• Goal check: Yes. The run found a practical judgment improvement: distinguish environment/interface debt from instruction debt, and favour explicit, narrow, verifiable action surfaces.
• Recommendation check: No material change was proposed. The no-action outcome is concrete, non-circular, bounded and approval-aware; future action requires an observed local failure and verification path.
• State updates: Added six inspected sources to source-index.json; advanced rotation from 3.4 to 3.5; updated last-run state; reinforced refl-2026-07-26-001 after repeating its exact-URL-check ordering failure. No watchlist, backlog, experiment, disagreement, decision or protected-system state changed.
• Process note: One source-index sequence error occurred for the official MCP release page. It caused no duplicate inspection, but it repeated a known process failure and was recorded rather than excused.
• Stop reason: Five searches and six depth inspections were sufficient. Evidence converged on a usable diagnostic lesson, while the missing local failure and transfer evidence stopped the loop before a speculative protected-system proposal.