Artificial Quirks

Catching Hallucinated Paths: Quality Intercepts

Sat, 04 Jul 2026 00:00:00 GMT

Imagine an AI agent confidently handing you a finished architectural plan. It looks perfect, the logic is sound, and the syntax is flawless. But when you go to implement it, you realize the agent cited a file path that doesn't exist. The plan is hallucinated.

This is a pervasive issue in agentic planning. To combat it, our orchestration framework implements Pre-Finalization Quality Intercepts—a system that catches hallucinated paths before the agent is allowed to finalize its trajectory.

1. The Anatomy of a Hallucination

When an agent analyzes a complex repository, it builds a mental model of the directory structure. Because LLMs are predictive text engines, they will often guess where a file should be based on common conventions.

For example, an agent might propose edits to src/utils/logger.py, completely unaware that the project actually stores its logging module in pkg/telemetry/logging.py. If the agent finalizes its plan with the hallucinated path, the entire run is a failure, regardless of how elegant the proposed code is.

2. The Pre-Finalization Intercept

To solve this, we cannot rely on the agent checking its own work. We must introduce a host-side validation gate right before the agent calls its submit_plan or finalize tool.

The Hook: When the agent attempts to submit its final artifact, the orchestrator intercepts the payload.
Path Grounding Check: The host parses the artifact for any referenced file paths, code snippets, or module names. It then physically verifies these references against the actual filesystem and AST (Abstract Syntax Tree) of the repository.
The Bounce: If a path does not exist, the orchestrator rejects the submission. Instead of ending the run, it sends an error back to the agent: "Error: Proposed file src/utils/logger.py does not exist. Please use search tools to verify paths."

3. Forcing Self-Correction

By bouncing the submission, the intercept forces the agent into a Trajectory Repair Loop. The agent must spend a turn using tools like grep_search or list_dir to ground its mental model in reality.

This turns a silent, 0% quality failure into a slightly longer, but 100% grounded success. The intercept acts as an automated reviewer, ensuring that no hallucinated plans make it to the user.

What a Two-for-Two Agent Result Actually Proves

Wed, 01 Jul 2026 00:00:00 GMT

Small agent cohorts are common because each repeat can consume minutes, millions of tokens, and a full repository snapshot. The wrong response is to dismiss every two-run result. The equally wrong response is to turn 2/2 into a universal claim.

The useful move is to name the level of evidence precisely.

Three claims that look similar but are not

| Claim | What supports it | What it does not establish | | --- | --- | --- | | Cohort outcome | Two runs completed under the recorded configuration | That another configuration will do the same | | Mechanism effect | Runs exercised the intervention and differ from a relevant control | That success came from an unrelated change | | Default-policy readiness | Replication across tasks, repeats, and failure modes | That the policy is harmless in all production contexts |

The test-repair fallback cohort completed 2/2, verified 22/22 grounding claims, and scored 1.00 in both repeats. That establishes a strong cohort outcome: those two recorded runs finished and passed the harness checks.

It does not directly establish the intended repair mechanism. Neither repeat re-triggered the exact rejected-test-reference branch after the fallback was introduced. The cohort is non-regression evidence for the stricter loop, not a branch-level causal demonstration.

Compare it with the checkpoint study

The checkpoint experiment had a more suggestive mechanism contrast: baseline completed 0/2 while the checkpoint arm completed 2/2.

| Arm | Repeats | Completion | Mean tokens | Mean iterations | | --- | ---: | ---: | ---: | ---: | | Baseline | 2 | 0% | 667,729 | 42.5 | | Checkpoint 70 + 5 | 2 | 100% | 1,087,231 | 67.0 |

Even here, caution is required. One checkpoint repeat finalized before the checkpoint could matter. One baseline run failed before accepting a trajectory action. The clean comparison is not “the checkpoint costs 63% more”; it is “the experiment found a 2-versus-0 completion split with heterogeneous failure mechanisms.”

A practical interpretation template

For every small-cohort result, write four sentences before deciding what to do:

Observed: What exactly happened, with repeat count and configuration?
Mechanism: Which runs directly exercised the intervention?
Confounders: What alternative explanation or uneven failure occurred?
Decision: Keep as research-only, rerun, harden, or promote?

Applied to the fallback cohort:

Observed: both configured repeats completed and verified.
Mechanism: neither directly exercised the target invalid-test branch.
Confounder: finalization error types differed from the motivating failures.
Decision: keep the fallback, retain unit coverage, and add a deterministic branch-forcing benchmark before attributing the result to that mechanism.

That is not timid language. It is a decision that preserves a useful improvement without laundering uncertainty into a default.

Counterfactual: when is 2/2 enough?

Two runs can be enough for a local engineering decision when the intervention is low-risk, easy to roll back, and the result is corroborated by deterministic tests. For example, keeping a prompt clarification behind a strict validator is different from changing a global production execution policy.

Two runs are not enough when the decision changes safety boundaries, cost ceilings, default model routing, or the interpretation of a public benchmark. Those need more tasks, more repeats, and explicit sensitivity analysis.

The next experiment

The next fallback study should pre-specify the failure branch and force it: inject an invalid test reference, return zero related tests, then assert that the revised plan puts the same planned path in tests and expected_files within allowed scope. Run at least four repeats per arm against a control. Report all runs and the subset that actually reached the branch.

That experiment would not make the whole planner reliable. It would transform the current inference from “the system passed a later cohort” to “this recovery mechanism worked under its intended trigger.”

Cohort results at a glance

Takeaways

2/2 is a fact about a cohort, not a synonym for general reliability.
Direct branch coverage is stronger than post-hoc narrative alignment.
State confounders next to the headline, not in a footnote.
Use small cohorts to choose the next discriminating experiment.

For the repair-loop design behind this example, see Designing Bounded Repair Loops for Agent Plans.

The Security Cost of Autonomy: Traversal Risks

Tue, 23 Jun 2026 00:00:00 GMT

When you deploy a fleet of autonomous agents across 29 parallel experimental runs, you aren't just testing intelligence—you are stress-testing your infrastructure's security posture.

In a recent benchmarking study using our orchestration framework, we subjected 29 Recursive Language Model (RLM) trajectories to a rigorous security audit, specifically looking for path traversal attempts and container mount escapes. The results illuminate the hidden costs of agent autonomy.

1. The Threat Model

An agent with access to file-writing tools (like replace_file_content or write_to_file) poses an inherent risk of Path Traversal. If an agent decides to write to ../../../../etc/passwd or /root/.ssh/authorized_keys, the orchestrator must intercept it.

In our swarm, worker nodes use Docker volumes to mount the target repository into /workspace. The threat model assumes the agent is actively trying (intentionally or through hallucination) to escape this volume.

2. The Audit Findings

Across the 29 runs, the security telemetry logged the following behaviors:

Path Traversal Attempts (14 incidents): 14 distinct trajectories attempted to use ../ to navigate outside the /workspace root. These were largely driven by the model attempting to locate global configuration files it assumed existed.
Absolute Path Violations (8 incidents): 8 trajectories attempted to write directly to /tmp/ or /var/log/, ignoring instructions to use the workspace.
Mount Escape Attempts (0 incidents): Thanks to strict canonical path resolution in the host tools, 0 trajectories successfully escaped the bind mount.

How the Host Protects the System

def resolve_secure_path(workspace_root: str, requested_path: str) -> Path:
    base = Path(workspace_root).resolve()
    target = (base / requested_path).resolve()
    
    if not target.is_relative_to(base):
        raise SecurityException(f"Path traversal blocked: {requested_path}")
    return target

Every tool execution in our orchestration framework runs through a path resolver like the one above. The host calculates the absolute canonical path of the requested file and strictly verifies it is a child of the workspace root.

3. The Cost of Security

Intercepting these actions comes with a cost. When a traversal is blocked, the agent receives an error. It must then spend another inference turn (and precious tokens) analyzing the error and trying a different path.

This is the "Security Cost of Autonomy." We pay for infrastructure safety with token latency. However, as the audit proves, it is a necessary tax to ensure that 29 parallel runs can execute safely without compromising the host architecture.

Inside the Sandbox: Shell Execution Kills Reliability

Sun, 21 Jun 2026 00:00:00 GMT

When building autonomous agents, the easiest path to giving a model "power" is to hand it a raw shell. Need to install a package? Run pip install. Need to find a file? Run find / -name "*.py".

It feels powerful, but in production, unconstrained shell execution is a reliability nightmare. In our orchestration framework, we discovered that soft prompt instructions ("don't delete files outside the workspace") are fundamentally incapable of preventing an agent from accidentally bricking its environment.

1. The Illusion of Prompt Security

LLMs are probabilistic. They do not natively understand the difference between rm -rf ./tmp/ and rm -rf /tmp/. When an agent is confused, hallucinating, or stuck in a loop, it will try commands that seem plausible but are environmentally destructive.

In early studies, we observed agents:

Overwriting global Python installations because they couldn't figure out virtual environments.
Killing system processes while attempting to "free up memory."
Entering recursive grep loops over /usr/bin that exhausted API time limits.

Prompting the model to "be careful" is not security; it's a suggestion.

2. Hard Isolation is the Only Fix

To achieve reliability, the execution boundary must be enforced by the host, not the model. This is why our orchestration framework relies on strict Docker isolation.

Network Mode none: Agents cannot reach out to the internet to download unverified binaries or leak data. If an agent needs a tool, it must be explicitly provisioned in the container image.
Read-Only Root: The container's root filesystem is mounted as read-only. Agents can only write to a tightly scoped /workspace directory.
PIDs and IPC Isolation: Agents cannot see or interact with host processes. They operate in a sterile vacuum.

3. Designing for Determinism

By removing the agent's ability to alter the global state of the machine, we force determinism. If an agent fails in a strictly isolated sandbox, we know exactly why it failed: it couldn't solve the logic problem, not because it accidentally corrupted the apt cache.

When building agent systems, stop treating the shell as a feature. Treat it as a vulnerability that must be ruthlessly contained.

Strategies, Not Model Ifs

Wed, 17 Jun 2026 00:00:00 GMT

If you run more than one model through the same recursive agent loop, a single default policy will usually punish at least one of them. A multi-fence model that plans in five code blocks can burn a tool budget in a few turns; a one-cell-friendly model may look “disciplined” under the same knobs and finish cleanly. The instinctive fix — if "vendor" in model: inside the engine — does not age well.

Claim. Separate who runs (model profile) from how the loop runs (a named execution strategy). Encode strategies as data (YAML presets), bind them optionally from profiles, and let task metadata win on every key. Keep the runtime free of model-name branches.

This note is from live recursive-agent work in mid‑2026: multi-cell thrash on long reviews, disciplined short plans, and human-in-the-loop “extend budget” actions that did nothing because the wrong ledger row was raised. Numbers and presets below are starting points from that dogfood, not universal optima.

What this article assumes

We talk about a recursive language-model (RLM) loop: the model proposes fenced code cells, a runtime executes them in a REPL, returns observations, and repeats until the model emits a terminal signal (FINAL), or a budget trips (steps, tools, model calls).

Figure: one simplified turn. “Cell” means one executed fenced block, not a notebook metaphor only.

You do not need our particular codebase to use the idea. Any agent stack with multi-turn tool use and more than one model personality hits the same design fork.

Companion notes in this series:

When smaller cells make agents worse — prompting changes cell shape; horizon still decides completion.
RLM is not automatically token-efficient — history caps belong on the same strategy object as cell and tool limits.

The problem: one loop, two behaviors

| Behavior | Typical model style | Failure under one-size defaults | |----------|---------------------|----------------------------------| | One cell / turn, converges | Single-cell-friendly | Fine near modest max_tool_calls | | Many cells / turn, exploratory | Multi-fence | Burns cell/tool budget quickly; raising root steps alone does not help |

The useful product question is not “do we need different models?” It is: do we need different approaches — and can we change approaches without forking the engine?

Architecture: who vs how

| Axis | Config surface | Meaning | |------|----------------|---------| | Who | Profile registry (profiles.yaml) | Provider + model id (+ optional default strategy id) | | How | Strategy registry (rlm_config.yaml) | Iterations, tool/model caps, cells/turn, prompt style, history, addons |

Figure: profiles point at strategies; tasks can override either the whole preset or individual keys. The runtime never branches on the model string.

Resolution order (highest wins per key)

task.metadata[key]
  >  task.metadata.rlm_config_id  (named preset)
  >  profile.rlm_config_id        (convenience default)
  >  AGENT_RLM_CONFIG / "default"

Figure: rank only — a task key always beats a profile-bound preset for that key.

Why not model `if`s

New models appear constantly. Engine forks rot.
Same model, different jobs. A short probe may want multi-block batching; a long review may want hybrid late discipline (cell A/B).
Evals need pure strategy diffs without swapping weights.
Operators should add presets without shipping Python.

Named presets (illustrative shape)

| Preset | Intent | Typical binding | |--------|--------|-----------------| | default | Conservative shared baseline | env / fallback | | disciplined | One-cell-friendly, tighter output | single-cell-oriented profiles | | exploratory | High tool headroom, multi-cell OK, hybrid late phase, write-early nudge | multi-fence profiles |

Figure: max_cells/turn of 0 means no hard cap (null in config) for default.

# rlm_config.yaml (abridged)
configs:
  default:
    max_tool_calls: 200
    max_model_calls: 40
    max_code_blocks_per_turn: null
    prompt_style: multi_block
    history_keep_recent_turns: 6
    history_max_total_chars: 80000

  disciplined:
    max_tool_calls: 200
    max_code_blocks_per_turn: 1
    prompt_style: single_block
    history_max_total_chars: 60000

  exploratory:
    max_tool_calls: 1000
    max_code_blocks_per_turn: 12
    hybrid_switch_after_turns: 3
    late_max_code_blocks_per_turn: 4
    prompt_style: multi_block_budgeted
    system_prompt_addon: >-
      Prefer batched reads; write findings early under a reviews path;
      after orientation, fewer smaller cells and FINAL soon.

# profiles.yaml (bindings)
single-cell-model:
  provider: gateway
  model: vendor/single-cell-model
  rlm_config_id: disciplined

multi-fence-model:
  provider: gateway
  model: vendor/multi-fence-model
  rlm_config_id: exploratory

Task authors still win:

agent:
  profile: multi-fence-model
metadata:
  rlm_config_id: disciplined   # force a different approach
  max_tool_calls: 500          # one-off key override

Knobs that earned a place

| Knob | Why it showed up in practice | |------|------------------------------| | max_tool_calls / max_model_calls | Real stop reasons; must seed a ledger so “extend budget” raises the limit that actually fired | | max_code_blocks_per_turn | Soft prompt styles leak on turn 0; the runtime can execute the first N and note deferred cells | | prompt_style | single_block / multi_block / multi_block_budgeted as data, not forked system prompts | | system_prompt_addon | Write-early and “budget is finite” steers without new code paths | | Hybrid late phase | Explore with a higher cell cap, then tighten (long multi-fence reviews) | | History working set | Stops input escalators (token note) |

Ledger honesty (operations)

A recurring failure mode: the runtime stops on max_tool_calls, a human “extends budget” by raising root steps or an unset ledger row, and warm-continue changes nothing useful.

Strategy work is operationally real only when:

Limits from the resolved strategy are seeded on the budget ledger (not left None).
Actual tool/model counts are settled each invocation.
Warm-continue grants remaining against the raised ceiling.
Gates surface exhaustion_reason so operators know which knob tripped.

Without that, “exploratory with 1000 tool calls” is a paper policy.

Worked scenarios

A — short multi-fence probe. Default exploratory may be wrong: multi-block batching can still finish under a short step budget (see the A/B note). If you force disciplined for measurement, treat completion risk as part of the experiment, not a surprise.

B — long multi-fence review. Profile default exploratory gives tool headroom, hybrid late nudge, and history caps. If you see exhaustion_reason=max_tool_calls, extend the tool budget — not steps alone.

C — single-cell-friendly implement. Profile disciplined keeps one-cell cadence; the task can still raise max_iterations without rewriting engine code.

Counterfactuals

If one global default were enough, multi-fence multi-cell burn and single-cell success would both be well-served by something like max_tool_calls≈100 and multi-block prompts. Live runs showed they are not.
Auto-tune from telemetry is a different product. It still needs a strategy representation like this YAML; it does not remove the who/how split.
Per-provider adapter forks multiply code paths and fight “same stack, many models.”
Falsifier for this architecture: a required behavior that cannot be expressed as strategy keys without reading model in the engine. None appeared in this design pass for cell caps, prompts, history, or budgets.

Limitations

Preset numbers (1000 tools, 12 cells, hybrid after 3) are starting points, not optimized frontiers.
Profile → strategy binding is a convenience; a mis-bound profile silently changes cost envelopes — snapshot defaults with each run.
Hard cell caps can surprise models that planned later fences; deferred-cell messaging must stay explicit.
This article does not claim hybrid + compaction fixed deliverable writes; token and cell behavior improved while write thrash could remain (token note).

Takeaways

Split who (profile) from how (strategy preset).
Encode approaches in data; resolve with a clear override stack; never branch the engine on model id strings.
Put every enforced limit on the ledger, or human “extend” actions will lie.
Keep history and cell policy on the same strategy object — they interact with tool budgets.
Use task metadata when the job’s horizon disagrees with the model’s default personality (smaller cells).

When Smaller Cells Make Agents Worse

Fri, 05 Jun 2026 00:00:00 GMT

Making an agent emit smaller, fewer code cells per turn sounds like pure upside: tighter discipline, less thrash, easier observations. Sometimes it is. Sometimes it is how you fail a short task while your dashboards look healthier.

Claim. In a controlled multi-fence-model A/B on a recursive agent stack, prompting for smaller cells improved cell shape and hurt task completion under a short root-step budget. Cell aesthetics are a diagnostic, not a success metric. Match cell policy to horizon.

This is a research note from mid‑2026 dogfooding (n = 1 clean comparable pair). Treat effect sizes as directional, not population estimates. It is not a claim about all models or all task lengths.

Background: cells in a recursive loop

The runtime drives a simple cycle: the model emits fenced Python cells, the environment executes them, observations return, and the loop continues until FINAL, budget exhaustion, or a human pause.

Figure: each “model call → cells → observation” cycle typically costs one root step. Batching work into one multi-cell turn can be the efficient encoding of a short plan.

Models differ wildly in how many fences they emit per call:

Single-cell-friendly models often converge with one-cell-ish turns.
Multi-fence models under default multi-block prompting often dump many fences in one response.

A natural reaction is: prompt the model to prefer smaller cells. We tested that with prompting only — no hard max_code_blocks_per_turn — on a short plan-mode container security probe (10 root steps, 50 tool calls).

Series companions:

RLM is not automatically token-efficient — when the cost problem is input growth, not cell count.
Strategies, not model ifs — why cell policy should be a selectable strategy, not a global moral.

Architecture of the failure mode

Under a fixed step ceiling, multi-block batching and single-cell discipline use the budget differently:

Figure: Arm A finishes inside the budget; Arm B spends steps on per-cell model rounds and hits the wall without FINAL.

Experimental setup

| Arm | Run id | prompt_style | Extra | |-----|--------|----------------|--------| | A baseline | run-a-baseline | multi_block | none | | B small-cell | run-b-smallcell | single_block | system addon: prefer ≤1 short cell/turn |

Same task family, same multi-fence model family; the difference is prompting.

Footnote (provisional): the first B attempt failed on a container-daemon race while another run shared the host runtime; metrics below are from a clean re-run.

Results

| Metric | A baseline | B small-cell | Δ (B−A) | |--------|------------:|-------------:|--------:| | Outcome | completed / FINAL | blocked (10 steps, no FINAL) | — | | Iterations | 1 | 10 | +9 | | Total cells | 5 | 15 | +10 | | Cells/turn mean | 5.0 | 1.5 | −3.5 | | Cells/turn max | 5 | 6 | +1 | | Cells/turn series | [5] | [6,1,1,1,1,1,1,1,1,1] | — | | Code chars mean | 299 | 92 | −207 | | Code chars median | 318 | 64 | — |

Figure: mixed-unit grouped bars — compare bars within each metric, not across metrics.

Figure: A reached FINAL; B did not under the same step ceiling.

What the cell series shows

After turn 0, arm B stayed at one cell per turn for nine turns. Mean cell text was roughly 3× shorter. Prompting did change behavior.

Figure: sticky multi-fence open (6), then disciplined single-cell turns — and still no FINAL by step 10.

Core argument

1. Cell discipline is not the objective function

Arm B optimized proxies operators like (cells/turn, code length). Arm A optimized what the eval scored: finish the short probe.

On a 10-step budget, a multi-block turn with five related micro-reads can be the efficient encoding of “one planning step.” Forcing one micro-step per model call multiplies model rounds — each with latency and fixed overhead — until the step ledger hits the wall.

2. The first turn is sticky

Even with single_block + “prefer one short cell,” B still opened with six fences once. Soft guidance is not a hard guarantee on an opening plan dump. If the risk is “turn 0 burns the tool budget,” prompting alone is insufficient — you need engine caps or deferred-cell policy (strategies).

3. When smaller cells are the right medicine

The same period’s longer multi-fence review thrash showed the opposite failure mode: many cells, re-scans, tool-budget blowups, no deliverable. There, smaller cells (or hybrid late-phase caps) target long-horizon thrash, not a 10-step probe.

Labeled inference: short probes often reward batching; long exploratory reviews may reward turn discipline + write-early pressure. Collapsing both into “always small cells” is a design error.

Worked example: reading the dashboard

| Dashboard signal | B looks… | Actual task outcome | |------------------|----------|---------------------| | Cells/turn | excellent | blocked | | Code chars | excellent | blocked | | Iterations used | “working hard” | exhausted | | FINAL / artifact | — | missing |

Without an outcome column (FINAL, files changed, verify score), B wins a beauty contest and loses the job.

Counterfactuals

If “smaller cells always help” were true, B should match or beat A on completion under the same budgets. It did not here — falsifying the universal form of the claim for this setup.
Alternative explanation: not cell size, but slower exploration under a hard step cap. More steps might let B finish — that is a different experiment, not a free rescue of the universal claim.
Hard cap counterfactual: set max_code_blocks_per_turn: 1 in the runtime instead of prompting. Expect less first-turn leakage; completion still depends on step budget. Not run in this A/B (prompt-only by design).
Long-horizon counterfactual: re-run with 40+ steps and an artifact success metric. Prediction: B or hybrid may dominate if A thrash-burns tools early. Provisional until re-run.

Limitations

n = 1 clean pair (plus one failed B attempt). Directional only.
Prompt-only intervention; engine cell caps and hybrid schedules are out of scope for these numbers.
Task is a short plan-mode probe, not a full review deliverable.
One multi-fence profile; do not export to “all multi-fence models” without replication.
Token thrash metrics live in the companion token article; do not mix those totals into this A/B.

Takeaways

Measure completion, not only cell aesthetics.
Match cell policy to horizon. Short step budgets can make multi-block batching more efficient.
Prompting moves means; it does not seal turn 0. For guarantees, use strategy knobs (max_code_blocks_per_turn, hybrid late phase) in strategies.
Next experiment: same A/B with artifact success + longer step budget; report cells/turn and FINAL and tokens in/out.

RLM Is Not Automatically Token-Efficient

Mon, 01 Jun 2026 00:00:00 GMT

Recursive agent loops are often sold as a way to work longer without stuffing the whole world into one prompt. That can be true for task structure. It is false by default for token cost.

If every model call re-sends a growing dialog of tool traces and observations, input tokens climb nearly monotonically. Efficiency is a history policy, not a free property of “being recursive.”

Evidence (directional, mid‑2026 dogfood, multi-fence model, security-review style runs): with history compaction, per-call input plateaued around 14–16k instead of climbing toward ~50–67k, and total tokens for a 25-step stop fell from ~1.04M to ~367k (about 2.8×). The cheaper run still did not produce the review file.

So this note is about what you measure and what you ship as knobs — not a claim that compaction finishes the job.

Quick vocabulary

| Term | Meaning here | |------|----------------| | RLM loop | Model proposes code → runtime executes cells → observations return → repeat | | Cell | One fenced code block executed in the REPL | | Per-call input | Tokens in the next model request (usually dominated by history) | | Working set | The subset of history you deliberately keep full-fidelity |

Figure: history sits on the path into every model call; without a policy it grows each turn.

Related reading:

When smaller cells make agents worse — cell policy ≠ completion.
Strategies, not model ifs — history caps live on named presets next to cell/tool budgets.

Three confusions worth separating

Operators watching live runs often ask: why are tokens climbing? Isn’t recursion supposed to be efficient? Should we chart input and output separately?

Those questions mix:

Recursion depth (nested sub-calls) vs dialog length at one depth.
Total tokens vs per-call input (the quantity that makes each step more expensive).
Efficiency of reasoning vs efficiency of memory encoding.

This article focuses on (2) and (3).

What unbounded history looks like

Without a working-set policy, each turn appends assistant prose, tool dumps, errors, logs, and scaffolding. The next call’s input includes most of that. Output may stay modest while input becomes the bill.

Figure: compaction does not delete the task; it caps what re-enters the next prompt.

Observation — thrash run: late calls approached ~50–67k input tokens; cumulative total near a 25-step stop was on the order of ~1.04M (~999k in / ~43k out).

Observation — compaction re-run: after an early climb, per-call input held ~14–16k (series ending near 12867, 16272, 13357, 16672, 13710, 13882, 14010); cumulative ~367k (~340k in / ~28k out) at the same step ceiling.

Figure: thrash late points are schematic midpoints from monitor notes (not a full exported series); compacted series follows the live plateau. Use for shape, not millimetric accuracy.

Figure: same stop condition, very different bill — driven by input.

Core argument

1. Recursive efficiency is a policy surface

A loop gives you places to intervene before each model call:

| Knob (strategy config) | Role | |------------------------|------| | history_keep_recent_turns | Full-fidelity recent window | | history_max_chars_per_old_message | Truncate older turns | | history_max_total_chars | Hard working-set ceiling | | history_protect_prefix_messages | Keep system/task head intact | | max_observation_chars | Bound a single tool result |

These belong on the same strategy object as cell and tool budgets (strategies).

Inference: if you ship recursive agents with unbounded dialog concatenation, you have built a linear input escalator, not an efficient long-horizon system.

2. Report input and output separately

Totals hide the failure mode:

| View | What you miss | |------|----------------| | Total only | Whether cost is “thinking” or “re-reading” | | Output only | Looks fine while input explodes | | Input per call | Shows plateau vs climb — the health metric |

Live monitors should treat last-call input and history size under budget as first-class series.

3. Token wins do not imply task wins

The compacted run was ~2.8× cheaper — yet stopped at 25/25 steps with no FINAL and no deliverable file. Notes showed the model stuck on write mechanics (parse errors, chunked writes, shell heredocs) while input stayed flat.

Compaction fixed the right bottleneck for the token question and the wrong bottleneck for “please finish the review.” Both can be true at once.

Worked example: reading a monitor line

Healthy compacted turn (illustrative):

turn 14  in≈16.3k  out≈1.5k  hist_chars≈51k/64k  tools 36/1000  file? no

Checklist:

in flat → memory policy holding.
out modest → not dumping the whole report into chat.
file? no after many “about to write” turns → success is still red; do not extend the step budget assuming tokens are the issue.

Thrash contrast:

turn 14  in≈55k+  out≈2k  hist growing  tools climbing  file? no

Here, prioritize history policy and re-scan behavior, not only more steps.

Counterfactuals

If RLM were token-efficient by construction, per-call input would stay roughly constant as turns increase under a fixed task. The thrash series falsifies that for an uncompacted dialog loop.
Alternative to truncation: externalize state into the workspace (files, variables) and keep dialog thin by design. Compaction is a runtime mitigation when the model keeps stuffing observations into chat history.
Aggressive summarization of old turns might save more tokens but can erase error strings needed to stop write thrash — a different tradeoff, not measured here.
What would reverse the ~2.8× win? Disable history caps with the same model and task length; expect totals back toward thrash order-of-magnitude. Provisional without a controlled re-disable A/B on identical seeds.

Limitations

Thrash late-call series in the figure is reconstructed from monitor narrative, not a full CSV export.
Both runs hit a step ceiling without deliverable; token comparison is for same stop, not same success.
Compaction parameters were those of the strategy in flight that day — not a full grid search.
Nested recursion depth is not measured separately from root dialog length.
Write-path failures deserve their own note; they are only a boundary condition here.

Takeaways

Assume dialog RLM will grow input until you stop it. Ship working-set knobs on day one.
Dashboard in and out separately; watch per-call input plateau.
Token health ≠ task health. Pair token series with artifact checks (file exists, FINAL, verify score).
Bind history caps with cell/tool budgets on one strategy object — see strategies.
Next measurement: export full per-call in/out series so figures need no schematic fill.

Grounding Is Necessary, Not Sufficient

Thu, 21 May 2026 00:00:00 GMT

Grounding is often described as the cure for hallucinated agent plans: require the planner to cite real repository files and reject the plan when it cannot. That is necessary. It is not enough.

The key distinction is between reference validity and claim validity. A file can exist while being the wrong test, a neighbouring implementation, or documentation that describes a different execution surface. A planner that cites it has grounded a string, not necessarily an assertion.

What strict grounding changed

The strict plan-reference cohort used the same indexed planner and a checkpoint-70-plus-five budget policy, but required each task to provide scope, evidence, and tests. It terminated at 0% completion after 77 mean iterations, approximately 1.51 million mean tokens, and 15 plan-validation failures. The error mix was evenly split across missing evidence, scope, and tests.

That is not a failure of the principle. It shows the validator was able to prevent under-specified plans from being accepted. An earlier evidence-reference repair cohort reached 50% completion, 50% verification, and 11 verified references out of 12 claimed. It demonstrates that the planner can sometimes use repair feedback to obtain real evidence.

| Cohort | Repeats | Completion | Grounding | Mean tokens | Validation failures | | --- | ---: | ---: | ---: | ---: | ---: | | Strict reference grounding | 1 | 0% | n/a | 1.51m | 15 | | Evidence-reference repair | 2 | 50% | 91.7% | 1.23m | 3 | | Checkpoint candidate | 2 | 100% | 100% | 1.09m | n/a |

The table comes from data/study-metrics.csv. The study manifests, scoreboards, reports, and hashes are recorded in data/evidence-manifest.yaml.

The worked failure: valid files, invalid plan

Manual review of accepted checkpoint plans exposed why existence checks are only the first layer.

The plans cited test paths under the wrong package root; the relevant tests were under tests/unit/....
They attributed network isolation and environment-key scrubbing to one Docker backend when the evidence belonged to different repository surfaces.
They presented intentional paused-state behaviour and normal success routing as failure modes.

Every example sounds plausible in a natural-language summary. None is safe to implement from. The important failure is not “the agent made up a filename.” It is “the agent assembled a claim from nearby facts without establishing the component-level relationship.”

A hierarchy of evidence checks

| Check | Rejects | Still permits | | --- | --- | --- | | Path existence | Invented filenames | Wrong existing file | | Scope membership | Files outside the task | A too-broad but in-scope citation | | Source-type match | Documentation used as implementation evidence | Misread implementation branch | | Related-test validation | Unrelated or nonexistent tests | A real test that does not exercise the claim | | Claim-to-branch review | Contradictions with inspected code | Future behaviour changes |

This hierarchy suggests an implementation order: add cheap, deterministic checks early, then reserve semantic review for claims with high downstream cost. Do not attempt to solve semantic correctness by making the schema increasingly elaborate.

Counterfactual: when path grounding is enough

Path grounding is sufficient for some narrow tasks. If a plan's only duty is to name existing files for a static inventory or migration checklist, source type and branch semantics may not matter. The moment a plan proposes a behavioural change, explains a failure mode, or chooses a test, existence becomes a weak proxy.

The falsifier for this article's claim is straightforward: show that adding existence checks alone reliably rejects the wrong-test and wrong-component examples in a held-out cohort. The current evidence does not show that; the manual review shows the opposite.

What to add next

Three gates are high-value:

Compare each cited test path with the repository's actual test roots and the task's declared component.
Require implementation claims to cite implementation branches, not only security documentation or manifests.
Add a contradiction-oriented review prompt: name the claimed wrong-state branch and the claimed recovery branch, then verify both against code.

These should complement, not replace, strict path checks. Grounding prevents a plan from floating free of the repository. Semantic review prevents it from becoming confidently wrong inside the repository.

Cohort results at a glance

Takeaways

A real path is evidence of a file, not evidence of a claim.
Grounding metrics must state their level: existence, scope, source type, or semantic support.
Manual semantic review is expensive; use it where a plan becomes an execution contract.

Read A Plan Can Validate and Still Be Unsafe to Implement for the broader readiness model.

Zero Net Access: Hardening LLM Agent Sandboxes

Sun, 17 May 2026 00:00:00 GMT

Imagine inviting a highly capable assistant into your office to organize your files, only to find they've accidentally emailed your private documents to the internet. This is the risk we face when giving autonomous AI agents—like those writing code or managing systems—free reign on a computer. Security cannot rely merely on politely asking the AI to "behave" through prompt instructions. Without strict, physical-like boundaries, an unconstrained agent can accidentally leak secrets, alter critical configurations, or make unauthorized connections to the outside world.

In this article, we break down how we solved this problem for our orchestration framework by building a Zero Net Access sandbox—a digital vault that completely cuts off the AI from the internet while still allowing it to do its job securely.

Threat Model & Sandbox Requirements

Autonomous coding agents present three distinct attack and failure vectors:

Outbound Data Exfiltration: Model code attempting to send repository contents or environment variables to external endpoints via curl or urllib.
Host Directory Traversal: Ad-hoc file modifications escaping the task directory (../) into system files.
Audit Tampering: Modifying local execution logs to hide unapproved tool operations.

To mitigate all three vectors, our sandbox enforces three non-negotiable architectural invariants:

network_mode=none: Complete hardware network isolation for the execution container.
IPC via Unix Domain Sockets (UDS): Inter-process communication between host orchestrator and container REPL using a local domain socket mount (/proxy.sock).
ECDSA Signed Audit Log: Every container execution event is hashed and signed on the host control plane.

Architecture & Control Flow

The host control plane (our orchestration framework) initializes an ephemeral Docker container for each agent trajectory. Network adapters (eth0) are completely disabled at container creation time.

UDS Inter-Process Communication

Because the container has no network interfaces, RPC communication between the host orchestrator and the Python REPL running inside the sandbox occurs via a mounted Unix Domain Socket:

# orbit_harness/rlm/general/environments/docker_repl.py
def _create_container(self) -> None:
    self.container = self.client.containers.run(
        image=self.image,
        network_mode="none",  # Mandatory Zero Net Access
        volumes={
            str(self.uds_host_path): {"bind": "/workspace/proxy.sock", "mode": "rw"},
            str(self.project_root): {"bind": "/repo", "mode": "rw"},
        },
        detach=True,
    )

Empirical Security Audit Results

We evaluated 29 benchmark study runs across multiple LLM provider models (Gemini 3.6 High/Medium/Low and DeepSeek v4 Flash) under the enforced Zero Net Access posture.

| Provider Group | Total Runs | Network Posture | Blocked Network Hits | Signed Audit Ratio | Sandbox Integrity | | :--- | :---: | :---: | :---: | :---: | :---: | | cliproxyapi-gemini-3.6-flash-high | 3 | disabled | 0 | 100% | PASS | | cliproxyapi-gemini-3.6-flash-medium | 3 | disabled | 0 | 100% | PASS | | cliproxyapi-gemini-3.6-flash-low | 3 | disabled | 0 | 100% | PASS | | deepseek-v4-flash | 3 | disabled | 0 | 100% | PASS |

All 12 provider arm runs completed under complete network isolation. Cryptographic verification of the signed audit logs confirmed zero unverified operations or host traversal attempts.

Key Takeaways

Enforce Kernel-Level Boundaries: Prompt engineering is not security. Use network_mode=none for all execution sandboxes.
UDS Sockets for RPC: Unix Domain Sockets provide high-performance, secure local IPC without opening loopback network ports (127.0.0.1).
Cryptographic Auditing: Sign every execution event on the host plane to guarantee audit trail tamper resistance.

A Plan Can Validate and Still Be Unsafe to Implement

Sat, 16 May 2026 00:00:00 GMT

An agent plan is not ready to execute merely because it has the right JSON shape, cites files that exist, and survives a bounded repair loop. Those checks are useful, but they answer a narrower question: can this plan be stored and mechanically inspected? They do not answer whether the plan describes the system correctly.

This distinction emerged while evaluating an indexed planner that investigates a repository and emits an implementation plan. The headline result was attractive: an action-70 synthesis checkpoint completed both candidate runs while the two baseline runs completed neither. Manual review, however, found that the accepted candidate plans still cited nonexistent test paths, conflated controls implemented in different execution surfaces, and described failure modes contradicted by code.

The practical rule is simple: treat structural validity, reference grounding, and semantic readiness as separate gates.

The intervention: force synthesis before the investigation becomes a loop

The planner normally chooses when to stop reading and submit a plan. The experiment added an opt-in checkpoint: after 70 actions, allow five more evidence actions and then require finalize_plan. The study used two repeats per arm on the same task and model configuration.

| Arm | Repeats | Completion | Verification | Mean tokens | Mean iterations | | --- | ---: | ---: | ---: | ---: | ---: | | Baseline | 2 | 0% | 0% | 667,729 | 42.5 | | Checkpoint 70 + 5 | 2 | 100% | 100% | 1,087,231 | 67.0 |

The data is in data/study-metrics.csv; its source hashes and the full study locations are recorded in data/evidence-manifest.yaml.

That result is evidence that the checkpoint can improve termination in this narrow cohort. It is not evidence that the resulting plans are semantically sound. One candidate finalized before the checkpoint could be causal; one baseline failed before accepting a trajectory action. The group-average token comparison is also confounded by that short baseline failure.

What the normal gates caught—and missed

The planner already had useful mechanical checks: non-empty task scope, evidence, tests, expected outputs, and path existence. A separate strict grounding cohort shows why they matter. Its one repeat completed 0%, recorded 15 plan-validation failures, and spent roughly 1.51 million tokens before terminating. The failure categories were missing evidence, missing scope, and missing tests.

But these checks have an obvious boundary. A test path can exist in the wrong directory; a documentation file can describe a control without that control being implemented by the component under review; a plausible prose summary can invert a branch's real behavior. None of those is a malformed field.

The manual review of accepted checkpoint plans found all three patterns:

Wrong test locations. The plans named tests under the wrong package root; the relevant tests live under tests/unit/....
Evidence-source conflation. They attributed network isolation and environment scrubbing to a Docker backend even though the evidence belonged to other repository surfaces.
Contradicted terminal-state claims. They described exception and blocked paths as failures even where the code intentionally persists a resumable pause or routes normal success.

These are not cosmetic errors. They make an implementation plan unsafe as a contract for someone else to execute.

A better readiness model

Use three gates, each with its own evidence and failure mode.

| Gate | Question | Good evidence | What it cannot prove | | --- | --- | --- | --- | | Structural validity | Is the plan complete enough to parse and route? | Schema checks; required fields; bounded repair | That its claims are true | | Reference grounding | Do cited files and tests exist within declared scope? | Repository reads; path checks; expected-file declarations | That the cited file supports the claim | | Semantic readiness | Does the plan accurately describe the relevant implementation, states, and tests? | Claim-to-code review; contradiction checks; targeted human review | That a future code change will work |

The gates should be cumulative. Passing the first two should unlock semantic review, not replace it.

The useful counterexample: 2/2 success without direct mechanism proof

A later two-repeat fallback cohort completed 2/2, verified 22 of 22 grounding claims, and had one successful repair. That is a meaningful non-regression signal for the stricter finalization path. It did not re-trigger the precise nonexistent-test repair branch that motivated the fallback. Calling it a direct causal proof would be stronger than the data allows.

This is the same discipline the semantic gate demands from the planner: name what the evidence establishes and what it does not.

What to test next

The next experiment should force the troublesome branch deterministically: submit an invalid test reference, have targeted discovery return no matching test, and verify that the repaired plan declares one exact planned test path in both tests and expected_files. That converts a unit-tested instruction into a live mechanism test.

In parallel, add semantic checks that compare a claim with the cited implementation branch, verify test-root conventions, and reject evidence that only describes a neighboring component. The goal is not to make planning impossibly strict. It is to stop confusing a well-formed plan with a trustworthy one.

Cohort results at a glance

Takeaways

Completion is a termination metric, not a correctness metric.
Path existence is necessary grounding, but it is not semantic evidence.
Small, mixed cohorts can reveal mechanisms, but they rarely justify broad defaults.
A plan becomes implementation-ready only when its claims survive structural, grounding, and semantic scrutiny.

The companion piece, Benchmarking Agent Systems Beyond “Did It Finish?”, turns those gates into a reusable measurement framework.

Designing Bounded Repair Loops for Agent Plans

Sat, 09 May 2026 00:00:00 GMT

Rejecting an invalid agent plan without feedback turns validation into a dead end. Allowing unlimited retries turns it into a cost and loop-control problem. A bounded repair loop sits between those failures: expose the validator's reason, allow one targeted evidence action, then require a revised finalization.

The boundary matters. It makes both the model's behaviour and the system's cost auditable.

The minimal protocol

Attempt finalize_plan.
Validate required scope, evidence, tests, and plan-level checks.
If validation fails, preserve the errors in the observation.
Permit exactly one targeted evidence action.
Require the next action to be a revised finalization.
Terminalize if that revision remains invalid.

The protocol does not guarantee that the model repairs the plan. It guarantees that a failure is finite, attributable, and measurable.

What the cohorts say

| Cohort | Completion | Validation failures | Repairs | Successful repairs | Mean post-finalize calls | | --- | ---: | ---: | ---: | ---: | ---: | | Repair signals | 50% | 3 | 3 | 2 | 2.5 | | Evidence repair v2 | 0% | 2 | 1 | 1 | 1.0 | | Completeness guidance | 0% | 2 | 1 | 1 | 1.5 | | Reliability validation | 0% | 4 | 2 | 2 | 2.5 | | Test-repair fallback | 100% | 1 | 1 | 1 | 1.5 |

The result is deliberately uncomfortable: a repair action can be recorded as successful while the run still fails. In the reliability cohort, both allowed repair actions completed, yet both repeats ended with missing or nonexistent test references. The observation succeeded; the revised plan did not.

That is why a repair dashboard needs at least three separate measures: repair action success, repaired-finalization success, and terminal run success.

Worked example: empty test discovery

The hardest observed failure was a rejected test reference followed by related_tests returning no matching files. A vague instruction to “find the right test” leaves the model with two bad options: omit the test field or invent an existing path.

The valid strict-plan fallback is precise: choose one exact planned test path within the task's allowed scope, place the same path in both tests and expected_files, and resubmit. The final fallback cohort completed both repeats, with 22 of 22 grounding claims verified and one successful repair.

That is encouraging non-regression evidence, not decisive mechanism proof. Neither repeat re-triggered the exact nonexistent-test validation branch after the fallback was introduced. A unit test covers the directive; a deterministic live benchmark still needs to force the branch.

Failure taxonomy should drive the next action

| Error type | Useful recovery | Bad recovery | | --- | --- | --- | | Missing evidence | Read the named implementation branch | Add generic prose | | Missing tests | Discover related tests or declare planned output | Leave tests empty | | Nonexistent test | Replace with real test or declared planned test | Invent another path | | Missing acceptance checks | Re-read task acceptance | Search unrelated code | | Transport failure | Retry the same completion within a limit | Treat it as a semantic repair |

This table is a design guide, not a claim that the current model follows every path reliably. The evidence bundle in data/ records the cohorts that motivated it.

Counterfactual: why not allow more repair actions?

More actions can improve a genuinely under-explored plan. They also allow the model to spend unbounded tokens circling a validator error or to hide a weak plan behind repeated unrelated reads. The right counterfactual experiment is not “one action versus infinity.” Compare one, two, and three repair actions on a pre-specified failure taxonomy, while holding task, model, budget, and acceptance policy constant.

Until that exists, one bounded action is a useful safety default because it makes failure legible.

Cohort results at a glance

Takeaways

Treat a repair action as an event, not proof of recovery.
Tie repair metrics to the next finalization and terminal outcome.
Make error categories select a narrow evidence action.
Use deterministic branch-forcing benchmarks before attributing a later cohort's success to a repair prompt.

For the measurement framework around these loops, read Benchmarking Agent Systems Beyond “Did It Finish?”.

From REPL Loops to Swarms: Leasing Sandboxed Containers

Thu, 07 May 2026 00:00:00 GMT

Imagine hiring a team of researchers, but forcing them all to share a single laptop. One reads a file, closes it, then the next person takes their turn. It’s slow, inefficient, and bottlenecks the entire team. In the world of AI agents, relying on a single, sequential REPL (Read-Eval-Print Loop) container for complex repository analysis creates the exact same bottleneck.

In this article, we explore how our orchestration framework solves this problem by moving from sequential execution to a parallelized Swarm Architecture using the SwarmLeaseManager.

1. The Single-Container Bottleneck

Traditional LLM agent harnesses spin up a single Docker container for the agent's Python REPL. The agent reads a file, waits for the result, executes a grep search, waits for the result, and slowly piece-meals its understanding of the codebase.

While this works for simple scripts, analyzing a massive enterprise repository or executing a test suite while simultaneously checking logs requires concurrency. If an agent wants to grep_search across five different sub-packages, doing so sequentially burns precious time (and API window duration).

2. Enter the SwarmLeaseManager

To enable parallel execution without sacrificing sandbox security (like our Zero Net Access posture), we implemented the SwarmLeaseManager.

Instead of a single REPL, the host orchestrator manages a pool of isolated worker containers. When the root agent decides it needs to parallelize a task, it requests "leases" from the manager.

How Leasing Works

The SwarmLeaseManager dynamically allocates worker nodes with strict lifecycle rules:

# orbit_harness/orchestration/swarm.py
class SwarmLeaseManager:
    def acquire_lease(self) -> SwarmWorkerLease | None:
        self.reclaim_expired_leases()
        active_count = sum(1 for l in self.leases.values() if l.active)
        if active_count >= self.max_workers:
            return None # Swarm pool is full

        lease_id = f"lease_{uuid.uuid4().hex[:8]}"
        worker_id = f"worker_node_{uuid.uuid4().hex[:8]}"
        lease = SwarmWorkerLease(lease_id=lease_id, worker_node_id=worker_id)
        self.leases[lease_id] = lease
        return lease

Acquisition: The orchestrator requests a lease. If under the concurrency limit (max_workers), a new SwarmWorkerLease is generated and a sandboxed Docker container is spun up.
Heartbeats: To prevent zombie containers from hogging resources, workers must send regular heartbeats (heartbeat(lease_id)).
Reclamation: If a worker crashes or hangs (failing to send a heartbeat within ttl_seconds), the manager automatically reclaims the lease (reclaim_expired_leases()) and destroys the rogue container.

3. Parallel Dispatch in Action

With the lease manager active, our orchestration framework can use asyncio to dispatch tasks across the swarm concurrently.

async def dispatch_parallel_swarm_tasks(
    tasks: list[Callable[[], Coroutine[Any, Any, Any]]],
    max_concurrency: int = 4,
) -> list[Any]:
    semaphore = asyncio.Semaphore(max_concurrency)

    async def _run_one(task_fn: Callable[[], Coroutine[Any, Any, Any]]) -> Any:
        async with semaphore:
            return await task_fn()

    return await asyncio.gather(*[_run_one(t) for t in tasks], return_exceptions=True)

By wrapping execution in an asyncio.Semaphore, the orchestrator ensures we never exceed our leased worker count, smoothly distributing tasks like parallel test runs, concurrent static analysis, or multi-directory grep_search operations.

4. Key Takeaways

Break the REPL Loop: Sequential tool execution is a major latency bottleneck for complex agents.
Leased Isolation: Dynamically leasing containers ensures that concurrent tasks remain isolated from one another, preventing filesystem collisions during parallel testing.
Heartbeats are Mandatory: Always implement TTLs (Time-to-Live) and heartbeats when orchestrating Docker containers to prevent zombie processes from hanging the host machine.

Why Build an Agent Harness?

Wed, 06 May 2026 00:00:00 GMT

Coding agents can search a repository, propose a plan, edit files, and run tests. That does not yet make their work safe to delegate or their outcomes useful to learn from. A harness is the missing engineering layer: it constrains what an agent may do, records what it did, and applies the same verification standards to an agent-produced change that a careful reviewer would expect.

The harness was built around that premise. Its immediate role is a local-first control plane for work in a target repository; its larger purpose is to make agent-assisted development an inspectable research-and-development practice. The system isolates work in Git worktrees, applies execution budgets, removes secrets and live-trading settings from the environment, and separates inspection, planning, implementation, verification, review, and human-approved application.

The goal is not to make an agent look autonomous. It is to make the boundary between useful autonomy and engineering control explicit.

The problem is not just code generation

Without a harness, an agent run often collapses into a single question: did it finish? That answer hides the questions that matter when the output will affect a real repository:

Which repository state and task definition did it see?
Was it permitted to write, run commands, or reach the network?
Which tests and policy checks were actually run?
Did a plan cite the right files and tests, or merely plausible-looking ones?
How much time, model budget, and repair work did the result consume?
Can someone reproduce the cohort and explain a surprising failure later?

A terminal success cannot answer those questions. Nor can a long transcript on its own. A useful harness makes the answers first-class artifacts.

The operating model

The harness treats agent work as a bounded workflow rather than an unstructured chat loop:

Each layer has a different job. Isolation contains side effects. Budgets make costly or stalled work visible. Verification turns assertions into checks. Human approval retains authority over application. Durable artifacts let later experiments distinguish a promising mechanism from an accidental result.

Why research belongs in the same system

The harness becomes more valuable when it can evaluate its own operating choices. For example, a checkpointed indexed-planner cohort completed 2/2 runs while its baseline completed 0/2, but the checkpoint cohort used more mean tokens and later manual review found semantic defects in both accepted plans. That is a useful result only because the study preserved repeat-level outcomes, cost, finalization behavior, and the plans for inspection.

Likewise, a later test-repair fallback cohort completed and verified 2/2 runs, recorded 22/22 grounding claims, and logged one successful repair. It is strong non-regression evidence. It is not direct proof of every repair branch: the exact empty-test-discovery branch was not exercised. The distinction matters. A research harness should make it easy to say both what improved and what remains unproved.

| What a harness records | Why it changes the decision | | --- | --- | | Repository snapshot, task, policy, and run ID | A reviewer can identify the conditions of the result. | | Per-case outcomes and terminal states | A cohort rate does not conceal failed or malformed runs. | | Verification, grounding, and repair telemetry | Completion can be separated from correctness and mechanism evidence. | | Token, latency, and iteration data | An apparent gain can be weighed against operational cost. | | Reports, scoreboards, and provenance manifests | Findings can be regenerated and challenged after the run. |

The early adapter-axis sweep makes the observability argument concrete. It reported 50% completion across two runs but no token figure, not because the work was free, but because that telemetry had not yet been materialized. Later cohorts retained token and trajectory evidence. Preserving the gap is part of the point: a system should expose its own blind spots instead of presenting a cleaner historical story than the artifacts support.

What the harness is not

It is not a claim that every agent action can be automatically trusted. Deterministic checks, path grounding, and budgets reduce risk; they do not prove semantic correctness or product fitness. The checkpoint study is the counterexample: structurally accepted plans still cited nonexistent test paths and confused documentation with the implementation under review.

It is also not a substitute for engineers. The desired division of labor is deliberate: the system lets agents perform bounded exploration and produce evidence; engineers choose goals, define acceptance, inspect the important failure modes, and approve changes with real consequences.

The series

This opening article provides the frame. The rest of the series investigates the individual controls and the evidence needed to evaluate them:

Experiments Should Be First-Class Product Artifacts explains the artifact chain behind reproducible conclusions.
Benchmarking Agent Systems Beyond “Did It Finish?” defines a scorecard spanning completion, verification, grounding, repair, and cost.
A Plan Can Validate and Still Be Unsafe to Implement shows why structural checks need semantic review.
Grounding Is Necessary, Not Sufficient separates file existence from claim correctness.
Designing Bounded Repair Loops for Agent Plans turns a repair attempt into an observable control loop.
What a Two-for-Two Agent Result Actually Proves provides the language for interpreting small cohorts honestly.

The standard to hold it to

The harness earns its complexity only if it improves decisions. A useful falsifier is straightforward: if a team cannot reconstruct a result, identify the conditions under which it ran, and explain why it passed or failed, the system is collecting activity rather than producing engineering evidence.

That is the motivation for the harness and for the research program around it: not agents that merely act, but agent-assisted development that can be inspected, challenged, and improved.

Experiments Should Be First-Class Product Artifacts

Mon, 04 May 2026 00:00:00 GMT

An agent experiment is not complete when the model stops. It is complete when a later reviewer can answer: what task ran, against what repository state, with what configuration, what happened in each repeat, and why the conclusion follows.

That sounds like research hygiene. In an agent system it is also product design. A study runner that emits only a terminal score turns every failure investigation into archaeology. A runner that materializes manifests, scoreboards, reports, case results, and trajectories makes iteration cumulative.

The artifact chain

Use a small, explicit chain for every cohort:

Each link answers a different audit question. The task and snapshot answer “what was intended?” Trajectories answer “what did the model do?” Case results answer “what happened in each repeat?” The scoreboard answers “what changed across groups?” The article bundle makes the published argument regenerable.

Why a summary report is not enough

The indexed-planner studies expose this quickly. An adapter-axis sweep reported 50% completion across two runs. That is a useful headline and an insufficient diagnosis. The later finalization-reliability cohort reported 0% completion despite substantial work: 76.5 mean turns, four validation failures, two recorded repair actions, and about 1.28 million mean tokens. The fallback cohort then reported 100% completion, 22/22 verified grounding claims, and one successful repair.

| Cohort | Completion | Mean tokens | Mean turns | Validation failures | Repair actions | | --- | ---: | ---: | ---: | ---: | ---: | | Adapter-axis sweep | 50% | 0 | 81.0 | n/a | n/a | | Finalization reliability | 0% | 1.28m | 76.5 | 4 | 2 | | Test-repair fallback | 100% | 1.32m | 78.0 | 1 | 1 |

The zero-token adapter-axis row is not evidence that the system was free. It reflects an observability gap that later work corrected with persisted model-invocation telemetry. The comparison is valuable precisely because the artifacts preserve that limitation rather than silently rewriting history.

What must be materialized

At minimum, a study package should retain:

study.yaml for the declared axes and repeats;
a manifest with git coordinates, source task, arm IDs, and run IDs;
per-case outcomes, including failed and pending arms;
a scoreboard with completion, verification, cost, latency, grounding, and repair metrics;
a human-readable report generated from those raw artifacts; and
trajectories or event logs for mechanism analysis.

Do not put all of this into a single prose report. The report is an interpretation layer; the case data and manifest are the audit layer.

The article handoff is part of the system

The authoring-research-harvest workflow turns selected study artifacts into three article-owned files:

data/study-metrics.csv
data/study-cases.csv
data/evidence-manifest.yaml

The manifest records the source artifacts and their SHA-256 hashes. This avoids two common failures: numbers copied from a transient console, and a chart whose underlying data cannot be found once the experiment workspace changes.

Counterfactual: when can a notebook be enough?

For a one-off exploratory question, a notebook plus an archived dataset may be sufficient. The threshold changes when a result will alter agent policy, spend budget repeatedly, or become a public claim. At that point, the experiment needs stable identities, repeat-level results, and provenance.

The falsifier is operational: if a new engineer can reconstruct the exact cohort and explain a surprising case from the report alone, the extra artifacts may be unnecessary. In practice, model failures, transport errors, and partial repairs make that rare.

Cohort results at a glance

Takeaways

Treat manifests and case records as product outputs, not debugging leftovers.
Preserve failures; they often explain an apparent improvement.
Generate prose reports from raw artifacts, not the other way around.
Make publication consume the same durable evidence the operators use.

The companion Benchmarking Agent Systems Beyond “Did It Finish?” explains the scorecard these artifacts should support.

Benchmarking Agent Systems Beyond Did It Finish?

Thu, 23 Apr 2026 00:00:00 GMT

“Did the agent finish?” is a useful operator question and an inadequate research metric. It merges at least six different behaviours: whether the run terminated, whether output passed verification, whether the plan was grounded, how much repair it required, what it cost, and whether the same result can be reproduced.

The indexed-planner experiments behind this note use a compact scorecard that keeps those questions separate. The result is not a promise of statistical certainty—most cohorts have one or two repeats—but a better way to prevent a green completion cell from hiding an ungrounded or expensive outcome.

The scorecard

| Dimension | Primary fields | Question answered | | --- | --- | --- | | Termination | completion rate, iteration count | Did the planner reach a terminal result? | | Acceptance | verification pass rate, mean score | Did the harness accept the plan? | | Grounding | claimed/verified references, grounding ratio | Are required references supported at the chosen level? | | Repair | validation failures, repairs, successful repairs | Did feedback produce a valid revision efficiently? | | Cost | input/output/total tokens, elapsed time | What did the outcome consume? | | Service health | mean/max latency, transport failures | Was the result affected by model or provider behaviour? |

The article package owns the normalized source data in data/study-metrics.csv and data/study-cases.csv. The evidence manifest records the original scoreboards, reports, and manifests by hash.

A worked sequence: the finalization cohorts

Seven two-repeat cohorts evaluated variations of strict plan finalization. They should not be read as one clean A/B: interventions accumulated, some runs hit provider issues, and individual failure modes changed. They are useful as a repair ledger.

| Cohort | Completion | Grounding | Mean tokens | Validation failures | Successful repairs | | --- | ---: | ---: | ---: | ---: | ---: | | Repair signals | 50% | 100% | 1.14m | 3 | 2 / 3 | | Evidence-reference repair | 50% | 91.7% | 1.23m | 3 | 2 / 2 | | Evidence-reference repair v2 | 0% | n/a | 653k | 2 | 1 / 1 | | Finalization clean | 50% | 92.9% | 667k | 1 | 1 / 1 | | Completeness guidance | 0% | n/a | 646k | 2 | 1 / 2 | | Reliability validation | 0% | 0% | 1.28m | 4 | 2 / 2 | | Test-repair fallback | 100% | 100% | 1.32m | 1 | 1 / 1 |

Two observations matter more than the final row's 100% headline.

First, a successful repair action is not the same as a successful run. The reliability cohort recorded two successful repair actions per the study metric, yet both repeats ultimately failed because the revised plans retained missing or nonexistent tests. Counting repair attempts without final outcome would overstate robustness.

Second, completion and grounding can move independently. The evidence-reference cohort completed only half its repeats but reported 11 verified references out of 12 claimed across the measured group. Reference-level grounding is informative; it does not guarantee that a run terminates or that the plan is semantically correct.

Why raw trajectories belong beside the scoreboard

Aggregates tell us that a repair happened. Trajectories tell us what the planner did with the feedback.

For this class of system, retain at least:

the first-finalize sequence;
every validation error category;
repair-action count and repair success count;
post-finalize calls and post-finalize tokens;
action-type histogram; and
the run IDs that connect a score back to durable artifacts.

This avoids a common benchmarking failure: averaging two runs with completely different mechanisms. A provider disconnect, a malformed response, an empty test discovery result, and a genuinely poor plan are all “failed runs,” but they demand different engineering changes.

What counts as a fair comparison

Keep these fields stable before comparing interventions:

Task and repository snapshot.
Model profile and planner configuration.
Budget limits and finalization checkpoint policy.
Acceptance and grounding rules.
Repeat count and exclusions.

Then report confounders explicitly. In the checkpoint experiment, one control failed after only three schema retries; using the raw group mean would make the candidate look much more expensive than a long-run comparison suggests. In the final fallback cohort, both repeats passed, but neither directly exercised the exact invalid-test repair path. That supports non-regression, not a broad causal claim about the fallback.

The operational output: an evidence bundle, not a screenshot

Every study-to-article handoff should include three machine-readable files:

data/study-metrics.csv       # group comparisons
data/study-cases.csv         # repeat-level outcomes
data/evidence-manifest.yaml  # source locations and SHA-256 hashes

The companion authoring-research-harvest skill generates these files from durable study artifacts. That lets prose, tables, and later charts be regenerated without depending on a chat transcript or an ephemeral runtime database.

Limits and next experiment

The current cohorts are small and sequential, not independently powered randomized trials. They are best used to identify failure modes, screen candidate interventions, and design a stronger follow-up.

The next benchmark should deterministically force the nonexistent-test repair branch, then compare a control and fallback treatment over at least four repeats per arm. Pre-register the expected success condition: the repaired task must contain the same planned test path in both tests and expected_files, within allowed scope. That turns a persuasive story about repair into an observable mechanism test.

Cohort results at a glance

Takeaways

Treat completion as one column, never the whole scorecard.
Keep repair telemetry separate from final success.
Preserve run-level provenance so an aggregate can be audited.
Make limitations part of the result, not a footnote after publication.

For the semantic consequence of this framework, read A Plan Can Validate and Still Be Unsafe to Implement.

Targeted Trajectory Repair: Low-Cost Continuations

Wed, 22 Apr 2026 00:00:00 GMT

Imagine an AI agent has just spent 15 minutes and thousands of tokens diligently analyzing a codebase and writing a complex plan. At the very last step, it fails a quality check. Throwing away all that work and starting over from scratch isn't just frustrating—it's incredibly expensive.

In this article, we demonstrate Targeted Trajectory Repair, a surgical approach to fixing AI mistakes. Using our orchestration framework, we show how to create lightweight 'child' runs that pick up exactly where the AI failed, fixing the specific error while saving massive amounts of computing power and time.

Provenance-Linked Child Continuations

Instead of resetting execution state, our orchestration framework creates a lightweight child run that clones the parent's SQLite database trajectory, active workspace state, and turn message history.

CLI Entrypoint & Kernel Mechanics

The CLI command orchestrator run repair-grounding <run_id> evaluates the source run's unverified path claims and injects a precise repair prompt into the child trajectory:

# orbit_harness/orchestration/commands.py
def repair_grounding(self, source_run_id: str) -> CommandResult:
    run_dir = self.repo_root / ".orchestrator" / "runs" / source_run_id / "agent-output"
    summary = result_data.get("summary", "")
    grounding = check_grounding(summary, self.repo_root)

    if not grounding.unverified:
        return CommandResult(success=True, message="No grounding repair needed.", data={"repaired": False})

    unverified_str = ", ".join(grounding.unverified[:5])
    repair_instruction = (
        f"Grounding Repair Mode: Your prior plan cited {len(grounding.unverified)} unverified file path(s): "
        f"{unverified_str}. Execute view_file() or grep_search() to inspect these files immediately."
    )
    return self.continue_failed_plan(source_run_id, instruction=repair_instruction)

Quantitative Efficiency Comparison

We benchmarked full trajectory reruns against targeted child continuations on grounding repair scenarios.

| Execution Strategy | Turns Executed | Tokens Burned | Latency (s) | Grounding Pass Rate | Cost Reduction | | :--- | :---: | :---: | :---: | :---: | :---: | | Full Trajectory Rerun | 15 | 44,080 | 222.8s | 100% | 0% (Baseline) | | Targeted Child Continuation | 2 | 4,200 | 18.4s | 100% | 90.5% |

Result: Targeted child continuations achieved identical 100% plan grounding pass rates while reducing token burn by 90.5% and reducing repair latency from 222s to 18s.

Key Takeaways

Clone Trajectories, Don't Rerun: Inheriting parent message history preserves contextual state without re-executing search steps.
Inject Explicit Targeted Prompts: Specifying the exact unverified file paths in the continuation prompt focuses model attention immediately on missing evidence.
90%+ Cost Reduction: Child continuations dramatically reduce evaluation costs across large agent benchmark suites.

Token Efficiency: Code Fences vs Large Contexts

Wed, 01 Apr 2026 00:00:00 GMT

As context windows for Large Language Models expand into the millions of tokens, a dangerous anti-pattern has emerged in agent engineering: the "Context Window Dump."

Instead of teaching agents to precisely navigate a repository, developers simply dump the entire codebase into the prompt. While this might yield quick results for trivial scripts, it destroys token efficiency and creates massive latency bottlenecks in recursive, multi-turn trajectories.

1. The Cost of the Dump

In a Recursive Language Model (RLM) loop, the context window grows with every turn. The agent sees the initial prompt, its own tool calls, and the tool responses.

If you dump a 100,000-token codebase into the initial prompt, and the agent takes 15 turns to solve a problem, you are paying to process those 100,000 tokens 15 times.

$$ 100,000 \text{ tokens} \times 15 \text{ turns} = 1.5 \text{ million input tokens} $$

This isn't just expensive financially; it incurs massive Time-to-First-Token (TTFT) latency, slowing down the entire swarm.

2. Single-Cell Turn Discipline

In our orchestration framework, we advocate for Small Code Fences and Single-Cell Turn Discipline.

Instead of dumping the codebase, the agent is given a strict set of precise tools (grep_search, view_file with line number constraints). The agent must actively explore the codebase, pulling only the snippets it needs.

The Efficiency Curve

When an agent uses targeted tools, its context window starts small and grows linearly only with the specific information relevant to the task.

Turn 1: grep_search("AuthModule") (Returns 500 tokens of results). Total Context: 2,500 tokens.
Turn 2: view_file("auth.py", start=10, end=50) (Returns 300 tokens of code). Total Context: 3,000 tokens.
Turn 15: Total Context: 15,000 tokens.

$$ \text{Average Context (8,750)} \times 15 \text{ turns} = 131,250 \text{ input tokens} $$

By enforcing discipline, we achieve a >90% reduction in token usage compared to the dump method, while drastically improving execution speed.

3. Engineering for Precision

LLMs are capable of processing millions of tokens, but that doesn't mean they should. Massive context windows should be reserved for problems that inherently require massive context (like reading a 500-page PDF), not as a crutch to avoid building proper search and navigation tools for your agents.

To build production-grade agent swarms, optimize for precision. Small fences build efficient agents.

Grounding Is Not Proof: Why 100% Code Completion Fails

Sun, 29 Mar 2026 00:00:00 GMT

It’s easy to assume that if an AI finishes a task without crashing, it did a good job. But what if it confidently hands you a finished blueprint that cites nonexistent materials? In the world of AI agents, evaluating systems purely by whether they finish a task creates dangerous illusions of competence. An AI can execute perfectly, hit no errors, and yet submit a plan full of fabricated file paths and unverified claims.

In this study, we tested several top-tier AI models—including Gemini 3.6 and DeepSeek v4—and discovered why a 100% completion rate means nothing if the AI’s work isn't strictly "grounded" in reality. More importantly, we show how to build safeguards that force the AI to double-check its facts before submitting its final answer.

The Execution vs. Quality Paradox

During matrix benchmarks, Gemini 3.6 model tiers consistently achieved 100% execution completion (0 runtime crashes, 0 budget pauses). However, when evaluated against strict quality gates checking whether cited file paths were actually read via view_file() or grep_search(), all provider groups failed the quality gate (BLOCKED (0%)).

| Provider Group | Completion Rate | Mean Score | Grounding Ratio | Quality Gate Status | Mean Tokens | Mean Elapsed (s) | | :--- | :---: | :---: | :---: | :---: | :---: | :---: | | cliproxyapi-gemini-3.6-flash-high | 100% | 1.00 | 75% | BLOCKED (0%) | 44,080 | 222.8s | | cliproxyapi-gemini-3.6-flash-medium | 100% | 1.00 | 0% | BLOCKED (0%) | 17,642 | 38.0s | | cliproxyapi-gemini-3.6-flash-low | 100% | 1.00 | N/A | BLOCKED (0%) | 18,354 | 64.7s | | deepseek-v4-flash | 33% | 0.33 | 100% | BLOCKED (0%) | 84,847 | 316.3s |

Key Takeaway: Gemini models ran fast and completed 100% of tasks, but cited file paths they had never inspected. DeepSeek achieved 100% path verification on the 33% of runs that completed, but consumed 4.8x more tokens and hit step ceilings.

Pre-Finalization Intercept & Self-Correction

To eliminate ungrounded answers without forcing full trajectory reruns, we implemented a Pre-Finalization Quality Intercept in our orchestration framework.

Intercept Implementation

When a model attempts to emit FINAL(answer), our orchestration framework extracts path claims and checks them against check_grounding(). If unverified paths are found:

# orbit_harness/rlm/general/rlm.py
if grounding.unverified and grounding.claimed:
    self._self_correction_attempts += 1
    unverified_str = ", ".join(grounding.unverified[:5])
    message_history.append(
        Message(
            role="user",
            content=(
                f"[Quality Check Alert]: The plan answer contains {len(grounding.unverified)} "
                f"unverified file path(s): {unverified_str}. Execute view_file() or grep_search() "
                "to inspect and confirm these files exist before calling FINAL()."
            )
        )
    )
    final_result = None
    continue  # Allow agent to inspect missing paths

Key Takeaways

Completion Rate $\neq$ Quality: Never rely on binary task completion as proof of model capability.
Pre-Finalization Intercepts Work: Pausing finalization to report ungrounded paths forces self-correction without wasting prior trajectory steps.
Deterministic Evaluation: Grounding ratio and required-finding checks provide unambiguous quality signals for agent benchmarks.

Artificial Quirks

Catching Hallucinated Paths: Quality Intercepts

1. The Anatomy of a Hallucination

2. The Pre-Finalization Intercept

3. Forcing Self-Correction

What a Two-for-Two Agent Result Actually Proves

Three claims that look similar but are not

Compare it with the checkpoint study

A practical interpretation template

Counterfactual: when is 2/2 enough?

The next experiment

Cohort results at a glance

Takeaways

The Security Cost of Autonomy: Traversal Risks

1. The Threat Model

2. The Audit Findings

How the Host Protects the System

3. The Cost of Security

Inside the Sandbox: Shell Execution Kills Reliability

1. The Illusion of Prompt Security

2. Hard Isolation is the Only Fix

3. Designing for Determinism

Strategies, Not Model Ifs

What this article assumes

The problem: one loop, two behaviors

Architecture: who vs how

Resolution order (highest wins per key)

Why not model ifs

Named presets (illustrative shape)

Knobs that earned a place

Ledger honesty (operations)

Worked scenarios

Counterfactuals

Limitations

Takeaways

When Smaller Cells Make Agents Worse

Background: cells in a recursive loop

Architecture of the failure mode

Experimental setup

Results

What the cell series shows

Core argument

1. Cell discipline is not the objective function

2. The first turn is sticky

3. When smaller cells are the right medicine

Worked example: reading the dashboard

Counterfactuals

Limitations

Takeaways

RLM Is Not Automatically Token-Efficient

Quick vocabulary

Three confusions worth separating

What unbounded history looks like

Core argument

1. Recursive efficiency is a policy surface

2. Report input and output separately

3. Token wins do not imply task wins

Worked example: reading a monitor line

Counterfactuals

Limitations

Takeaways

Grounding Is Necessary, Not Sufficient

What strict grounding changed

The worked failure: valid files, invalid plan

A hierarchy of evidence checks

Counterfactual: when path grounding is enough

What to add next

Cohort results at a glance

Takeaways

Zero Net Access: Hardening LLM Agent Sandboxes

Threat Model & Sandbox Requirements

Architecture & Control Flow

UDS Inter-Process Communication

Empirical Security Audit Results

Key Takeaways

A Plan Can Validate and Still Be Unsafe to Implement

The intervention: force synthesis before the investigation becomes a loop

What the normal gates caught—and missed

A better readiness model

The useful counterexample: 2/2 success without direct mechanism proof

Why not model `if`s