Papers
Topics
Authors
Recent
Search
2000 character limit reached

Regimes: An Auditable, Held-Out-Gated Improvement Loop Demonstrated on LongMemEval with ActiveGraph

Published 8 Jun 2026 in cs.AI | (2606.10241v1)

Abstract: Autonomous improvement loops are hard to trust because the improvement process is usually external scaffolding bolted onto the agent: failures go unlogged, diagnoses cannot be replayed, and promote-or-discard decisions land in a side database rather than the agent's own history. We show that an event-sourced agent runtime removes that friction and turns controlled improvement into a first-class workflow. When the agent's state is a deterministic projection of an append-only event log, failures are recorded, a run replays exactly from its log, candidate patches scope to typed pipeline seams, gates are auditable, and every promotion or discard is itself an event. We demonstrate this with Regimes, a loop on the ActiveGraph runtime that diagnoses failed evaluations, proposes a repair at a pipeline point, and promotes it only after static checks, sandbox execution, in-sample evaluation, and held-out validation. The loop is target-agnostic: the same control flow runs against different tasks through a common interface. On LongMemEval-S the dominant failure is not retrieval but reconciliation: the evidence is already in the assembled context, yet the reader answers incorrectly. Across five seeded held-out splits, Regimes discovers reader-prompt repairs that improve final held-out accuracy by +0.05 to +0.10 in four splits and +0.01 in one over-promotion split; two splits are individually significant (seed 5 unadjusted for its sequential promotion structure), and the pooled count is descriptive only, since the splits share one 500-question pool. The durable contributions are ActiveGraph as an auditable substrate that makes controlled improvement loops tractable, the held-out-gated loop it supports, the failure-regime taxonomy routing each failure to a pipeline location (whose marginal value over an unrouted baseline is the primary open question), and the prompt-as-discovery-probe hypothesis.

Authors (1)

Summary

  • The paper demonstrates an auditable, held-out-gated improvement loop that deterministically diagnoses and corrects LLM errors via regime-to-seam routing.
  • It leverages event-sourced ActiveGraph to ensure reproducibility, robust auditing, and static validation of self-improvements across multiple data splits.
  • Empirical results on LongMemEval-S show statistically significant accuracy gains and minimal false positives, affirming the safety and efficacy of the approach.

Auditable Self-Improvement Loops in LLM Agents: An Analysis of "Regimes" (2606.10241)

Motivation and Problem Setting

The paper "Regimes: An Auditable, Held-Out-Gated Improvement Loop Demonstrated on LongMemEval with ActiveGraph" addresses the unreliability and opacity of autonomous improvement loops (AILs) for LLM-based agents. Traditional improvement scaffolding is typically external, logs are fragmented or incomplete, and the process is difficult to audit or reproduce. There is a pressing need for auditable, deterministic, and tightly integrated self-improvement mechanisms in agentic AI, especially as these systems are deployed in increasingly critical or high-stakes settings.

Methodology: Event-Sourced Improvement via ActiveGraph

The core methodological innovation is the Regimes loop, executed atop the ActiveGraph runtime. ActiveGraph's pivotal property is event sourcing: the system's entire state is a deterministic projection of an append-only event log. All operations—diagnosis, patch proposal, validation, promotion, or discard—become auditable events in this log. This architecture allows for complete deterministic replay, robust auditing, and forensic analysis. Model and tool outputs are cached, ensuring that replay never incurs new external calls, a critical feature for experimental reproducibility and process reliability.

Regimes orchestrates agent self-improvement through several steps:

  1. Failure Diagnosis: The agent's failures are classified into specific regimes based on deterministic, gold-label-based detectors.
  2. Regime-to-Seam Routing: Each failure regime is mapped to a specific "action seam" in the agent pipeline—score reweighting, context assembly, or reader prompt editing.
  3. Patch Authoring: For each regime, a dedicated LLM (e.g., Claude-Sonnet-4-6) authors executable transforms at the mapped seam.
  4. Gating and Validation: Candidate patches are funneled through stringent static checks, sandbox execution, in-sample (development) evaluation, and—crucially—validation on held-out example splits.
  5. Promotion or Discard: Only patches that improve held-out performance and avoid regressions are promoted, with every decision logged for auditability.

Experimental Evaluation: LongMemEval-S as Stress Test

The primary empirical setting is LongMemEval-S, a challenging benchmark for long-context, chat-based memory tasks. The regime-to-seam taxonomy is essential for localizing errors that relate not to retrieval deficiencies but to evidence reconciliation—the dominant failure mode post-retrieval saturation. Specifically, "assemble-internal" failures (evidence present but misused) are targeted via reader-prompt edits.

Key experimental features include:

  • Stratified Cross-Validation: Five independent splits (OPTIMIZE and CONFIRM) are used, with clear separation between tuning and validation data per run.
  • Replication Across Seeds: To probe robustness, the loop is re-run across multiple seeded random splits from the 500-question benchmark.
  • Auditable, Deterministic Logging: Every run (diagnoses, proposals, gating, outcomes) is fully replayable from logs, conditioned on cached responses.

Results and Analysis

Numerical Results

  • Held-Out Accuracy Gains: Across five fresh splits, Regimes improved held-out accuracy by +0.05 to +0.10 in four runs and +0.01 in one run that exhibited over-promotion.
  • Split-Wise Statistical Support: Two splits demonstrated statistically significant improvements (McNemar’s p < 0.05), with the strongest split realizing a +0.10 improvement.
  • Low False Positive Rate: Right-to-wrong answer flips were minimal (≤2 in all but one split), underscoring the safety of the gating process.
  • Pooled Descriptive Gains: Across all splits, 43 answers improved from wrong-to-right versus 13 regressions (McNemar’s p = 7.3e-05, caveated by shared pool).
  • Effect Localization: Gains largely localized to assemble-internal regimes, affirming the efficacy of regime-to-seam routing for these error types.

Diagnostic and Theoretical Contributions

  • Regime-to-Seam Taxonomy: The explicit mapping from failure regime to correction seam (score-transform, assembly-transform, reader-prompt-transform) organizes agent self-repair in a principled, targeted, and auditable fashion.
  • Held-Out-Gated Improvement: The strict gating mechanism discarded nearly all overfit (in-sample only) repairs, with only robust, generalizable changes admitted.
  • Failure Mode Insights: Promoted prompt edits recurrently targeted reconciliation strategies: trusting retrieved context, integrating evidence across sessions, resolving temporal expressions, and guarded use of anti-hedging.
  • Identified Pathologies: Over-promotion (seed 101) highlighted the necessity of plateau-aware stopping and raised the default promotion threshold (to surpass model variance/noise).
  • Operator Hypothesis: Prompt repairs that produce repeatable gains often implicitly encode structural behaviors; future improvements should distill these into guarded, deterministic operators—moving toward explicit, structural solutions rather than ad hoc prompt patching.

System and Control-Flow Generality

  • Target-Agnostic Loop: The loop was abstracted and re-homed to a text-to-SQL agent, demonstrating interface and control-flow generality (byte-identical event logs); however, empirical improvement was not claimed outside LongMemEval-S due to the near-ceiling performance of the second task.
  • Robustness: The loop's control logic was hardened against adversarial (chaotic-mock) candidate proposals, ensuring no fragile or brittle pathways in production deployment.

Implications and Future Directions

Practical Implications

  • Auditability and Replay: Event-sourced agent architectures like ActiveGraph provide an effective substrate for research on self-improving agents, establishing a new standard for experimental reproducibility, audit trails, and system transparency in LLMPipelines.
  • Reliability of Self-Improvement: Combining regime-to-seam routing with stringent held-out gating maximizes the reliability of self-improving workflows, avoiding the common pitfalls of overfitting, undetectable regressions, or silent failures.

Theoretical Implications

  • From Prompts to Operators: The repeatability and content of successful prompt repairs suggest an externalization path toward synthetic, composable, and guard-conditioned operators. Such operators should be induced from repeated prompt discoveries and validated through the same held-out loop, resulting in more robust, interpretable, and generalizable improvements.
  • Failure Taxonomy as Instrument: A fine-grained, executable failure taxonomy not only enables targeted repair but also offers a lens for understanding agent pipelines, benchmarking error regimes, and guiding future architectural changes.

Directions for Future Work

  • No-Routing Ablation: To isolate the marginal value of regime-directed routing over naive failed-example authoring, a direct control/ablation experiment is needed.
  • Operator Distillation and Synthesis: Explicit distillation of durable operators from recurring prompt fixes, and their gating via structure-detection rather than question labels, represents the next theoretical and practical frontier.
  • Hardening Promotion Criteria: Implementing plateau-aware stopping and noise-calibrated thresholds to avoid cumulative prompt cruft without accuracy gain.
  • Transferability and Wider Validation: Applying the loop to a broader set of agent tasks, models, and benchmarks, and validating cross-task efficacy.

Conclusion

"Regimes" (2606.10241) delivers an auditable, held-out-gated improvement loop for LLM agents that robustly, deterministically, and transparently improves agent behavior in the regime of reconciliation (post-retrieval evidence use) on LongMemEval-S. The combination of deterministic event-sourced substrates, executable failure taxonomies, and strong held-out gating demonstrates reliable, modest improvements while diagnosing real architectural limits of current self-improving loops. The findings suggest a path forward toward converting prompt-based probes into durable, guard-conditioned deterministic operators. This system-level, substrate-forward approach reframes the locus of innovation from local repairs to the overall architecture enabling safe and auditable self-improvement in agentic AI.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

What this paper is about (big picture)

The paper introduces a way for AI systems to safely improve themselves — and for people to trust those improvements. It does this with two main pieces:

  • ActiveGraph: think of it like a black box that records every action the AI takes, step by step, so you can replay exactly what happened later.
  • Regimes: an improvement loop that spots where the AI went wrong, suggests a fix, tests that fix carefully (including on new, unseen examples), and only keeps it if it really helps.

They show this working on a long-memory question-answering test called LongMemEval, where the hardest part isn’t finding the right information but using it correctly once it’s already in front of the AI.

What the researchers wanted to find out

In simple terms, they asked:

  • Can we build a “self-improvement loop” for an AI that’s trustworthy because every change is recorded and can be replayed exactly?
  • Can that loop avoid “overfitting” (improvements that only work on the examples it saw while tuning) by requiring success on held-out (unseen) questions before accepting the change?
  • Can the same improvement loop work across different kinds of AI tasks without being rewritten each time?
  • On LongMemEval, where the AI often has the right evidence but still answers wrong, can small, targeted prompt edits to the AI’s “reader” actually fix this?

How it works (methods in everyday language)

Imagine the AI as a factory line:

  • It stores history, retrieves useful bits, assembles them, then “reads” that assembled context to answer a question.
  • Problems can happen at different stations on the line (retrieve, assemble, read).

Now add two key ideas:

  1. A perfect replayable log (ActiveGraph)
  • Every step the AI takes is written into a diary (an “event log”) that you never erase, only add to.
  • Because the AI’s state is rebuilt from this diary, you can rewind and replay exactly, like playing a recorded game with no surprises.
  • Model/tool responses are cached so replays don’t hit the model again — they’re truly identical.
  1. A careful improvement loop (Regimes)
  • Diagnose: When the AI gets an answer wrong, it labels the reason (the “failure regime”). Example: “assemble-internal” means the right evidence was in the context, but the reader still answered wrong — a reconciliation failure.
  • Route: Each failure type points to a specific “seam” (the exact part of the pipeline you’re allowed to edit). For example:
    • If evidence was dropped, adjust retrieval or assembly.
    • If the reader misused evidence, edit the reader’s prompt.
  • Author: A LLM proposes a candidate fix at that seam (like a small patch).
  • Gate (a series of safety checks):
    • Static checks: Is the patch safe and well-formed (no disallowed imports, reasonable size, etc.)?
    • Sandbox: Does it run without crashing?
    • In-sample test: Does it help on the practice set (OPTIMIZE) without making other things worse?
    • Held-out validation: Most important — does it also help on new, unseen questions (CONFIRM)? Only then is it “promoted” (kept).
  • Rotate: If a fix fails a gate, it’s discarded and recorded; try the next idea or the next failure type. Stop when you run out of sensible ideas.

Two helpful analogies:

  • Held-out validation is like studying for a test: you don’t count “improvements” that only ace the homework you already saw. You must also do well on new problems.
  • Seams are like access panels on a machine: you only fix the part that’s actually connected to the failure.

They also tested that the same loop can plug into a very different task (text-to-SQL) without changing the loop’s logic — this is the “target-agnostic” claim.

What they found (main results)

On LongMemEval (long conversation memories):

  • The biggest problem wasn’t finding the right messages; it was using already-present evidence correctly (the “assemble-internal” failure).
  • The improvement loop often discovered useful edits to the “reader prompt” — short instructions that nudge the AI to use evidence more carefully.

Across five runs (each using different, held-out question splits):

  • Four runs showed meaningful held-out accuracy gains of about +0.05 to +0.10.
  • One run only improved by +0.01 (basically flat). This revealed a useful lesson: if your promotion threshold is too forgiving (accepting tiny, within-noise gains), you can “over-promote” small changes and end up with little or no real improvement.
  • In two runs, the improvement was statistically strong on their own.
  • The held-out gate did its job: it rejected many fixes that looked good on the practice set but didn’t generalize.
  • Edits that tried to fiddle with retrieval scores rarely helped here, because the evidence was usually already present; the reader’s use of it was the issue.

Extra system-level findings:

  • Because ActiveGraph logs everything and enforces exact replay, the whole process is auditable: you can see every diagnosis, every proposed fix, every accept/reject decision, and replay runs exactly.
  • The same improvement loop ran unchanged on a different task (text-to-SQL). It didn’t show a gain there, but mainly because the model was already near-perfect on that small test; the point was the loop’s portability, not a new record.

Why this matters

  • Trust: Self-improving AIs can be risky if you can’t see what changed or why. Here, every step is recorded and replayable, so claims of improvement are transparent and checkable.
  • Real improvement, not hype: The held-out gate filters out overfitting. Gains that pass this gate are more likely to stick.
  • Practical insights: The successful prompt edits act like “discovery probes” — they reveal which evidence-use behaviors actually help. The authors suggest turning these insights into firm, rule-like “operators” later, so improvements don’t depend on vague, free-text prompts.
  • General tool, not a one-off: The loop is designed to plug into different tasks, which could make controlled self-improvement a reusable workflow rather than a custom hack each time.

So what’s next? (implications and future impact)

  • Tighten the rules for promotions: Raise the threshold for held-out gains and add a “plateau-aware” stopping rule so the loop doesn’t accept tiny, noisy changes.
  • Distill prompts into robust operators: Convert the helpful behaviors found by prompt edits into clear, deterministic rules that only activate when specific patterns are detected.
  • Broader use: Because the loop runs on a generic, auditable substrate, teams could apply it to many agent pipelines (not just long-memory tasks).
  • Open question: How much extra value comes from diagnosing failure types and routing to a specific seam, compared to just trying fixes and gating them? The paper flags this as a main question for future tests.

In short: The paper shows that careful logging and strict validation can make AI self-improvement both safer and real. It delivers steady gains on a tough “use the evidence you already have” problem, and it lays groundwork for turning prompt tweaks into durable, rule-based upgrades.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a single, focused list of what remains missing, uncertain, or unexplored in the paper, phrased to guide concrete follow-up work.

  • Marginal value of regime-to-seam routing untested: run a no-routing ablation (give the author failed examples + held-out gate but no regime labels or seam constraints) to quantify the routing step’s contribution to effect size, sample efficiency, and regression control.
  • Held-out reuse inflates Type I error in multi-promotion runs: implement and evaluate a third split (e.g., OPTIMIZE/CONFIRM/VERIFY) or sequential testing/alpha-spending to prevent adaptive overuse of the same held-out; report how stricter procedures change promotion rates and final accuracy.
  • Promotion threshold too permissive at high baselines: systematically sweep confirm_threshold (e.g., 0.00 → 0.02–0.05) and compare with repeated-confirm evaluation (multiple independent reads per candidate) to ensure improvements clear the reader-noise band.
  • Plateau-aware stopping and over-promotion control not implemented: formalize and test stopping rules (e.g., require sustained deltas, CI overlap checks, or minimum unique wrong→right flips per promotion) to prevent accuracy drift from stacking within-noise promotes.
  • Reader noise and variance not characterized rigorously: estimate per-split variance with replicated evaluations (fresh API calls) and/or multi-read ensembling; use those estimates to set thresholds and confidence intervals prospectively.
  • Regime classifier validity and deployability are unverified: obtain human validation of regime labels, measure inter-annotator agreement, and report precision/recall of detectors; develop detectors that do not depend on gold evidence (needed for real deployments), and assess how detector errors affect routing and outcomes.
  • Generalization beyond a single task and reader is untested: evaluate the loop on additional targets with measurable headroom and across multiple LLM readers (and authors) to test task- and model-robustness; include ablations where author and reader models differ.
  • SQL target only used as a control-flow unit test (ceilinged): identify alternative SQL (or other) fixtures with non-ceiling baselines to test empirical-improvement generality; report why some targets lack seam-reachable headroom and how to create it.
  • “True wall” regimes (retrieval-signal-gap, scoring-error) left unaddressed: explore added seams and tools (e.g., query rewriting, retriever re-ranking with learned features, retriever fine-tuning, external search/tools) to convert these from walls to actionable seams.
  • Score/assembly transforms underexplored and weakly effective: analyze why score re-weighting rarely generalized (feature design, overfitting, alignment with failure signals); propose and test structured transforms (e.g., learned rank fusion, budget-aware selection) with held-out gating.
  • Prompt repairs not distilled into guarded deterministic operators: specify candidate operators implied by recurring prompt clauses, define detection features (typed projections on the event log), implement guards, and compare operators vs. prompts on held-out accuracy and regression rates.
  • Interactions among multiple promotions are not modeled: study compositionality (do later repairs undo earlier gains?), define conflict-resolution/rollback policies, and measure monotonicity under different stacking strategies.
  • Sensitivity to OPTIMIZE/CONFIRM sizes and split strategy unmeasured: vary split sizes (e.g., 50/100 vs. larger) and stratification schemes to quantify stability of routing histograms, detection of dominant regimes, and confirm deltas.
  • Same-pool limitation for multi-seed results: replicate on disjoint benchmark pools or external datasets to eliminate same-pool dependence and report population-level significance.
  • Statistical procedures are exploratory, not pre-registered: pre-register primary endpoints, tests (e.g., McNemar, bootstrap), and correction plans for multiplicity; compare results under the pre-registered analysis to current exploratory findings.
  • Determinism guarantees are cache-conditional and model-endpoint fragile: quantify divergence when cache misses occur or endpoints update; define and test cross-hardware/provider determinism envelopes and their impact on confidence in promotions.
  • Limited per-question metadata persistence restricts auditability: persist full per-question traces (labels, abstention flags, regime assignments, candidate diffs) for all splits, and release event logs to enable external audit and reanalysis.
  • Author/reader configuration dependence unexamined: ablate author model choice, temperature, and decoding constraints; test cross-model authoring (e.g., smaller/cheaper authors) for cost-effectiveness and diversity of candidate repairs.
  • Cost, throughput, and sample-efficiency not reported: measure end-to-end compute/time/$$ per successful promotion; report candidate funnel costs by gate; compare against simpler baselines (e.g., manual prompt edits, unconstrained prompt search) for cost-adjusted gains.
  • Security/safety of transform execution only partially addressed: stress-test static/sandbox gates with adversarial candidates (prompt injections, obfuscated code) and measure coverage; formalize a policy for permissible prompt edits (e.g., maximum diff semantics, forbidden patterns).
  • Abstention behavior analyzed only on one split (incomplete): extend abstention and per-type analyses beyond seed 7; evaluate whether improvements trade off with appropriate abstentions and calibrate for abstention quality, not just accuracy.
  • Reliance on offline gold signals limits deployability: design and evaluate weakly supervised or self-supervised signals (e.g., retrieval-consistency checks, contradiction detectors) to enable real-time regime diagnosis without gold annotations.
  • Benchmark coverage narrow (LongMemEval-S only): test on LongMemEval-V2 and related long-context tasks (e.g., tool-augmented memory, streaming contexts) to assess whether reconciliation-focused gains transfer to broader settings.
  • Acceptance criteria localized to accuracy deltas: explore multi-metric gates (calibration, abstention quality, latency, context budget usage) and composite thresholds to ensure promoted transforms improve overall agent quality, not just accuracy.
View Paper Prompt  View All Prompts 

Practical Applications

Immediate Applications

Below are specific, deployable use cases that leverage the paper’s event-sourced substrate (ActiveGraph), held-out-gated improvement loop (Regimes), failure-regime taxonomy, and deterministic replay.

  • Auditable agent deployments and change control (software, finance, healthcare, government)
    • What: Deploy LLM agents on an event-sourced runtime where every run, diagnosis, patch proposal, gate outcome, and promote/discard is logged as an immutable event. Promote only those changes that pass held-out validation.
    • Tools/workflows: ActiveGraph-compatible runtime; Regimes loop or equivalent “diagnose-author-gate-promote” pipeline; per-candidate marginal evaluation reports; approval workflows mapped to gate outcomes.
    • Assumptions/dependencies: Adoption of an event-sourced architecture and content-addressed caching; availability of representative held-out sets; static/sandbox gates integrated with org security policies.
  • Safe prompt/program iteration with held-out gates (software, platform/ML tooling)
    • What: Improve prompts/program snippets with a binding held-out gate to prevent overfitting to development examples.
    • Tools/workflows: Integration of a CONFIRM threshold (e.g., ≥ +0.02 to clear noise bands) into existing frameworks (DSPy-like pipelines, LangChain/LlamaIndex stacks); OPTIMIZE vs. CONFIRM split management.
    • Assumptions/dependencies: Reliable evaluation harnesses; cost budget for repeated held-out scoring; baseline noise characterization.
  • Failure-regime dashboards for triage and prioritization (software, enterprise AI/IT)
    • What: Classify failures into regimes (e.g., retrieval vs. reconciliation) and route fixes to specific seams (score, assembly, or reader-prompt). Focus teams on the seam that moves the needle.
    • Tools/workflows: Regime histogram visualizations; seam-specific playbooks; alerting when a “true wall” regime dominates.
    • Assumptions/dependencies: Access to failure signals (may require offline gold annotations for diagnosis); quality of the regime detector impacts routing value.
  • Enterprise RAG “reconciliation” upgrades (customer support, legal/eDiscovery, knowledge management)
    • What: For long-context assistants where relevant evidence is present but misused (assemble-internal), deploy reader-prompt repairs that bias the agent toward cross-checking, recency-aware reconciliation, abstention on conflict, and explicit citation.
    • Tools/workflows: Reader-prompt transform seam; in-sample then held-out confirmation; regression-bounded acceptance rule.
    • Assumptions/dependencies: Long-context retrieval already strong; representative held-out conversations; careful tuning of abstention behavior to align with business KPIs.
  • Deterministic replay for reproducibility and cost control (academia, ML platforms, regulated industries)
    • What: Use an event-sourced cache of model/tool responses to replay runs exactly, enabling repeatable audits without extra API spend.
    • Tools/workflows: Content-addressed caching; run replayer that can “time-travel” to any event sequence; reproducibility badges in experiment tracking.
    • Assumptions/dependencies: Stable cache management; clear policies for cache invalidation when models update.
  • Continuous improvement with guardrails for enterprise assistants (HR IT, internal helpdesks, operations)
    • What: Run a periodic improvement loop that drafts small, scoped patches (e.g., prompt fragments), evaluates them in-sample, validates on held-out, and promotes only non-regressing changes.
    • Tools/workflows: Weekly/batch “optimize-confirm-promote” job; plateau-aware confirm threshold (at minimum set > 0 to avoid within-noise promotes); roll-back via event-log reversion.
    • Assumptions/dependencies: Sufficient traffic or archived queries to build OPTIMIZE/CONFIRM sets; governance alignment on non-regression criteria.
  • Chaotic-mock hardening for agent pipelines (software QA, security)
    • What: Use adversarial/chaotic mocks that emit invalid code, sandbox crashes, and regressions to validate that the improvement loop rotates, terminates, and records failures safely.
    • Tools/workflows: Fuzzers for candidate authors; one-sink discard path; runner backstops that prevent null termination.
    • Assumptions/dependencies: Sandboxed execution environment; strict import whitelists; monitoring to catch unanticipated behaviors.
  • Audit-ready AI governance and compliance templates (policy, risk management, internal audit)
    • What: Establish “self-improvement governance” that requires event logs, deterministic replay, and held-out-gated promotions for any change to production agents.
    • Tools/workflows: Policy templates aligned with NIST AI RMF/EU AI Act; attestations containing per-candidate marginal deltas and gate outcomes.
    • Assumptions/dependencies: Dedicated audit storage; role-based access to logs; acceptance by compliance stakeholders.
  • Safer text-to-SQL and tool-use agents (software, data platforms)
    • What: Even if performance is near ceiling, adopt the loop’s safety infrastructure—static/sandbox gates, per-candidate marginal evaluation, deterministic replay—to prevent regressions and facilitate audits.
    • Tools/workflows: SQL execution harness in evaluation; prompt-only seam for databases; byte-identical control-flow tests across targets.
    • Assumptions/dependencies: High-fidelity offline evaluation of SQL correctness; guardrails for data privacy.
  • Sector-specific deployment with audit trails
    • Healthcare: Clinical decision support chatbots that only promote evidence-use prompt changes after held-out checks; full traceability for QA committees.
    • Finance: Customer service and compliance assistants with per-patch held-out validation and immutable change histories.
    • Education: Tutoring systems that learn better guidance without overfitting to a teacher’s examples; logs for educator review.
    • Assumptions/dependencies: Domain-appropriate held-out data and evaluation metrics; human oversight processes; strict PII handling in event logs.

Long-Term Applications

These use cases require further research, scaling, or standardization before broad deployment.

  • From prompts to guarded deterministic operators (software, platform tooling)
    • What: Distill repeatedly successful prompt clauses (evidence-use behaviors) into typed, deterministic operators that fire on detected structure (e.g., conflict detection → abstain-and-ask).
    • Potential products: Operator libraries for reconciliation, recency-handling, contradiction resolution; operator registries with versioning on the event log.
    • Assumptions/dependencies: Reliable structure detectors; benchmarks to validate operator triggering; integration patterns for operator composition.
  • Cross-task, target-agnostic self-improvement at scale (general AI systems)
    • What: Demonstrate empirical improvements across diverse tasks (beyond long-context QA) with the same loop and gates by swapping only the Target interface.
    • Potential products: Multi-domain “self-tuning” agents where regime detectors and seams are modular plug-ins.
    • Assumptions/dependencies: High-quality, task-specific evaluators and held-out sets; ablations to quantify routing’s marginal value over no-routing baselines.
  • Online held-out gating with canaries and plateau-aware stopping (production ML Ops)
    • What: Continuous deployment where each candidate runs on shadow/canary traffic; promote only if out-of-sample uplift exceeds noise and plateau rules say continued edits are warranted.
    • Potential products: “Safe Autotuning” MLOps suite; adaptive thresholds; automated stop conditions to prevent over-promotion drifts.
    • Assumptions/dependencies: Sufficient traffic for statistical power; advanced sequential testing or Bayesian monitoring; guardrails for multiple comparisons.
  • Industry standards for AI event logs and replay (policy, standards bodies)
    • What: Define minimum viable “auditable AI” standards requiring event-sourced logs, deterministic replays, and binding held-out validation for self-modifying agents.
    • Potential products: Compliance certifications; audit APIs for third-party assessors.
    • Assumptions/dependencies: Multi-stakeholder consensus; mapping to existing regs (EU AI Act, sectoral guidance).
  • Marketplace for vetted transforms/operators (software ecosystems)
    • What: Share and reuse transforms or operators with provenance, performance on public held-out sets, and safety metadata.
    • Potential products: Registries integrated with package managers; “trust scores” derived from confirm deltas and regression rates.
    • Assumptions/dependencies: Interoperable seam definitions; security vetting; license and IP frameworks.
  • Robust, general-purpose regime detection (academia, tooling)
    • What: Improve and validate regime classifiers across domains with human-verified labels; study ablations to quantify the benefit of regime-to-seam routing.
    • Potential products: Open datasets and detectors; benchmarking suites for failure taxonomies.
    • Assumptions/dependencies: Annotation budgets; agreements on taxonomy granularity; external validation.
  • Safety-by-construction for code-generating agents (security, software)
    • What: Require static/sandbox gating for all agent-authored code changes; integrate with supply chain security (SBOMs, signing).
    • Potential products: “Agent CI” pipelines; runtime monitors that enforce import whitelists and resource sandboxes.
    • Assumptions/dependencies: High-fidelity sandboxes; governance of capability escalation; continuous vulnerability scanning.
  • Self-healing enterprise assistants with human-in-the-loop oversight (enterprise IT)
    • What: Assistants that propose repairs, show per-candidate held-out evidence, and request approval; operators gradually automate once trust and triggers are validated.
    • Potential products: Control centers with explainable diffs and flip barcodes; approval routing integrated with ticketing systems.
    • Assumptions/dependencies: UX for non-ML reviewers; education on statistical thresholds and noise; cultural adoption.
  • Domain-specific operator families
    • Healthcare: Operators for medication changes vs. historical instructions, temporal reasoning over encounters, contradiction detection across notes.
    • Finance: Operators for policy updates, exception handling, recency-weighted compliance interpretations.
    • Education: Operators for prerequisite detection, misconception diagnosis, and fair grading interventions.
    • Assumptions/dependencies: Domain ontologies and detectors; rigorous validation (up to clinical or regulatory standards).
  • Robotics and cyber-physical systems (robotics, energy, manufacturing)
    • What: Event-sourced control agents with deterministic replay and held-out validation before deploying new policies or toolchains; propose-and-gate micro-updates.
    • Potential products: “Black box flight recorder” for robots; safe self-improvement loops for task policies.
    • Assumptions/dependencies: High-fidelity simulators for held-out gates; strict safety cases; latency constraints.
  • Fairness, accountability, and transparency (policy, academia)
    • What: Use immutable event logs and per-candidate marginal deltas to audit bias impacts of changes; incorporate fairness metrics into gates.
    • Potential products: Gate extensions that require non-regression on fairness slices; audit packages for external review.
    • Assumptions/dependencies: Labeled data for fairness audits; consensus on fairness metrics; privacy-preserving logging.
  • Personal knowledge tools with auditable self-improvement (daily life, productivity)
    • What: Email/notes assistants that learn corrections over time but only adopt changes that pass local held-out tests; users can “replay” why the assistant changed.
    • Potential products: Local event-sourced agents with user-visible timelines and one-click reverts.
    • Assumptions/dependencies: On-device or private cloud storage for logs; small held-out sets representative of user tasks; UX to avoid burdening users.

Notes on feasibility and dependencies across applications:

  • The event-sourced runtime is the central dependency; without it, deterministic replay and first-class audit trails are hard to achieve.
  • Held-out gating assumes access to representative, non-overlapping evaluation data; in production, shadow/canary traffic may substitute but requires careful statistical controls.
  • Model non-determinism and silent endpoint changes can impact reproducibility; caching and version pinning are necessary.
  • Routing value depends on the quality of the regime detector; validating detectors and running no-routing ablations are important before attributing gains to diagnosis.
View Paper Prompt  View All Prompts 

Glossary

  • action seam: The specific part of the agent pipeline that the loop is allowed to modify to address a diagnosed failure. "An action seam is the part of the pipeline the loop is allowed to edit in response (re-weight retrieval scores, reorder the assembled turns, or edit the reader's prompt)."
  • ActiveGraph: An event-sourced agent runtime whose state is a deterministic projection of an append-only event log, enabling exact replay and auditability. "The loop runs on the ActiveGraph runtime [Nakajima, 2026], an event-sourced system whose state is a deterministic projection of an append-only event log, with a cache that records model and tool responses."
  • append-only event log: A log structure where events are only appended (never mutated), serving as the single source of truth for replay and auditing. "an event-sourced system whose state is a deterministic projection of an append-only event log"
  • assemble-internal: A failure regime where the relevant evidence is present in context but the reader still answers incorrectly (a reconciliation failure). "We give this failure a short name for reuse, assemble-internal, meaning the evidence was assembled into context but used incorrectly."
  • assembly-crowding: A failure regime involving overcrowding during assembly of context, potentially causing important evidence to be lost or diluted. "* Failure regime: the diagnosed reason a question failed. budget-truncation (evidence dropped at the context budget), assembly-crowding, assemble-internal (evidence present, answer wrong, the reconciliation wall), retrieval-signal-gap (the right turns never scored high enough), scoring-error."
  • assembly-transform: A transform that reorders or filters selected turns during the assembly stage to address certain failure regimes. "An assembly-transform (reorder or filter selected turns)"
  • auditable substrate: A runtime foundation that records all operations as events, making improvement loops easy to replay, inspect, and audit. "ActiveGraph as an auditable substrate for controlled improvement loops: event sourcing, deterministic replay from the log, cached model and tool responses, and the loop's own history recorded as events are what make autonomous improvement easy to build, replay, inspect, constrain, and audit."
  • Bonferroni correction: A multiple-comparisons adjustment that tightens significance thresholds based on the number of tests. "under a Bonferroni correction for five tests (adjusted alpha 0.01) seed 5 (p = 0.006) remains significant and seed 7 (p = 0.039) does not"
  • byte-identical: Exactly identical at the byte level (e.g., serialized event logs), used to certify unchanged control-flow behavior after refactoring. "We extracted the Target interface and re-homed LongMemEval behind it under a hard constraint: byte-identical loop behavior before and after."
  • cached replay: Re-executing a run using cached model/tool responses to achieve exact reproducibility without new API calls. "cached replay buys exact reproducibility, not a noise estimate."
  • chaotic mock author: A testing mock that intentionally emits malformed and failing candidates to stress-test loop robustness. "We test it with a chaotic mock author that emits the full failure distribution"
  • CONFIRM split: The held-out validation subset used only to gate candidate promotions after in-sample checks. "Validate: run the candidate on the held-out CONFIRM split and promote only if CONFIRM does not regress."
  • confirm_delta: The measured held-out accuracy change attributable to a candidate, computed as a marginal difference against the current deployed state. "The gate computes confirm_delta by measuring CONFIRM accuracy with the candidate installed, then reverting only that candidate (a keyed removal, leaving any previously promoted transforms in place) and measuring again"
  • confirm_threshold: The minimum held-out improvement (or non-regression) required for promotion. "The confirm_delta >= confirm_threshold rule is the promotion gate; the reported runs used the default confirm_threshold = 0.0."
  • content-addressed cache: A cache keyed by content hash that stores model and tool responses to enable deterministic replays. "with a determinism contract and a content-addressed cache that records model and tool responses so replay performs no new model calls."
  • determinism contract: A system guarantee that, given the same log and cache, runs replay without variability. "with a determinism contract and a content-addressed cache that records model and tool responses so replay performs no new model calls."
  • deterministic projection: A state representation computed deterministically from an event log, ensuring reproducible agent state. "an event-sourced runtime whose graph state is a deterministic projection of an append-only event log"
  • deterministic replay: The ability to replay runs exactly from logs without new model calls, yielding identical outcomes. "Regimes shows the improvement loop can be made target-agnostic while preserving deterministic replay on an event-sourced substrate."
  • event-log determinism: The property that the serialized event log uniquely determines the loop’s behavior and outcomes. "This is the event-log determinism of the ActiveGraph substrate [Nakajima, 2026]."
  • event-sourced: An architecture where system state is derived from a sequence of recorded events, enabling auditing and replay. "an event-sourced runtime whose state is a deterministic projection of an append-only event log"
  • event-sourced substrate: A base runtime using event sourcing that makes controlled improvement loops auditable and tractable. "Regimes shows the improvement loop can be made target-agnostic while preserving deterministic replay on an event-sourced substrate."
  • failure regime: A categorized diagnosis of why a question failed, used to choose an appropriate action seam. "A failure regime is the diagnosed reason a question failed (for example, evidence dropped at the context budget, or assemble-internal)."
  • guarded deterministic operator: A future design pattern where learned behaviors are converted into deterministic, condition-triggered operators rather than prose prompts. "guarded deterministic operators that fire on detected structure rather than coarse prose rules."
  • held-out gate: A binding validation step that only promotes candidates that do not regress (or improve) on held-out data. "The held-out gate is binding."
  • held-out-gated promotion: The policy of retaining a repair only if it passes validation on examples not used to author it. "We call this a held-out-gated promotion, and it is what separates a real improvement from a candidate that merely overfits the cases the loop happened to see."
  • LongMemEval-S: A long-context memory benchmark variant used as the paper’s main case study. "The case study is LongMemEval-S [Wu et al., 2024], a long-context memory benchmark."
  • McNemar test: A paired statistical test for binary outcomes used to assess significance of flip counts. "The detailed statistics (per-split McNemar tests, pooled discordances, and the same-pool caveat) are in the results section rather than here."
  • OPTIMIZE split: The in-sample subset used for diagnosis, authoring, and preliminary gating of candidates. "It is computed from the failures on the 50-question OPTIMIZE split"
  • over-promotion: A failure mode where multiple within-noise promotions accumulate without true held-out gains. "the over-promotion failure in Section 5.7"
  • paired nonparametric bootstrap: A resampling method used to estimate confidence intervals for paired differences. "For seed 7, a paired nonparametric bootstrap over the 100 held-out questions (percentile method, 10,000 resamples) gives mean paired difference +0.08, 95% CI [+0.02, +0.15]."
  • plateau-aware stopping rule: A stopping criterion that halts promotions when improvements plateau within noise. "a stricter promotion threshold and a plateau-aware stopping rule."
  • reader-prompt-transform: A transform that edits the reader’s prompt fragments to improve evidence use and reconciliation. "assemble-internal routes to a reader-prompt-transform."
  • reconciliation wall: The challenge where evidence is present but the reader still answers incorrectly, requiring changes to evidence use. "assemble-internal (evidence present, answer wrong, the reconciliation wall)"
  • regime classifier: The detector that assigns failure-regime labels used for routing and analysis. "Section 6 audits the measurement itself, including the regime classifier and the determinism claim."
  • regime histogram: The distribution of diagnosed failure regimes used to select the dominant seam-reachable target. "Diagnose: run the agent on the OPTIMIZE split, classify each failure into a regime via fixed detectors (Section 6 reports the detection mechanism), build a regime histogram"
  • regime-to-seam mapping: The fixed routing from a diagnosed failure regime to the action seam that can address it. "The regime-to-seam mapping is the fixed routing from a diagnosed regime to the seam that can address it."
  • retrieval-signal-gap: A failure regime where the correct turns never scored high enough to be retrieved. "* Failure regime: the diagnosed reason a question failed. budget-truncation (evidence dropped at the context budget), assembly-crowding, assemble-internal (evidence present, answer wrong, the reconciliation wall), retrieval-signal-gap (the right turns never scored high enough), scoring-error."
  • sandbox execution: Running candidate transforms in a controlled environment to ensure they execute safely before evaluation. "Regimes diagnoses failed evaluations, proposes a repair at a specific point in the agent's pipeline, and promotes that repair only when it passes static checks, sandbox execution, in-sample evaluation, and validation on held-out examples."
  • score-transform: A transform that re-weights retrieved-turn scores to mitigate retrieval/selection failures. "A score-transform (re-weight retrieved-turn scores)"
  • stratified split: A dataset split preserving category proportions, used here to create OPTIMIZE and CONFIRM sets. "Each run uses a stratified split of the 500-question LongMemEval-S set into OPTIMIZE = 50, on which the loop diagnoses, drafts, and runs in-sample eval-diffs, and CONFIRM 100"
  • target-agnostic: A design property where the same improvement loop operates across different tasks via a common interface. "We call this target-agnostic: the diagnosis, gating, and rotation logic talk to any task through a common interface"
  • typed pipeline seam: A precisely defined edit surface in the pipeline (with a type) that constrains where and how patches apply. "candidate patches scope to typed pipeline seams"
  • typed projections: Structured, type-checked views derived from the event log to implement durable operators. "the operators these probes reveal belong as typed projections on the event log itself (Section 8.4)"
View Paper Prompt  View All Prompts 

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Generate Now

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 5 tweets with 73 likes about this paper.

Sign Up for Free