StateHarness: Maintaining Evolving Project State for Long-Horizon Coding Agents

Chuan Zou; Yujun Zhou; Xiaonan Luo; Xiangliang Zhang

cs.SEOct 13, 2026

StateHarness: Maintaining Evolving Project State for Long-Horizon Coding Agents

Authors: Chuan Zou, Yujun Zhou, Xiaonan Luo, Xiangliang Zhang

Organizations: University of Pennsylvania · University of Notre Dame

Abstract

Long-horizon coding requires agents to maintain an evolving view of the project they are changing: what problem is currently being solved, what has already been learned or modified, which other artifacts may be affected, and what work remains unresolved. When this information is scattered across a growing interaction history, local edits can become disconnected from their later consequences and progress can be difficult to carry forward. We introduce StateHarness, a runtime framework that maintains evolving project state without updating model parameters. The working agent records its current problem and hypothesis, important findings and decisions, discovered repository relationships, and unfinished work. Runtime support prompts record updates, searches for callers, tests, and documentation that may be affected by a change, and maintains a compact working brief for subsequent decisions. When behavioral signals accumulate, a separate diagnostic session revisits the recorded history and surfaces overlooked evidence. Across three repository-level evaluations, StateHarness improves task completion and several measures of change consistency. On RefactorBench, full-chain completion increases from 29.4% to 35.3% and cleanup-check accuracy from 87.0% to 95.4%. On five LHTB software-engineering tasks, mean reward improves from 0.427 to 0.576, exceeding LongHorizon-Harness at substantially lower recorded execution cost. On ChainSWE, bug-fix rate increases from 35.1% to 39.5% and residual debt decreases from 60 to 43 items, although pass-to-pass regressions increase. These results show that maintaining project state can improve long-horizon coding while introducing measurable execution and regression trade-offs.

Figures & tables

Figure 1: Maintaining evolving project state as coding progresses. StateHarness preserves what the agent has learned, records code changes and potentially related files, and tracks what has been completed and what still requires attention. These records support reviewing change consequences and continuing unfinished work.

Figure 2: StateHarness overview. The working agent maintains persistent project records, from which fixed rules refresh a compact working brief. Change-impact retrieval identifies candidate files for inspection when supported edits may have non-local consequences. Accumulated behavioral signals can trigger a separate diagnostic session that revisits older recorded evidence and returns concise suggestions through the brief.

RefactorBench
	Completion		Checks		Cleanup Breakdown
Method	Subtasks	Chains	Refactor	Cleanup	Imports	Calls	Docs
	$\uparrow$	$\uparrow$	$\uparrow$	$\uparrow$	$\uparrow$	$\uparrow$	$\uparrow$
Claude Code	77.9	29.4	94.6	87.0	82.7	93.3	90.9
StateHarness	81.4	35.3	95.9	95.4	94.4	93.3	100.0
Long-Horizon Terminal-Bench (LHTB)

Table 1: Overall performance across the three evaluation settings. Higher is better for completion, reward, and bug-fix rate; lower is better for P2P regressions and residual debt. Best results are shown in bold.

Figure 3: RefactorBench consistency breakdown. StateHarness produces a modest improvement on checks for the requested refactoring itself, while larger gains appear in cleanup checks for related artifacts. The largest improvements occur for import and documentation updates; call-site performance is unchanged.

Setting	Method	Recorded tokens (K)	Tool calls	Time (s)
RefactorBench	Claude Code	25.6	81	383
RefactorBench	StateHarness	33.1	110	529
ChainSWE	Claude Code	24.9	75	300
	StateHarness	35.3	96	383
	LongHorizon-Harness	208.0	272	2214

Table 2: Execution cost across evaluation settings. Values are averages under the corresponding setting. Lower is better for all cost measures.

Figure 4: Regression checking changes the repair trajectory. Both agents identify the same root cause and initially make broad changes to shared parsing behavior. Claude Code stops after the targeted tests pass. StateHarness performs additional regression checking, detects a failure in a previously passing Databricks test, and narrows the repair to the JSON-path parser.

Appendix figures & tables5 assets

Supplementary material from the paper’s appendix.

Appendix

Record	What changes during the task	Stored representation
Task state	Record the initial observation and environment; replace the current focus when the active subproblem or hypothesis changes.	task_state.md
Event log	Append important changes, tests, findings, decisions, and rejected assumptions together with their reasons.	breakthrough_log.md
Relation notes	Record discovered relationships to callers, tests, documentation, configuration, or schemas.	file_relation_graph.md
Procedure guidance	Maintain a named procedure’s invocation history, latest observed failure, usage policy, and rationale.	skill_states.json
Working brief	Refresh the current focus, relevant procedure guidance, recent events, and diagnostic alerts returned to the working agent.	context_brief.md

Appendix

Table 3: Persistent representations of task-relevant project state. The working agent authors the first four records; the working brief is a selective view returned to subsequent decisions.

Observed condition	Response and state change
Missing command-completion events	At the next shell call, count a missing normal completion callback. Three such events produce a signal and reset the streak; a normal shell completion clears the streak.
Repeated reads of one path	Three counted reads produce a signal and reset that path’s count. A proposed edit to the path clears the count before the edit outcome is known.
Working brief neglected for 25 calls	Deliver the brief and restart the window. Add diagnostic score only when no non-state edit or recognized test was proposed during that window. Recognized brief access restarts the window.
Recognized test completion	Clear diagnostic score and diagnostic alerts on the normal post-event, without parsing whether the test passed. A proposed test alone does not perform this reset.
Recognized progress tag	Synchronization clears the diagnostic score and alerts when the latest event indicates recognized progress, such as a passed test or an established root cause.
Successful nonblank diagnosis	Replace diagnostic alerts, clear diagnostic score and the brief-neglect count, start a 15-call cooldown, and return the updated brief.

Appendix

Table 4: Default feedback and diagnostic transitions. Unmentioned counters retain their current values. Test completions and recognized progress tags act as progress proxies.

Function	Recorded project state	Subsequent use
Preserve understanding	Retrieval identifies the service, CLI, test, and README as potentially affected by the loader signature change. The event log records that the loader and service have been updated, while relation notes preserve the remaining caller and documentation relationships.	The discovered scope remains available after the immediate edit, including the still-unchecked CLI caller.
Return current state	The current focus becomes “Checking loader.py ; I suspect encoding is still handled incorrectly.” Recent modification and decision events are copied into the working brief together with relevant procedure guidance.	Subsequent model requests receive the active hypothesis and recent progress without rereading the full project history.
Update after changes	Further edits push the earlier CLI decision outside the recent-event window, but the decision remains in the full event log. Later state records show that the loader and service have been updated while the CLI still requires review.	The compact working view follows recent work, while older project evidence remains recoverable from persistent state.
Recover overlooked evidence	Repeated reads of loader.py raise diagnostic score to the diagnostic threshold. Diagnosis revisits the full event log and surfaces the deferred CLI inspection as overlooked evidence.	The alert returns the CLI to the current working view. After the CLI is updated and the relevant regression test passes, the new result is recorded and ordinary execution continues.

Appendix

Table 5: One change through the four StateHarness functions. The example shows how project understanding is recorded, returned to current work, updated after code changes, and later recovered when relevant evidence falls out of the recent working view.

Component	Claude Code	StateHarness
Persistent project records	No	Yes
Working-brief synchronization	No	Yes
Recording reminders and behavioral signals	No	Yes
Repository change-impact retrieval	No	Yes
On-demand diagnostic session	No	Yes
Record-structure and history checks	No	Yes

Appendix

Table 6: Runtime components in the ordinary-agent and StateHarness configurations. The working model and task input are matched within each comparison.

Material	Delivery	Role
Working-agent startup instructions	Included in the initial request	Provide environment information, identify the project-state directory, request initialization and completion checks, and specify when the working agent should update project records.
Initialization and completion protocols	Explicitly requested reads	Establish the initial task observation and current focus, and later request review of recorded relationships, unresolved warnings, and relevant tests before termination.
Procedure-guidance lifecycle	Available as protocol files	Specifies how repeated procedure failures can produce use , verify , avoid , or freeze guidance. These files are not independently injected on every procedure failure.
Record templates and maintenance protocols	Available as supporting files	Define the persistent record formats and additional maintenance behavior. The working records are initialized from these templates rather than requiring the agent to reread the templates during ordinary execution.
Diagnostic instructions	Supplied directly to a fresh diagnostic session	Request evidence-backed identification of overlooked information or unproductive execution patterns using the triggering signal, task state, procedure guidance, full event log, and current working brief.

Appendix

Table 7: Instruction delivery in the StateHarness integration. Availability indicates that a file can be accessed by the agent; explicit delivery indicates that its contents or a request to read it enter the execution directly.

Software Engineering Agents

Software Engineering Agents are AI systems that use code, tools, and feedback to perform software development tasks.

See all 338 papers

StateTape: Action-Conditioned Evidence Lifecycle Modeling for Long-Horizon Coding Agents
Sep 28, 2026Ziyang Yu, Liang Zhao, Bowen Zhu +1AI Coding Agents LLM Agent Memory
Causal Dynamics Lab · Emory University
MemTrace: State-Consistent Memory for Long-Horizon Coding Agents
Oct 4, 2026Hongming Xu, Le Zhou, ZhongHe Jin +5Agent Memory Agent Memory Management
Shanghai Jiao Tong University · MemTensor (Shanghai) Technology Co., Ltd. · Theseus Lab
GitHarness: Git Init Your Harness Working Memory for Perpetual User Requirements
Sep 29, 2026Zhibang Yang, Xinke Jiang, Yuxuan Liu +9LLM Agent Memory Long-Horizon LLM Agents
National Engineering Research Center of Software Engineering, Peking University, Beijing, China · School of Computer Science, Peking University, Beijing, China · Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China +2

Sep 28, 2026J/K move · Enter open · S save

StateTape: Action-Conditioned Evidence Lifecycle Modeling for Long-Horizon Coding Agents

Ziyang Yu, Liang Zhao, Bowen Zhu, Hasibul Haque

Causal Dynamics Lab · Emory University

AI Coding Agents LLM Agent Memory Long-Horizon Agent Evaluation Graph-Based Agent Memory Agent Memory Management

Open paper AskPDF arXiv

Despite the recent success of coding agents built on large language models, it remains challenging to run them over long horizons, since every observation is appended to the context and the context grows with each one. History-based maintenance is a common remedy, which masks or summarizes old observations, or prunes what a model reads as useless, and bounds the context at little cost. However, it decides from the text of the history alone and sees nothing of how the code is connected. Since a coding agent edits code many times over a single task, and each write can change what code elsewhere means, such maintenance may keep records a write has falsified, drop ones that still hold, and miss code the agent needs next. To overcome these challenges, this paper proposes StateTape, a novel and scalable framework that rewrites a coding agent's context as the repository changes rather than as the context grows. The key idea of StateTape is to model the repository as a symbol-level code graph, whose dependencies and language rules expose which symbols a write can affect. Upon this graph, a tape marks the symbols each write changed, which turns staleness from an inference about text into an observation of the agent's writes. We propose a per-write procedure in which the tape nominates the records a write could have falsified while a small manager model settles what the write log cannot, and further provide a theoretical analysis and TraceBench, a benchmark that labels what an agent is holding against what is actually needed. Empirically, we demonstrate that StateTape can effectively clear falsified records and retrieve what is needed, and thus achieve a higher resolve rate in all experiments spanned by six coding agents and three edit-heavy benchmarks with little computational overhead.

Abstract

Software Engineering Agents

Explore similar work

StateTape: Action-Conditioned Evidence Lifecycle Modeling for Long-Horizon Coding Agents

MemTrace: State-Consistent Memory for Long-Horizon Coding Agents

GitHarness: Git Init Your Harness Working Memory for Perpetual User Requirements