Agent8088: Agentic Harness for Making Small Local Models Reliable Agents

Why Does the Agentic Harness Matter More Than the LLM for Your Agentic Tasks, Especially for Small Local Models on Long-Running Tasks?

When using AI agents to complete automation tasks, the model provides the reasoning, while the harness provides everything else. That includes tool use, control flow, context management, memory, guardrails and verification. That makes a good harness important for completing agentic tasks reliably, especially for small LLMs and long-running tasks. Many studies have tried to measure how much the harness matters relative to the LLM, and concluded that it matters a lot.

• The study in “Stop Comparing LLM Agents Without Disclosing the Harness” [1] found that the variance in results caused by the harnesses was 7.8× bigger than the variance caused by the LLMs, and swapping the harness reversed 6 out of 9 model-pair rankings.
• As cited in “HarnessDev” [2], the Terminal-Bench 2.1 leaderboard shows one harness (Terminus 2) solving 35.2% of tasks, while another (Codex CLI) solved 49.6% with an identical GPT-5 model.
• Based on DarwinX [3] results, a self-evolving harness took a base agent from 43.5 to 93.0 on WebArena-Infinity, while keeping the LLM constant.
• According to “Finding the Right Fit: Model-Harness Interactions across Agent Tasks” [4], which tested 66 model-harness configurations, rankings reverse depending on the harness. A 7.94-point lead for one configuration became a 30.16-point deficit under another.
• In “Better Harnesses, Smaller Models” [5], CMU researchers adapted harnesses for small models on seven business tasks. Small models improved on 16 of 21 task-model pairs and fully closed the gap to a large model on 7 of them, at roughly 4 to 8% of the cost.

The harness matters for LLMs of every size, but it matters the most for small ones. A frontier model may compensate for a weak harness through raw capability, but smaller 9B, 12B and 27B models usually can’t. Harness also matters more where the tasks have specific failure modes.

• In HarnessX [6] experiments, the same self-evolved harness improved an open 9B model by up to 44.0% on ALFWorld, compared with 11.2% for a frontier model.
• In “Claw-SWE-Bench” [7], swapping harnesses moved coding scores by 10.2 percentage points for GLM 5.1, but by 24.3 percentage points for Qwen 3.6-Flash.
• Similarly, on the “Holistic Agent Leaderboard” [8] (HAL), the gap on SWE-bench Verified Mini between the SWE-Agent and HAL Generalist harnesses with the same LLM reached nearly 48 percentage points for the smaller o4-mini, compared with 34 percentage points for Claude Sonnet 4.5 and GPT-5 [1].
• “When Harness Beats Scale” [9] compared a 7B and a 72B model on the same document-QA task. The harness added 0.282 joint accuracy to the 7B model but at most 0.005 to the 72B model, and a 27B model with the full harness matched the 72B (0.884 vs 0.873).

Long-running tasks make per-step reliability critical. If each step of a task succeeds with probability p, a task of N steps succeeds with roughly p^N. At 95% per-step reliability, a 20-step task succeeds about 36% of the time.

• The “Measuring AI Ability to Complete Long Software Tasks” (METR) [10] results show that the length of task a model can complete at 80% success is about 4 to 6 times shorter than the length it can complete at 50% success. For example, o3 has a 50% time horizon of around 110 minutes.
• “Is there a half-life for the success rates of AI agents?” [11] showed that METR’s results fit a simple model where the agent has a constant chance of failing at every minute of the task. Under that model, for example, an agent that completes a 1-hour task half the time completes a 2-hour task about 25% of the time, and a 4-hour task about 6% of the time.
• Being right once is also different from being reliably right. On τ-bench [12], GPT-4o solved about 61% of retail tasks on a single try, but under 25% when it had to succeed on the same task 8 times in a row.

For a small model, the harness is the most direct way to achieve the required reliability. Many mechanisms in a good harness exist to stop that exponential decay, including verification, failure recovery, checked steps and context management.

How Local Models Actually Break?

Small models have specific failures that show up again and again, in published studies, in benchmarks and in the issue trackers of popular agent tools. Many of them occur around the model rather than inside it, which is why a harness can fix them.

We can group them into five failure-mode categories, with each tied to a part of the agent loop. They include what the model sees (Context), how it acts (Tool Use), how it finishes (Verification and Completion), what happens as the task gets long and starts changing the real world (Long Runs), and failures that only look like the model’s fault (Look-alikes). Most of these failure modes are not unique to small models. Larger models show them too, only less often.

Context: What the Model Sees

This category is about what the model actually sees when it makes each decision. Small models have small contexts, so anything that wastes, truncates or distorts the context hurts them early, and often without any error message.

The common failure modes in this category are the following:

• Silent Overflow: The prompt, tool definitions and history no longer fit in the window, so the server drops the oldest content without raising an error. The agent carries on, but the model never sees its instructions.
• Context Rot: The longer the context grows, the less reliably the model uses it. Instructions in the middle get missed, and mistakes already in the context make new ones more likely.
• Lossy Compaction: Summaries of summaries drift further and further from what the user originally asked for.
• Stale or Inherited State: The agent keeps acting on facts that stopped being true, such as an old file version or an earlier result.
• Knowledge Ceiling: A small model often does not have knowledge about specific things, especially if they are new or not common knowledge, and requires context engineering with search and retrieval.

Context issues are a well-documented problem for agents.

• “Mingbird” [13] names tool definitions overflowing the context as the first failure form of small models, because every tool adds its definition to the prompt on every turn. With 256 tools, a 4B model spent about 5.6 seconds per turn just processing the prompt, and a 2B model spent 33.6 seconds.
• “Lost in the Middle” [14] showed that language models use information in the middle of a long context much less reliably than information at the start or the end.
• The “Illusion of Diminishing Returns” [15] paper found that models are more likely to make a mistake when their own earlier mistakes are in the context, and that making the model bigger did not remove the effect.
• “How Fast Do Agents Rot?” [16] tested nine models (six open ones from 1.2B to 671B parameters) and found that success decayed with the number of steps rather than the length of the context, and that capping the context made the decay steeper, not gentler.

Tool Use: How the Model Acts

This category is about how the model acts. Almost every step runs through a tool call, so small slips in format, tool choice or repetition turn into failed actions that pile up over the run.

The common failure modes in this category are the following:

• Malformed or Invalid Calls: The model writes a tool call as plain text, uses the wrong format, or calls a tool that does not exist. A strict parser throws the call away and the turn is wasted.
• The Constraint Tax: Forcing the output into a strict schema guarantees valid format but can make the answer itself worse. A small model has little spare capacity to follow the format and think at the same time.
• Tool-Choice Collapse: With many tools on offer, the model picks the wrong one or gets confused, and every extra tool definition costs context on every single step.
• Repeating a Failed Action: The model runs the same failing command again and again, often because the failed attempt is still in its context, ready to be copied.
• Not Leaving a Dead End: The model can tell that a source or an approach is useless, yet keeps going back to it instead of stopping or changing course.
• Tool-Demonstration Loops: Given a casual question and a full toolset, the model starts demonstrating its tools instead of answering, and can fall into an open-ended loop.

Tool-use and action-related issues are also a well-documented problem:

• In “AgentBench” [17], open models ended 10.4% of runs with an invalid output format and 13.6% with an invalid action, against 6.0% and 4.6% for commercial models.
• “Flat Score, Amplified Failures” [18] found that 4-bit quantization, which most local users rely on, amplified tool-name hallucination and raised error volume by up to 2.5×, while the benchmark score stayed flat.
• “The Constraint Tax” [19] showed that forcing sub-3B models into a strict output schema raised format validity from 61.5% to 100%, but dropped answer accuracy from 19.7% to 11.0%.
• “RAG-MCP” [20] found that as the number of available tools grows, a baseline model’s success at choosing and running the correct tool drops markedly, and in its test the baseline reached only 13.62% tool-selection accuracy.

Verification and Completion: How the Model Finishes

This category is about how the model finishes and verifies success. It is where small models most often lose a task they had mostly done.

The common failure modes in this category are the following:

• False “Done”: The model announces that the task is complete while the files and functionality are missing, wrong or untested. The claim is confident, and nothing in the text gives it away.
• Fabrication After Silent Tool Failure: When a tool returns an explicit error, models usually say so. When it returns an empty, cut-off or corrupted result that looks like success, the model fills the gap with an answer the tool never gave.
• Failing Self-Verification: Asking the model to check its own work in the same context often doesn't help, and can talk itself into a wrong answer.
• Premature Wrap-Up: Some models stop early, give up halfway without saying so, or wrap up because they sense the context limit approaching, leaving the required output unfinished.

Verification and Completion issues also have documented evidence:

• In “From Confident Closing to Silent Failure” [21], an analysis of 9,876 τ²-bench trajectories, false success made up 45–48% of failures in single-control domains. Among AppWorld coding-agent trajectories that made an explicit status claim, it was 75.8%.
• In “What Stops a Small Language Model From Driving a Database Agent” [22], the largest class of tool-using losses (36.2%) was runs that used tools but never delivered a result.
• “Fabrication After Tool Failure” [23] found that when a tool returned an explicit error, models did not invent a value. When it returned an “ok” status with an empty, truncated or corrupted payload, 45.3% of responses asserted a value the tool never gave.
• “Locating Hidden Failures Makes Long-Horizon Agents More Reliable” [24] analyzed 2,518 agent trajectories and found that the strongest of six frontier judges located the first mistake in fewer than a third of runs, and that runs scored as solved can still delete data or fabricate success.

Long Runs: State, Side Effects and Safety

This category is about what happens as a task stretches over many steps and starts making changes in its environment. Mistakes in such scenarios have lasting effects, and the model does not reliably remember what has already been done.

The common failure modes in this category are the following:

• Duplicate Side Effects: A write times out and the model retries it, so the action happens twice. It could be a duplicated record, message or payment, too. The model usually reports success anyway.
• Unrecoverable Edits: A bad edit overwrites a file with no way back, and the next turns are spent trying to repair it instead of doing the task.
• Unused Memory and Checkpoints: Even when a memory or checkpoint tool is available, models rarely use it, so progress is lost after an interruption or a context reset.
• Time and Budget Blindness: When time or step budgets are provided in the prompt, the model does not turn that into controlled behavior. It runs out of time before delivering, or uses spare time on repeated actions.
• Objective Drift: Over a long task the model quietly redefines what “done” means, and rationalizes a missed target instead of reporting it.
• Unsafe or Out-of-Scope Actions: The model can write outside the working directory, touch credential files or take actions nobody asked for, especially when it is guessing.

Issues with Long Runs are also well documented:

• “LIMBO” [25] tested what happens when a write times out and the agent retries it, across 25,930 test runs. When the first request was still in progress or arrived twice, even frontier models duplicated the write in 56% and 74% of runs and claimed success in 90% of those cases. Adding an idempotency key to every write cut duplicates from 28% to 4%.
• “Planarian” [26] points out that when an agent’s work goes wrong it may have to undo earlier actions, and reconstructing the state can be costly or impossible if data was lost, so changes to files and online services otherwise have to be repaired by hand.
• “Judged Useless, Queried Anyway” [27] found that when a budget was stated in the prompt, the 7–8B models kept going until the deadline instead of stopping on their evidence.
• “Evaluating Goal Drift in Language Model Agents” [28] found that agents given a goal drift away from it over time when pressured by competing objectives. Every model tested drifted to some degree.

Look-alikes: Failures That Aren’t the Model’s Fault

This category is about failures that look like the model’s fault but are not. They matter because they make users try to fix the wrong thing, such as swapping models when the real problem is something else.

The common failure modes in this category are the following:

• Serving-Stack Quirks: The local server silently rejects, reshapes or truncates tool requests for some models, and the harness counts this as the model failing to call a tool.
• Harness Bugs Mistaken for Model Faults: A parser that drops valid output, a token cap that cuts replies short, or a scoring rule that is too lenient can look like a weak model.
• Run-to-Run Noise: Even runs with identical model and harness pairs give different results, so a small improvement measured on a few tasks or runs may be luck rather than a real gain.
• Platform and Encoding Fragility: A harness built for one operating system can fail on another before the model reasons at all, for example by sending the wrong shell commands or crashing on how text is encoded.

The evidence for such issues includes the following:

• “Measuring the Serving Stack Instead of the Model” [29] found that Ollama accepts tool-call requests only for models whose chat template has a certain flag. Some models, such as Phi-3 and Gemma-3, were rejected before the model ran at all. The test harness recorded those rejections as the model failing to call a tool, so a naive run scored them at 0%.
• “What Stops a Small Language Model From Driving a Database Agent” [22] studied 39 local models over 8,199 runs. The server logs recorded refusal codes but not the arguments the models had sent, so many failures went unseen for ten days.
• “Mingbird” [13] reports two harness bugs that made small models look worse. A strict parser threw away tool calls the model wrote as plain text, which wasted the whole turn. And an output cap of 2,048 tokens cut large files off halfway and sent runs into a spiral of empty turns. Recovering malformed calls and raising the cap to 8,192 fixed both.

When the Model Breaks

The failures above also tend to happen in a rough order over the life of a run:

• Before the First Useful Step: Overflowing or truncated prompts, a serving layer that rejects tool requests, platform and encoding problems, and tool calls the parser cannot read. These look like “the model is dumb” and are the cheapest to fix, so they should be ruled out first.
• In the First Dozen Steps: Picking the wrong tool, repeating a failed call, returning to a dead end, or demonstrating tools instead of working. This is where mistakes in the context can start a chain of mistakes.
• Around the First Compaction or Resume: Dropped constraints, stale facts and forgotten progress. These appear once a run outgrows a single context window.
• At Every Side Effect: Duplicated writes, edits that cannot be undone and actions outside the task’s scope. Each is rare on any single step but costly when it happens, and invisible if only the transcript is read.
• At the End of Every Run: False completion and made-up results after silent tool failures. This is the largest single source of lost tasks, and the one a verification step converts most reliably into a visible failure.

Agent8088: Agentic Harness for Reliable AI Agents, Even on Small, Local Models

Agent8088 is an open-source agentic harness from Palindrome Research Labs. It was built to make small local models finish real agentic tasks reliably. Most of the ways a small model fails can be fixed by engineering the harness around it.

Most harnesses are developed, assuming a large model and trusting it. Agent8088 does not consider the model to be reliable. It guards the context window, checks what actually changed before it accepts a “done”, keeps a run moving when the model stalls, can undo and resume, and enforces safety in code instead of in the prompt. The goal is a harness that gets real work done by a small model and then tells what got done and what did not and what could not be tested. Bigger models run into the same failures too but less often, so they benefit too. Agent8088 is also a complete agent product.

How Agent8088 Makes Small Models More Reliable

The approach can be grouped into seven pillars, and each one targets specific failure modes from the categories above i.e. Tool Intelligence, Robust Context Management, Verification-Gated Completion, Grounded Execution, a Reliable Control Loop, Failure Recovery, and Transparent, Safe and Controlled operation.

Tool Intelligence

Tool calls are how the agent takes actions to accomplish the task, so choosing the right tool and calling it correctly is essential for making progress in succeeding in a run.

Failure Modes Addressed: Malformed or Invalid Calls, the Constraint Tax, Tool-Choice Collapse, and Fabrication After Silent Tool Failure.

How It Works

• Tool Selection: Each request only sees the tool definitions most likely to matter, picked by combining keyword and embedding search. When the two methods disagree, it falls back to the full set instead of guessing. A few intent rules settle known overlaps, so a code-review request gets the dedicated reviewer and not a raw git diff.
• Forgiving Parsing: Native tool calls and text markers both work, and broken JSON escapes get repaired. Only allowed tools run. If the model asks for a tool that doesn’t exist, it gets a correction written in the format it was already using. Only a few retries are allowed.
• Argument Checks: Calls to built-in and MCP tools are checked against the arguments they declare. A misspelled argument name is mapped to the one the model most likely meant. A value of the wrong type is refused with a clear message.
• Exact Edits: edit_file replaces exact text and refuses a match that could mean more than one place. Reading back a path the model wrote works too, even though the sandbox stores new files under an artifacts folder. If a file write is cut off by the output limit, the part that arrived is saved when that’s safe in a new file or as an append. The model is told to carry on from there.
• Output Shaping: Noise is stripped out of tool output. When output has to be cut, both ends are kept and most of the room goes to the tail, because that’s where test runners print their result. Test and build runs get a short verdict of passed, failed or unknown, and “no tests ran” never counts as a pass. The full text stays available through last_output.
• Clear Errors: Every error comes with a code, a message, a suggested next step and a note on whether retrying makes sense.
• Lazy Skills: The 39 bundled skills load only a name and a short description until a skill is needed, and the CLI-Anything integration installs on first use, after you approve it.
• Tools as Data: A new tool is a row in a registry along with its permission mode, so adding one can’t bypass the permission gate.
• Measured Selection: Scripts score the tool selector (Recall@K, and COMP@K, the share of prompts where every required tool is present) and check live tool choice against a real model.

Research Evidence

• “RAG-MCP” [20] found that offering only the relevant tools raised tool-selection accuracy from 13.62% to 43.13% and cut prompt tokens by more than half.
• “The Constraint Tax” [19] also found that on a calendar tool-call task, Qwen2.5-1.5B fell from 91.5% accuracy with prompt-only JSON to 48.0% under a hard tool-call schema, even though both modes were fully schema-valid. So, the loss is semantic rather than structural. Its suggested pattern is to let the model reason freely and apply the constraint late. For small models, recovering intent beats strict enforcement.
• “Flat Score, Amplified Failures” [18] also found that a targeted error-repair prompt, tested on five telecom models at every precision, removed the extra errors exactly where quantization had added them, and nowhere else.
• “SWE-Skills-Bench” [30] found that 39 of 49 injected skills gave no improvement and the average gain was only 1.2%. Token overhead ranged from modest savings to a 451% increase. Seven specialised skills helped by up to 30% and three hurt by up to 10%, which is why skills are loaded lazily.
• “SWE-agent” [31] showed that an interface designed for the model solved 10.7 percentage points more instances than a baseline using only the default Linux shell.

Robust Context Management

Context is the model’s working memory. This pillar tries to ensure, what gets sent actually fits, that what’s kept is what matters, and what is dropped could be recovered.

Failure Modes Addressed: Silent Overflow, Context Rot, Lossy Compaction, Stale or Inherited State, and the Knowledge Ceiling.

How It Works

• Token Check: Before every call it estimates the prompt size, tool definitions included, corrects that estimate with the token count the server reported last time, and caps the reply at whatever room is left. If nothing fits, it fails loudly instead of sending a request the server would quietly truncate.
• Overflow Recovery: If a request still comes back as too long, the harness compacts the history, drops old tool output, and then retries once with a smaller output cap.
• Careful Compaction: At 75% of the window (configurable), older messages are summarised and the recent ones are kept. A single-turn task’s request stays word for word. The constraints that user stated earlier are copied verbatim into a section that is marked as not written by the model. An earlier summary is carried forward as written instead of being summarised again, and any rule files the user asked the agent to follow are re-read from disk.
• Task State Outside the Chat: The controller keeps its own record of the goal, the checklist, the evidence, the files written and the checks that passed, and gives it to the model every round, so it survives compaction. Users can read the same record at any time with /status.
• Full Output on Demand: Long tool output is trimmed in the conversation, but the full text is kept, and last_output can fetch the part that was cut.
• Outside Knowledge: Web search (SearXNG, DDGS, Tavily, Exa or a keyless fallback), a local memory with keyword and embedding search, repository maps and reads, and document reading with OCR for scans fill in the knowledge a small model doesn’t have.

Research Evidence

• “Mingbird” [13] keeps its fixed prompt small. It classifies the task first, loads only the tool definitions relevant to that category, and pins the fixed part of the prompt at 797 tokens with a test, so that any new feature must add no prompt growth.
• “The Illusion of Diminishing Returns” [15] found that models make more mistakes when their own earlier mistakes are in the context, and that a bigger model does not fix this.
• “What Stops a Small Language Model From Driving a Database Agent” [22] found that a 7.1 GB model with no context limit used its full 262,144-token window and 51 GB of a 64 GB machine. In the logs it looked like a plain timeout.
• “Skip the Compressor” [32] found that at an equal token budget, showing whole files verbatim resolved 43.7% and 46.7% of issues with two models, 6.3 points more than the best compressor, because a patch needs the exact text.
• “Pack Light, CarryOn” [33] continues long tasks from reusable task objects instead of compressed history. It gained 5.8% and 7.0% on two benchmarks while using 51.9% and 22.9% fewer tokens.
• “SKILL.state” [34] replaced accumulating history with an explicit structured state. After 100 steps it used 65,408 tokens against 1,062,387 for a history-accumulating baseline, a 16.2 times reduction.

Verification-Gated Completion

A model can say “done” when the task isn’t actually completed successfully. This pillar doesn’t accept a reported success until the work has been checked.

Failure Modes Addressed: False “Done”, Fabrication After Silent Tool Failure, Failing Self-Verification, and Premature Wrap-Up.

How It Works

• Pre-Answer Checks: When a reply has no tool call, a fixed series of deterministic checks runs first, and none of them calls a model. An empty reply is retried with thinking off. A reply that admits the work is unfinished is sent back. Files the request asked for must exist and can’t be empty. A web-app request with no page or server entry point is sent back. Pages and scripts the run wrote get a smoke test (a headless browser for pages, a syntax check for scripts). Saved reference pages, such as downloaded docs, aren’t judged as if they were the deliverable. Every part of a multi-part request has to be addressed, and changed work with no passing check is told to run one. A request that changed nothing never gets a verification reminder.
• Bounded Follow-Ups: Every follow-up tells the model to keep working, never to wrap up. A lighter version runs during the work. After three changed files with nothing run or opened, the model gets a short reminder to run what it wrote, up to three per request. They all use a small shared budget, so a task that can’t be finished still ends, and a follow-up that leads to progress hands its slot back.
• Honest Labels: Every answer says how well it was checked, on one of five levels. The levels include tested (a test run passed after the last change), exercised (it ran without an error, which is weaker), inspected (the files were read back, nothing was run), unchecked (nothing was run or read back) and failed (a check is failing). A NOT VERIFIED headline appears when a check is failing or evidence is missing. Anything unmet is listed under “Not completed”, and a note flags when existing tests were edited.
• Saying What Was Not Checked: Some things can’t be checked from inside the sandbox, and the harness says so instead of scoring them. If a page calls its own server or a local service it couldn’t reach, the answer says that part was not verified, and an optional backend check can start the project’s own server in the sandbox and probe the endpoints the page uses, reported on its own line. If there is no app to run, the answer doesn’t call the work “exercised”. And when a check can’t run because the machine won’t let it e.g. when no browser could be started, the sandbox refuses to launch a process, or the script needs a package the check’s Python lacks, then it is reported as not verified, not as a failure.
• Optional Audit: With auditing on, a separate read-only sub-agent checks each step that changes something against the real environment, using the plan the user approved, before the plan proceeds. A failed audit stops the plan. It costs one extra model call per changing step, so it’s optional, and its cost is reported, for example “verification cost this turn: 22% of tokens”.

Research Evidence

• “From Confident Closing to Silent Failure” [21] found that five LLM judges, tried with five prompt strategies, never exceeded 0.65 AUROC at spotting false success on τ²-bench (0.54 on AppWorld), because they anchor on confident closing language. Simple TF-IDF detectors reached 0.83 and 0.95 and caught 4 to 8 times more false successes at the same flag rate. That supports checking with deterministic rules instead of asking another model to judge.
• “ThinkingBox” [35] checks 507 business workflows by the final state of the database. Claude Opus 5 passed 66.50% of single attempts but only 47.53% when it had to pass all 20, and the authors conclude that response-level signals are weak indicators of completion.
• “FIRE” [36] applies targeted runtime policies at the stop and tool-call boundaries. They raised repeated success by 3.4 to 9.2 points across three model tiers on Terminal-Bench 2.1. In a randomised test, real policies reached 61%, against 39% with none and 39 to 43% with generic “verify” prompts.
• “LongHorizon-Harness” [37] runs each subtask in a fresh context and has a read-only auditor check the environment before the next round. It lifted Qwen 3.7-Plus from 51.8% to 80.7% on WeaveBench and from 69.7% to 77.2% on Terminal-Bench 2.1.
• “Evidence-First Agentic Verification” [38] checked each claim against its source and reached an F1 of 0.96 against 0.92 for the strongest baseline, at 23% lower cost.
• “AgentSWE” [39] lists recurring failure modes of coding agents, including “hollow runtimes” behind code that looks complete, and unsupported claims of completion.
• “Rethinking Verification in Agent Harnesses” [40] compared 17 verification designs on seven coding models. Prompt instructions and mid-turn reminders gave modest, model-dependent gains, completion gates helped more at a higher cost, and an independent critic gave the best accuracy for the cost.

Grounded Execution

Grounded execution means judging every step by what really happened in the environment, not by what the model says.

Failure Modes Addressed: False “Done”, Fabrication After Silent Tool Failure, and Stale or Inherited State.

How It Works

• Observable Results: The 59 built-in tools each declare a permission mode, and every result comes back as an observation the loop can inspect.
• Observed Facts Only: The task record holds only what the controller saw i.e. files written, checks that passed or failed, and operations performed. Full arguments and outputs stay in the transcript.
• Runner Verdicts: Test and build output is parsed, so the model hears what the runner actually reported instead of guessing from a column of passing lines. A test script the run wrote itself counts as a pass when its output ends on a clear pass line and nothing in it looks like a failure. Commands that only ask whether something is installed (where, pip show and import checks etc.) are never scored as results. A failed check is cleared when the same command, or an edited version of it, later runs clean. Once a test run passes, work that had only been read back or page-checked counts as tested.
• Real Checks: Named output files must exist, pages are loaded in a browser, and an optional auditor reads the actual files. A page that imports from a parent folder is served from the folder it needs. If the browser can’t start at all, the answer says so as a limit of the machine and suggests what to do instead. A plan stops at its first failed step, so later steps are never built on an effect that didn’t happen.
• Exact File Copies: copy_file and move_file copy the bytes themselves instead of making the model retype the content.
• Cited Sources: A grounding check nudges answers that used web research to say what the sources actually said.

Research Evidence

• “AgentForge” [41] is an execution-grounded multi-agent framework that reached 40.0% on SWE-bench Lite, 26 to 28 points above single-agent baselines. Its ablations show that execution feedback and role decomposition each drive the gain.
• “Fabrication After Tool Failure” [23] found that one added sentence requiring an explicit OK or FAILED retrieval status before answering cut dishonesty from 14.10% to 0.87%, and that it transferred unchanged to three other agent scaffolds.
• “LongHorizon-Harness” [37] argues that harnesses which keep execution, task state and completion checks in one growing context, let incorrect self-assessments spread into later decisions. It keeps task state outside execution and updates it only with facts independently verified from the environment.
• “What Coding Agents Leave Unsaid” [42] found that readers of agents’ reports recovered 52.0% of task-state facts, against 92.7% for readers of the full execution context, because failed attempts and workarounds disappear from reports.

Reliable Control Loop

Left alone, small models repeat themselves, wander into dead ends and run out of time. This pillar keeps a run moving and inside its limits, and most of it lives in code, not in the prompt.

Failure Modes Addressed: Repeating a Failed Action, Not Leaving a Dead End, Tool-Demonstration Loops, Time and Budget Blindness, Premature Wrap-Up, and the Capability Floor, where a model is too weak for a step.

How It Works

• Repeat Breaker: An identical call (same tool and arguments) is answered from cached output instead of being run again. However in Polling a repeated shell command is run again once enough time has passed, so waiting on a slow job isn’t mistaken for a loop. Three increasingly firm warnings follow, and then the run is told to stop using tools and answer. The run record marks that ending as no_progress, not turn_limit.
• Stall Watch: The loop counts rounds where nothing new happened: no new successful call, changed file, newly passed check or finished part. The model is asked once to finish or change approach, and if a second stretch is just as empty the run ends with a summary. A separate signal tells a run that is already built and passing to finish instead of inspecting it again.
• Forced Replan: After two recent failed or blocked actions, the controller tells the model not to repeat them and state a short revised approach and take some other safe action.
• Clock and Round Warnings: The harness supplies the clock. Warnings arrive at 60% and 85% of the time budget and at 80% and 95% of the round limit, each asking that every required output exist by now.
• Earned Rounds: A request starts with 400 rounds and keeps earning more while it makes real progress, up to three times that. A long task that is still moving forward doesn’t get cut off.
• Model Escalation: An optional auto model starts on the cheapest rung of a ladder of models and moves up only when the run shows it is struggling i.e. a reply cut off at the limit, repeated invalid tool calls, unknown tools, or no progress. It never asks the model to predict its own difficulty. Fallback models are a separate thing and only cover providers that can’t be reached.
• Shared Budgets: Sub-agents inherit the parent’s remaining tokens, cost and time, so delegating can’t reset the allowance. Per-turn limits on time, tokens and cost are available too.

Research Evidence

• “Feedback That Backfires” [43] found that small models (135M to 1.7B) were more likely to repeat a call they had just seen fail, with the chance rising from 0.06 to 0.54. An explicit “do not repeat” instruction changed nothing, while replacing the failed call with a description of the failure removed 76% of the effect. That is why repeat control is done in code.
• “Judged Useless, Queried Anyway” [27] found that seven agents judged a failing source useless 97 to 100% of the time, yet most kept querying it. A harness-enforced step after five useless results raised success for every model and held in a replication on 300 fresh questions.
• “Babysitting AI Agents” [44] sorted failures from 163,487 Reddit posts about agents into a taxonomy of 23 categories. Running on long after progress has stopped was the most reported, at 15.4% of failure reports.
• “Progress-Aware Distillation” [45] reports that distilled small-model agents (0.6B to 8B) get trapped in unproductive loops of failed strategies, across models and task domains.
• “Harness Evolution Hits a Ceiling” [46] showed that harness changes improved a 4B model’s held-out plan delivery from 55% to 90% and reduced loops, while content failures, where the plan itself is poor, were left for the weights. Control in code fixes process failures, while a stronger model handles the rest.
• “EdgeWise” [47] uses a small local model as the main solver and hands only key steps to a cloud model. It matched or beat pure-LLM execution while cutting inference cost by up to 62% on SWE-Rebench and 34% on Terminal-Bench 2.1.
• “LEASH” [48] notes that a small open-weight model alone often fails on long tasks, and escalates to a strong model only when an uncertainty signal says it is needed.
• “On the Clock” [49] found that a time budget stated in the prompt does not lead to controlled use of time, and that passing timing information through the harness helps.

Failure Recovery

Mistakes are common in a long agent run. However, their impact depends on whether they can be detected and undone, and whether the run can pick up where it stopped. A harness can handle such failure handling and recovery.

Failure Modes Addressed: Unrecoverable Edits, Unused Memory and Checkpoints, Duplicate Side Effects (by never trusting an unknown outcome), and recovery from Silent Overflow and cut-off replies.

How It Works

• Rollback: With auditing on, a write that fails verification is restored to its exact previous bytes, and any files it created are removed. Shell, sandbox and scheduling steps can’t be undone, so they are reported as “not reverted” instead of pretending otherwise. Files too large to snapshot are reported too.
• Stop at the First Failure: A plan halts when a step fails and says how many steps never ran, so a half-finished plan can’t pass as a finished one.
• Resumable Tasks: A durable task runtime keeps tasks in SQLite, with atomic checkpoints and an append-only ledger written before and after every tool call. If the process dies, operations caught mid-flight are marked unknown. The task is paused and resumable, so the agent checks them before building on top.
• Cut-Off Handling: A reply cut off at the output limit is discarded, not replayed. The harness retries it with an adjusted cap (a larger one when a tool call was cut off), then with thinking turned off, then compacts the context and adds a progress note, and as a last step makes one call with no tools that reports what exists. The caps themselves follow the model’s context window instead of being fixed numbers: the first-call cap is a quarter of the window (between 2K and 16K tokens) and the floor after a cut-off is half of that, so a 27B reasoning model that spends its first few thousand tokens thinking isn’t cut off at 4 to 8K. The browsing sub-agent keeps its own adaptive cap, which doubles after a cut-off and is no longer allowed to shrink below half its starting size. A cut-off file write is saved when that’s safe. Context overflow triggers compaction and a retry, and a failing model backend returns the best output so far instead of crashing.
• Saved Progress: The controller saves the task state itself, so recovery doesn’t depend on the model remembering to save its work.

Research Evidence

• “Planarian” [26] adds agent statepoints, restorable snapshots of local and remote state, with snapshot, rollback and fork operations so an agent can undo mistakes and explore alternatives. It reports up to 15 times better task quality, and recovery from erroneous actions with only 3% overhead.
• “LIMBO” [25] found that when a write’s outcome cannot be checked by reading it back (the request is still in flight, or was delivered twice), the tool contract, not the model, explains 81% of the variance, and no policy based only on verification can guarantee a write happens exactly once unless in-flight time is bounded. An outcome after a timeout is not something to take on trust, which is why interrupted operations are marked unknown.
• “ReTerm” [50] notes that terminal agents often struggle to recover from errors in long runs. Training Qwen3.5-9B on its own recoveries raised Pass@1 on Terminal-Bench 2.0 to 34.8%, up 14.6 points.
• “Locating Hidden Failures Makes Long-Horizon Agents More Reliable” [24] found that after a first mistake, agents often fail to recover and rarely notice the error, so the run carries on looking correct.

Transparent, Safe and Controlled

An agent that edits files and runs commands has to be safe by design and easy to inspect. Agent8088 takes care of that safety and observability.

Failure Modes Addressed: Unsafe or Out-of-Scope Actions, and, by making runs inspectable, the look-alike failures that are easy to blame on the model.

How It Works

• Permission Modes: readonly, full-auto and plan-only, with one-time scoped approvals. git_push asks every single time, for that exact remote and branch.
• Stop and Wind Up: Telling a model “don’t execute anything further” in the prompt is only a request, and a model in the middle of a plan often carries on anyway. So the stop is enforced by the harness. /hold takes every tool away. If that happens, nothing can run, replies are text only, and the user can still ask for an update. /continue (or /resume with no name) releases it. /finish asks for a final answer right now with no tools, and adds the harness’s own verification notes, so the model’s summary can’t overrule the evidence.
• Ten Layers: Path scope, sensitive files, shell start-up files, write zones, the permission mode, a shell classifier that sees through sh -c, hard Git blocks, an SSRF guard that follows redirects, the sandbox and output guards. Each layer can only say no. Credential paths, shell start-up files, destructive Git operations and system-prompt exfiltration are blocked in every mode.
• Gated File Writes: A change made through a file edit goes through the same gate as one made through the shell.
• Sandbox: Shell and code run inside a native OS sandbox, with Docker as the fallback. If neither is available, execution is refused instead of running unprotected.
• Secret Protection: Pasted text and written files are scanned for credentials, attachments are isolated per session, and a recalled memory can never authorise a tool call. The scan looks at the shape of a string, and it is tuned to ignore ordinary noise such as cache-busting hashes in saved web pages, while real keys are still flagged.
• Usage Visibility: Each turn gets a token and timing summary, with usage split between the main agent and each sub-agent, plus a verification-cost readout, optional local cost telemetry and an optional audit log of every tool call and approval. /capabilities shows the live tool, sandbox and guardrail setup, /status shows where the current task stands (goal, steps, changed files, verification level and latest check) without calling the model, and /doctor and a redacted /dump help with diagnosis.
• One Shared Layer: The CLI, web UI, messaging gateways, MCP server and scheduled runs all call the same agent loop and tool runner, so a permission fix lands everywhere at once. The MCP server exposes read-only tools by default, because MCP has no approval channel.
• Restricted Sub-Agents: Six profiles (explore, researcher, coder, test-writer, auditor and general-purpose) run in separate contexts. Their tool limits are real isolation, not advice.
• Strict Unattended Runs: Scheduled runs refuse anything that would have needed an approval.

Research Evidence

• “Overeager Coding Agents” [51] found that the framework had the largest effect on out-of-scope actions on ordinary tasks. Permissive frameworks went out of scope in 5.4% to 27.7% of cases, while one that asks before continuing did so in 0.2% to 4.5%.
• “Measuring the Permission Gate” [52] stress-tested a deployed classifier-based permission system and found a false-negative rate of 81.0%. It also found that 36.8% of state-changing actions fell outside the classifier’s scope because they were in-project file edits, the gap that gating file writes like shell commands closes.
• “ToolEmu” [53] tested agents on 144 high-stakes cases across 36 toolkits, and even the safest agent failed 23.9% of the time.
• “SWE-MISBEHAVIOR” [54] reports that open-source coding agents silently compromised environment integrity in 53% of cases and modified user inputs without being asked in 50.5%. Misbehaviour-aware guidelines with extra tools cut misbehaviours by 52% for one agent and 34% for another.
• “What Stops a Small Language Model From Driving a Database Agent” [22] found that once the models’ arguments were captured, five server defects appeared, and fixing them, with no change to the models, prompts or sampling, moved six models by 6 to 21 of 30 test cells. Visibility is how look-alike failures get found.

Agent8088 Beyond Reliability: What Makes It a Good Agentic Harness Product

Apart from focusing on reliability on small models, Agent8088 aims to be a good agentic harness with a variety of useful features.

What It Can Do

• A Real Working Toolset: 59 built-in tools cover files, shell, sandboxed Python, Git, web search, browsing, scheduling, documents and more.
• Web Research and Browsing: Search runs on SearXNG, DDGS, Tavily, Exa or a bundled keyless fallback, with date-aware queries and automatic fall-through if a backend fails. A headless browser can click, fill in forms and extract data, and it hands control back to the user for captchas and passwords.
• Documents and Images: It reads PDFs and Word, Excel and PowerPoint files, with checkpointed handling for large files and OCR for scans. It can also create .docx, .xlsx and .pptx files and convert Office documents. A local OCR engine enables text-only models to read screenshots too.
• Coding: It can analyze a repository, do a dependency-ranked map and bounded reads of local folders or GitHub repos, review code with file, line and severity, and give a source file to a sub-agent that writes and runs tests for it.
• Plan First, Then Act: With /plan the agent creates a plan and waits for user approval before making any change. If the model sends back a text-only plan, or announces a step and never takes it, it’s sent back to try again, and the planning time limit (600 seconds by default) is lifted once it is approved.
• Sub-Agents: Six focused profiles can handle exploring, research, coding, test writing, auditing and general tasks in separate runs, so a noisy job doesn’t clutter the main conversation and run in parallel.
• Memory: Facts to retain about the user and projects are learned from finished turns and recalled automatically with keyword and semantic search. The memory is stored in a local SQLite file, and the user can inspect, search and delete memories. An optional Mem0 memory integration is also available.
• Scheduled and Unattended Work: Recurring tasks can run through cron or Windows Task Scheduler, and one-off unattended runs can start from a prompt file, using the same safety rules as everything else.

Flexibility for Users

• Use the Model You Want: Local Ollama models, 12 built-in provider profiles or any OpenAI-compatible endpoint, with fallback models for when a provider fails. Users can switch mid-session with /model, and it can check the hardware and suggest, pull or remove local models.
• Terminal, Web or Chat: The same engine runs in the terminal, in a Web UI with live diffs and approvals, and in Slack, Discord, WhatsApp, Telegram and email. In the Web UI users can start or resume another chat while a task runs, and messages they send in the meantime are queued.
• Chat Approvals: In a messaging gateway, approvals happen in the chat itself (/approve and /deny, with buttons on Discord). Access is fail-closed and no one can chat with the bot unless they’re on the allowlist, and there is also rate limiting.
• Open Both Ways: It can use external MCP servers, and it can serve its own safe tools to Codex, Claude Code or Cursor. An experimental CLI-Anything integration lets it drive application CLIs while Agent8088 keeps control of planning, permissions and verification.
• Skills and Personas: 39 installable skill packages add know-how on demand, and a USER.md persona file sets tone and preferences.
• Sessions: Named sessions can be saved, resumed, compacted and exported to JSON along with the trace.

Easy Installation and Observability

• One-Command Install: One command per platform (macOS, Linux, WSL2, Windows) sets up an isolated Python environment, the global command, the browser, OCR and optionally, the memory engine. Users can also let an AI agent do the install from a prompt in the README. The Windows installer checks dependencies by actually running them and repairs a partial install instead of calling it done. Failures print the likely cause and a retry command, and the log is saved.
• A Guided Setup: agent8088 --setup walks through the provider, model, workspace and search backend. API keys go in a separate .env file, not in the config.
• Built-In Diagnosis: /doctor checks the setup and can repair web search. /dump writes a redacted bundle for bug reports, /status and /capabilities show what is live and /limits shows and changes every budget in one place.
• Transparent Usage: Per-turn token and timing summaries, optional local cost telemetry, an audit log and a step-by-step trace make it clear what the agent did and what it cost.
• Plain-Text Configuration: All the settings are in one readable config file, with comments explaining each option, so behaviour is easy to inspect and change.
• Updating: agent8088 --update follows the release branch, and the uninstaller can preview what it would remove before it touches anything.

Good Engineering Practices

• Layered Testing: Unit tests cover permissions, tools, gateway and MCP. Feature-verification scripts check real behaviour in temporary repos and sandboxes. An exhaustive script checks tool specs and the shell classifier. A duplicate-definition check guards the registry. A public-release gate and a pre-PR checklist sit on top of that.
• Safe Test Isolation: Tests and live runs use a scratch home and config, so they don’t interfere with a developer’s real settings. A live-model script scores real tool choice and does not run without an explicit opt-in.
• Clear Documentation: A versioned wiki covers getting started, permissions, tools, providers, memory, MCP, the gateway, skills, architecture, testing, troubleshooting and contributing. It also lists known gaps openly.
• A Disciplined Branch Workflow: New work branches from the current development branch, a sync check blocks edits on a stale branch, and promotion to the release branch follows a recorded procedure.
• Security Reporting: There’s a private route for reporting vulnerabilities, and contributors are told never to put credentials in public issues.
• Small, Focused Modules: Pure functions with their own tests handle completion checks, output shaping, routing and patching, so rules can be tested against recorded replies without a model.

Together, these make Agent8088 easy to install, easy to run on the model you already have, and safe enough to leave running.

References

[1] Y. Zhang, J. Wang, Y. Ge, W. Xu, J. Hamm, and C. K. Reddy, “Stop Comparing LLM Agents Without Disclosing the Harness,” arXiv:2605.23950, May 2026.

[2] Y. Wu et al., “HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?” arXiv:2609.01437, Sep. 2026.

[3] Y. Zhang et al., “DarwinX: Evolving Agent Harnesses Through Natural Selection,” arXiv:2608.07545, Jul. 2026.

[4] Y. Li et al., “Finding the Right Fit: Model-Harness Interactions across Agent Tasks,” arXiv:2610.00917, Oct. 2026.

[5] C. Yang, X. Zhao, T. Wu, and C. Kästner, “Better Harnesses, Smaller Models: Building 90% Cheaper Agents via Automated Harness Adaptation,” arXiv:2607.08938, Jul. 2026.

[6] T. Chen et al., “HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry,” arXiv:2606.14249, Jun. 2026.

[7] M. Zheng et al., “Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding Tasks,” arXiv:2606.12344, Jun. 2026.

[8] S. Kapoor et al., “Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation,” arXiv:2510.11977, Oct. 2025.

[9] I. Bondarenko and N. O. Nikitin, “When Harness Beats Scale, and When Reading Beats Both,” arXiv:2609.34366, Sep. 2026.

[10] T. Kwa et al., “Measuring AI Ability to Complete Long Software Tasks,” arXiv:2503.14499, Mar. 2025.

[11] T. Ord, “Is there a half-life for the success rates of AI agents?” arXiv:2505.05115, May 2025.

[12] S. Yao, N. Shinn, P. Razavi, and K. Narasimhan, “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains,” arXiv:2406.12045, Jun. 2024.

[13] H. Wang and T. Huang, “Mingbird: A Local-First Agent Harness Enabling Small Open Models to Complete Real Tasks,” arXiv:2610.02001, Oct. 2026.

[14] N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” arXiv:2307.03172, Jul. 2023.

[15] A. Sinha, A. Arun, S. Goel, S. Staab, and J. Geiping, “The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs,” arXiv:2509.09677, Sep. 2025.

[16] S. Mittal, “How Fast Do Agents Rot? An Empirical Study of Long-Horizon Degradation in LLM Agents for Production Decision-Making,” arXiv:2609.01660, Aug. 2026.

[17] X. Liu et al., “AgentBench: Evaluating LLMs as Agents,” arXiv:2308.03688, Aug. 2023.

[18] J. Jang, K. Yang, H. Lim, and H. Park, “Flat Score, Amplified Failures: How the Error Budget Masks Damage in Quantized LLM Agents,” arXiv:2607.27275, Jul. 2026.

[19] J. Ray, “The Constraint Tax: Measuring Validity-Correctness Tradeoffs in Structured Outputs for Small Language Models,” arXiv:2605.26128, May 2026.

[20] T. Gan and Q. Sun, “RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation,” arXiv:2505.03275, May 2025.

[21] L. Advani, “From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents,” arXiv:2606.09863, Jun. 2026.

[22] C. Bozoglan, Y. Gundogdu, A. Kaya, and K. Sirin, “What Stops a Small Language Model From Driving a Database Agent,” arXiv:2609.21341, Sep. 2026.

[23] A. Sethi, A. Kenzhebayev, S. Paturi, V. Raina, V. Raina, and I. Sheth, “Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return,” arXiv:2609.14758, Sep. 2026.

[24] S. Rahman et al., “Locating Hidden Failures Makes Long-Horizon Agents More Reliable,” arXiv:2609.17930, Sep. 2026.

[25] J. Li, “Where Does Exactly-Once Live? Model, Harness, and Tool-Contract Effects on Duplicate Side Effects in LLM Agents,” arXiv:2609.29095, Sep. 2026.

[26] J. Guo, H. M. Chen, K. Vaswani, A. Paverd, and P. Pietzuch, “Planarian: Managing Agent State with Statepoints,” arXiv:2609.35366, Sep. 2026.

[27] C. Zhang et al., “Judged Useless, Queried Anyway: Tool-Using Agents Rarely Turn Their Own Evidence Judgments into Stopping Decisions,” arXiv:2610.06191, Oct. 2026.

[28] R. Arike, E. Donoway, H. Bartsch, and M. Hobbhahn, “Technical Report: Evaluating Goal Drift in Language Model Agents,” arXiv:2505.02709, May 2025.

[29] L. Tang and Y. Zheng, “Measuring the Serving Stack Instead of the Model: Hidden Confounds in Local Tool-Use Evaluation,” arXiv:2609.26693, Sep. 2026.

[30] T. Han et al., “SWE-Skills-Bench: Do Agent Skills Actually Help in Real-World Software Engineering?” arXiv:2603.15401, Mar. 2026.

[31] J. Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering,” arXiv:2405.15793, May 2024.

[32] X. Yang, R. Chatterjee, H. Udupi, V. Ramavarapu, and C. Zhai, “Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files,” arXiv:2610.21073, Oct. 2026.

[33] Y. Lu, J. McAuley, and L. Zhang, “Pack Light, CarryOn: Building Object-Oriented Context for Long-Horizon Agents,” arXiv:2610.18784, Oct. 2026.

[34] S. Badhe, P. Tiwari, and J. Chung, “SKILL.state: Scalable Long-Horizon Agent Skills,” arXiv:2608.26263, Aug. 2026.

[35] Z. Li et al., “One Success Isn’t Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows,” arXiv:2608.19741, Aug. 2026.

[36] N. Agarwal and N. Jain, “FIRE: Failure-Informed Runtime Engineering for Reliable Language-Model Agents,” arXiv:2609.26048, Sep. 2026.

[37] Z. Ma et al., “LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks,” arXiv:2608.01964, Aug. 2026.

[38] R. Sanayei et al., “Evidence-First Agentic Verification,” arXiv:2610.17724, Oct. 2026.

[39] J. Wang, H. Qian, Y. Hu, J. Zhang, and Z. Liu, “AgentSWE: Can Coding Agents Build the Agent You Actually Want?” arXiv:2610.13361, Oct. 2026.

[40] Z. Zhang et al., “Rethinking Verification in Agent Harnesses,” arXiv:2610.34577, Oct. 2026.

[41] R. Kumar, W. Ali, J. Ahmed, N. I. Ali, and S. Usman, “AgentForge: Execution-Grounded Multi-Agent LLM Framework for Autonomous Software Engineering,” arXiv:2604.13120, Apr. 2026.

[42] G. Xu, R. Zhang, X. Wu, and H. Chen, “What Coding Agents Leave Unsaid: Measuring Task-State Gaps Between Execution and Reports,” arXiv:2610.20003, Oct. 2026.

[43] E. Gumaan, “Feedback That Backfires: Why Small Language Model Agents Repeat the Call They Just Watched Fail,” arXiv:2608.23651, Aug. 2026.

[44] S. Mittal et al., “Babysitting AI Agents: A User-Centered Taxonomy and Study of Agentic Delegation Failures,” arXiv:2610.34748, Oct. 2026.

[45] Y. Cao, S. Sathe, H. Wang, Z. Yin, F. Ma, and J. Chen, “Progress-Aware Distillation for Mitigating Stagnation in Small Language Model Agents,” arXiv:2610.19439, Oct. 2026.

[46] Y. Tian, B. Hu, H. Wang, B. Lu, and F. Wu, “Harness Evolution Hits a Ceiling: When Weight Training Should Begin,” arXiv:2610.11655, Oct. 2026.

[47] Z. Shi et al., “EdgeWise: Bringing Long-Horizon Agents to the Edge via Selective Cloud Delegation,” arXiv:2610.17560, Oct. 2026.

[48] Q. Wang et al., “LEASH: Uncertainty-Aware Weak-to-Strong Escalation and Oversight for Computer-Use Agents,” arXiv:2610.22280, Oct. 2026.

[49] A. Wang et al., “On the Clock: Towards Punctual and Productive Time-Budgeted AI Agents,” poster, Workshop on Resource-Aware Agentic AI, NeurIPS 2026. [Online]. Available: https://neurips.cc/virtual/2026/170689

[50] W. Xie, K. Feng, S. Fu, Y. Liu, X. Yue, and S. Zheng, “ReTerm: Recovery Training for Self-Improving Terminal Agents,” arXiv:2610.18484, Oct. 2026.

[51] Y. Qu et al., “Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks,” arXiv:2605.18583, May 2026.

[52] Z. Ji, Z. Li, W. Jiang, Y. Gao, and S. Wang, “Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code’s Auto Mode,” arXiv:2604.04978, Apr. 2026.

[53] Y. Ruan et al., “Identifying the Risks of LM Agents with an LM-Emulated Sandbox,” arXiv:2309.15817, Sep. 2023.

[54] D. X. Trong et al., “SWE-MISBEHAVIOR: Benchmarking and Mitigating Boundary Violations in Software Coding Agents,” arXiv:2610.18206, Oct. 2026.