Paper deep dive

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

Zhibang Yang, Xinke Jiang, Yuxuan Liu, Mingyu Zhang, Zhixin Zhang, Zhengxing Song, Yue Fang, Guohong Qiu, Ruiqing Li, Xu Chu, Junfeng Zhao, Yasha Wang

Year: 2026Venue: arXiv preprintArea: cs.MAType: PreprintEmbeddings: 87

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%

Last extracted: 9/30/2026, 6:26:19 AM

Summary

The paper introduces GitHarness, a pluggable Git-style framework designed to manage perpetual user requirements in LLM-based agents. It addresses the challenge of dynamic requirement changes (completion, elicitation, shift) by organizing requirement and work states into a branchable version history. A trainable Git Agent, optimized via black-box reinforcement learning, selects semantically compatible historical states to enable local updates, preserving valid work while excluding obsolete information. The authors also present MTAgentBench, a benchmark for evaluating these capabilities across multiple domains.

Entities (8)

GitHarness · framework · 98%Git Agent · model-component · 95%MTAgentBench · benchmark · 92%Requirement Completion · concept · 90%Requirement Elicitation · concept · 90%Requirement Shift · concept · 90%Reinforcement Learning · method · 88%GRPO · algorithm · 85%

Relation Signals (6)

GitHarness → uses → Git Agent

confidence 95% · A trainable Git Agent resolves requirement changes and selects a semantically compatible historical state.

Git Agent → trainedwith → Reinforcement Learning

confidence 92% · The Git Agent is trained through interface-level black-box reinforcement learning

GitHarness → evaluatedon → MTAgentBench

confidence 90% · We also construct MTAgentBench... Experiments demonstrate strong task performance

GitHarness → handles → Requirement Shift

confidence 88% · We address this gap by formulating dynamic-requirement collaboration... GitHarness... organizes requirement states... into a branchable version history.

GitHarness → handles → Requirement Completion

confidence 88% · The formulation covers requirement completion, elicitation, and shift

GitHarness → handles → Requirement Elicitation

confidence 88% · The formulation covers requirement completion, elicitation, and shift

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:LLM-based agents increasingly collaborate with users on long-horizon tasks, accumulating evidence, code, and drafts through extensive search, reasoning, and execution. As users inspect these results, they may supply missing information requirement completion, introduce new requirements requirement elicitation, or revise existing ones requirement shift. These changes often affect only part of the accumulated work, yet agents may carry forward obsolete information or turn local revisions into global rewrites. Existing approaches clarify current intent without determining how prior work should change, or reuse execution histories under a fixed objective. We address this gap by formulating dynamic-requirement collaboration as joint requirement tracking and local update. We introduce GitHarness, a pluggable Git-style framework that organizes requirement states and their corresponding harness work states into a branchable version history. A trainable Git Agent resolves requirement changes and selects a semantically compatible historical state. A unified version interface then restores that state and creates a new branch, enabling the underlying harness to exclude obsolete information, inherit compatible work, and focus execution on affected parts. The Git Agent is trained through interface-level black-box reinforcement learning, with downstream harnesses and task-execution models kept fixed. We also construct MTAgentBench, a verifier-preserving benchmark covering mathematical reasoning, text-to-SQL, agentic search, software engineering, and research synthesis. Experiments demonstrate strong task performance alongside effective requirement tracking, preservation of valid work, and efficient execution.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

84,164 characters extracted from source content.

Expand or collapse full text

GitHarness: Git Init Your Harness Working Memory for Perpetual User Requirements Zhibang Yang †thanks: Equal contribution. Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Email: yangzb@stu.pku.edu.cn Xinke Jiang11footnotemark: 1 Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Email: xinkejiang@stu.pku.edu.cn Yuxuan Liu11footnotemark: 1 Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Mingyu Zhang Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Zhixin Zhang Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Zhengxing Song Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Yue Fang Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Guohong Qiu Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Ruiqing Li Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Xu Chu †thanks: Corresponding authors. Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Affiliation: Center on Frontiers of Computing Studies, Peking University, Beijing, China Junfeng Zhao22footnotemark: 2 Affiliation: School of Computer Science, Peking University, Beijing, China Affiliation: Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing, China Yasha Wang22footnotemark: 2 Affiliation: National Engineering Research Center of Software Engineering, Peking University, Beijing, China Affiliation: Peking University Information Technology Institute (Tianjin Binhai), Tianjin, China Abstract LLM-based agents increasingly collaborate with users on long-horizon tasks, accumulating evidence, code, and drafts through extensive search, reasoning, and execution. As users inspect these results, they may supply missing information (requirement completion), introduce new requirements (requirement elicitation), or revise existing ones (requirement shift). These changes often affect only part of the accumulated work, yet agents may carry forward obsolete information or turn local revisions into global rewrites. Existing approaches clarify current intent without determining how prior work should change, or reuse execution histories under a fixed objective. We address this gap by formulating perpetual-requirement collaboration as joint requirement tracking and local update. We introduce GitHarness, a pluggable Git-style framework that organizes requirement states and their corresponding harness work states into a branchable version history. A trainable Git Agent resolves requirement changes and selects a semantically compatible historical state. A unified version interface then restores that state and creates a new branch, enabling the underlying harness to exclude obsolete information, inherit compatible work, and focus execution on affected parts. The Git Agent is trained through interface-level black-box reinforcement learning, with downstream harnesses and task-execution models kept fixed. We also construct MTAgentBench, a verifier-preserving benchmark covering mathematical reasoning, text-to-SQL, agentic search, software engineering, and research synthesis. Experiments demonstrate strong task performance alongside effective requirement tracking, preservation of valid work, and efficient execution. 1 Introduction LLM-based agents (Bubeck et al., 2023) can now carry out long-horizon tasks such as software engineering, open-world search, and deep research (Guo et al., 2025; Jaech et al., 2024; Jimenez et al., 2024; Zhou et al., 2024; Xiong et al., 2026; Du et al., 2025). During execution, they gather evidence, develop plans, invoke tools, and produce intermediate results such as code, queries, and report drafts. Yet users rarely provide a complete and immutable task specification at the outset. As they inspect intermediate results, they may supply missing task information (requirement completion), introduce new requirements inspired by the results (requirement elicitation), or revise, replace, or withdraw existing requirements (requirement shift) (Tack et al., 2026; Subramonyam et al., 2024; Lee et al., 2022; Faltings et al., 2023). Unlike conventional multi-turn chat (Lee et al., 2025), the context of long-horizon agent collaboration includes not just dialogue but also the results of extensive search, reasoning, and execution. Subsequent user feedback often targets only part of this accumulated work. An agent must track active requirements and reuse valid context and results. In practice, however, a request to fix a single bug may trigger changes to unrelated files across the workspace (Zhu et al., 2026), while a request to refine one visual detail may alter the entire image (Figure 1). A local revision can thus become a global rewrite, unnecessarily changing work that was already correct. This motivates our central research question: How can an agent harness adapt to changing user requirements while excluding obsolete information, preserving unaffected work, and updating only affected parts? Retaining the full history risks carrying forward obsolete requirements and results, whereas restarting from current requirements discards potentially reusable work. Existing methods address this trade-off only partially. ❶ Context retrieval, summarization, and intent reconstruction help clarify the current request (Dongre et al., 2025; Liu et al., 2026; Su et al., 2026), but do not directly determine how prior work should be reused, potentially requiring re-execution at substantial token and time cost. ❷ Trajectory organization, compression, and restoration support the reuse of intermediate work (Hu et al., 2025; Li et al., 2026; Hu et al., 2026; Zhuang et al., 2026), but typically assume a fixed task objective; when requirements change, superseded requirements and their associated results may continue to influence execution (Laban et al., 2026; Tack et al., 2026; Li et al., 2025). The missing link is an explicit connection between requirement changes and decisions about which prior work to preserve, discard, or recompute. Addressing this gap requires two linked decisions: where to resume—identifying the currently effective requirements and selecting a compatible historical state; and what to update—determining which parts of the prior work must change and which can be preserved. Version control offers a natural abstraction for these decisions. Git preserves versions through commits, supports branching from past states, and records local changes as diffs. This suggests a way to git init an agent’s working memory: organize requirements and their corresponding work as versioned states, and treat each new piece of feedback as a branch update from an appropriate historical state. Figure 1: When user feedback changes the umbrella color or removes a report section, reusing all prior work leaves stale content, while regenerating everything may alter unaffected parts. Selective updating limits changes to the affected work. To this end, we introduce GitHarness, a pluggable Git-style version-tracking framework that supports dynamic user requirements across diverse agent harnesses. It couples each effective requirement state with its corresponding work state in a branchable version history. A trainable Git Agent identifies effective requirements, interprets their changes, and locates a semantically compatible historical state, translating multi-turn feedback into explicit version transitions. GitHarness then restores the selected work state and creates a new branch, allowing the underlying harness to exclude obsolete states, inherit compatible work, and focus further execution on the affected parts. A unified version interface maps these operations onto the native work states of different harnesses without redesigning their working memory or execution procedures. We train the Git Agent through interface-level black-box reinforcement learning, using the correctness of requirement resolution, change interpretation, and historical-state localization as feedback while keeping the downstream harnesses and task-execution models fixed. Our contributions are threefold: • We formulate long-horizon agent collaboration under evolving requirements as a joint problem of requirement tracking and selective work reuse. The formulation covers requirement completion, elicitation, and shift, and connects changes in user requirements to decisions about where to resume execution and what to update. • We propose GitHarness, a pluggable framework that couples requirement states and work states in a branchable version history. A trainable Git Agent interprets requirement changes and selects compatible historical states, while a unified version interface supports restoration and continued execution across different harnesses without retraining the underlying task executors. • We construct MTAgentBench, covering mathematical reasoning, text-to-SQL, agentic search, software engineering, and research synthesis under diverse requirement-change trajectories. The dataset provides structured annotations of requirement states, version transitions, and task completion, together with an evaluation protocol for cross-task and compositional requirement changes. 2 Related Work Dynamic user requirement tracking. A user request may be disclosed, extended, or revised over several turns, making the latest utterance insufficient on its own. Existing methods maintain user-side history by appending previous turns, retrieving relevant dialogue (Zhang et al., 2025), summarizing context, rewriting conversational queries (Yuan et al., 2025), or modeling relations such as follow-up, correction, expansion, and recall (Li et al., 2025). Intent-mismatch methods further separate intent mediation from task execution (Liu et al., 2026), while U-Fold constructs an intent-aware dialogue summary and a task-relevant tool log for evolving user intent (Su et al., 2026). Despite these advances, models remain anchored to early assumptions under progressive disclosure and struggle with intent revelation, revision, and redirection (Laban et al., 2026; Tack et al., 2026). These approaches clarify current intent but do not determine how changes propagate to evidence, code, drafts, and other work produced under earlier requirements. Long-horizon agent work management. Long-horizon agents accumulate extensive traces and intermediate artifacts during planning and tool use. Memory methods organize, compress, or retrieve this execution-side history through stack operations, subgoal-based trajectories, active context editing, or state-adaptive recall (Jiang et al., 2025; Hu et al., 2025; Li et al., 2026; Hu et al., 2026). Recovery methods diagnose consequential failures or restore aligned agent and environment checkpoints (Qi et al., 2026; Ma et al., 2026; Zhuang et al., 2026). Related systems further introduce version-control abstractions: GCC manages context through commit, branch, merge, and retrieval (Wu et al., 2025), while GitOfThoughts stores reasoning trees as Git repositories (Shekar et al., 2026). These methods make prior execution easier to reuse, but select history according to the agent’s current reasoning state, an execution failure, or exploration needs under an otherwise given task. They therefore lack a requirement-driven mechanism for deciding which historical work state remains compatible when user feedback changes the task itself. In contrast, GitHarness uses requirement transitions to locate compatible historical states and decide what work to preserve, discard, or recompute. 3 Problem Formulation We study multi-turn tasks with evolving user requirements. At each turn t, the system maintains a requirement state i,t I_i,t (current goal and constraints) and a work state i,t W_i,t (execution context and accumulated artifacts). New feedback may change the goal and invalidate prior work. The central difficulty is that the agent cannot simply re-execute from scratch at each turn; it must identify what changed, retain valid prior work, and update only affected parts. Requirement changes. User feedback typically modifies an existing requirement rather than defining a task from scratch. We identify three directions of change, each formalized as an edit Δi,t I_i,t relative to a historical anchor state: • Completion: adds missing details consistent with the current direction. • Elicitation: introduces new task dimensions while preserving existing requirements. • Shift: revises or withdraws prior requirements, invalidating part of the existing state. The anchor need not be the most recent state—users may revisit earlier decisions or extend a historical branch. We instantiate nine fine-grained operators for data construction and evaluation; the method itself does not require change-type identification. Task definition. Given the accepted history ℋi,t−1H_i,t-1 and new feedback qi,tq_i,t, the system must (1) recover the full current requirement, (2) select a compatible historical base, and (3) update the work state locally: (^i,t,b^i,t,hi,t)=f⁡(qi,t,ℋi,t−1),^i,t=Fdi(i,b^i,t,^i,t,hi,t).( Q_i,t,\; b_i,t,\;h_i,t)\;=\;f\! (q_i,t,\;H_i,t-1 ), W_i,t\;=\;F_d_i\! ( W_i, b_i,t,\; Q_i,t,\;h_i,t ). (1) Here ^i,t Q_i,t is the resolved requirement, b^i,t b_i,t the selected base version, and hi,th_i,t an update hint for downstream execution. Rather than predicting which specific artifacts are affected, the system achieves locality through base selection and branch-local execution: resuming from a compatible prior state naturally confines edits to what the new requirement demands. For evaluation, each instance carries a final-task verifier and optional turn-level verifiers: si=Vdi(^i,Ti,i,Ti),si,t=V~i,t(^i,t,i,t,Δi,t).s_i^final\;=\;V^base_d_i\! ( Y_i,T_i,\; I_i,T_i ), \;s_i,t^step\;=\; V_i,t\! ( Y_i,t,\; I_i,t,\; I_i,t ). (2) We additionally report execution cost. 4 Method Figure 2: Framework of GitHarness. Flattening a growing interaction history into a single context obscures which prior states are reusable and makes selective rollback impossible. GitHarness addresses this by saving a version after each successful turn—a snapshot pairing the requirement with a recoverable checkpoint of the work state. Versions form a directed graph <tG_<t; any past version can be restored on demand via its checkpoint ℬ⁡(v)B(v). This structure supports continuation from the current head, rollback to an earlier version, and branching when requirements diverge. When feedback qtq_t arrives, GitHarness processes via: 1. Requirement resolution (§4.1): A Git Agent determines the full current requirement t Q_t and the best base version btb_t. 2. Branch execution (§4.2): The system restores the selected base and an update agent carries out targeted modifications. Separating these two concerns allows the Git Agent to focus purely on requirement understanding, while the update agent handles domain-specific execution. Formally: (t,bt,ht)=πθG(qt,<t),t=F⁡(bt,t,ht).( Q_t,\;b_t,\;h_t)\;=\; _θ^G\! (q_t,\;G_<t ), W_t\;=\;F\! ( W_b_t,\; Q_t,\;h_t ). (3) Only normally terminated results are committed as new versions; failed executions leave the graph unchanged. 4.1 Requirement Resolution The Git Agent must jointly determine the full requirement and the best historical base—two interdependent decisions that require reasoning over the version graph. A single-step classifier is insufficient: the agent may need to review what earlier versions achieved before deciding where to resume. It therefore runs a short ReAct loop with three actions: • Inspect: read a past version’s requirement, gathering context without making a decision. • Commit: declare the full current requirement and select a base version for runtime resolution. • Reuse: select a version that already satisfies the requirement, skipping further execution. At each reasoning step k: ak a_k ∼πθG(⋅∣qt,<t,η<k),ak∈Inspect,Commit,Reuse, \; _θ^G\! (· q_t,\;G_<t,\; _<k ), a_k∈ \Inspect,\;Commit,\;Reuse \, (4) ok o_k =Env⁡(<t,ak). =\;Env\! (G_<t,\;a_k ). A successful Commit or Reuse terminates the loop and returns the handoff ξt=(t,bt,vt,ht) _t=( Q_t,b_t,v_t,h_t), comprising the resolved requirement t Q_t, selected base btb_t, target version vtv_t, and non-authoritative update hint hth_t. Commit extends the main path when btb_t is the current head and creates a branch otherwise—branching is thus a natural by-product of base selection, not a separate action. 4.2 Branch Execution The Git Agent has determined what to achieve and where to start; the remaining question is how much work is actually needed. Three execution modes cover the full spectrum: zt=ExactReuse,ℬ(vt)≠⊥,FreshSolve,bt=∅orℬ(bt)=⊥,Rψ(t,bt),otherwise.z_t\;=\; casesExactReuse,&B(v_t)≠ ,\\[5.0pt] FreshSolve,&b_t= \;or\;B(b_t)= ,\\[5.0pt] R_ψ( Q_t,\; W_b_t),&otherwise. cases (5) ExactReuse applies when a past version already satisfies the requirement—its checkpoint is returned directly with no execution. FreshSolve starts from an empty workspace when no usable base exists. When a partially compatible base is available, the router RψR_ψ inspects a lightweight workspace manifest and chooses between FreshSolve and ReuseAndPatch; the latter forks the base checkpoint and applies targeted modifications, preserving unaffected work. For the two modes that require execution, the update agent initializes and then updates a candidate state: t 0=Empty⁡(),zt=FreshSolve,Fork⁡(bt),zt=ReuseAndPatch,~t=Execute⁡(t 0,t,ht). W_t^\,0\;=\; casesEmpty(),&z_t=FreshSolve,\\[4.0pt] Fork( W_b_t),&z_t=ReuseAndPatch, cases W_t\;=\;Execute\! ( W_t^\,0,\; Q_t,\;h_t ). (6) On normal termination the candidate is committed as a new version in the graph; on failure, the graph remains unchanged. Historical checkpoints are immutable, ensuring that failed executions never corrupt prior states. 4.3 Training with Harness RL Downstream quality depends on the Git Agent’s requirement and base selection: even a perfect update agent cannot recover from errors in either. We therefore train only πθG _θ^G via reinforcement learning, treating the update agent and domain harness as a fixed environment. We adopt Harness RL (Jiang et al., 2026) to extract trainable segments from structured rollouts. For rollout capture, a single rollout involves interleaved calls to the Git Agent and the update agent. Every Git Agent call is recorded as an interface call record ξn=(Xn,Yn,ℓn) _n=(X_n,Y_n, _n^roll)—tokenized input, sampled output, and per-token rollout log-probabilities. Between calls, the harness dispatches execution to the update agent and assembles resulting observations into the Git Agent’s next context. Only Git Agent calls are included in the training mask; all other calls contribute context but receive no gradient. Reward design. We combine a sparse outcome reward with a dense query-tracking reward, both attributed exclusively to Git Agent decisions. The outcome reward checks final-artifact correctness: Re=Vdi(^i,Ti,i,Ti).R^out_e\;=\;V^base_d_i\! ( Y_i,T_i,\; I_i,T_i ). (7) Because this signal cannot distinguish which turns contributed to success or failure, we introduce a turn-level query-tracking reward. At each turn t, an LLM-based judger JϕJ_φ scores whether the Git Agent faithfully tracks the user’s evolving intent: Re,t=Jϕ(^i,t,b^i,t,qi,t,i,t).R^track_e,t\;=\;J_φ\! ( Q_i,t,\; b_i,t,\;q_i,t,\; I_i,t ). (8) The judger evaluates three dimensions: requirement fidelity (no omission or hallucination), base optimality (maximum compatible reuse), and staleness exclusion (withdrawn requirements correctly removed). These dimensions align with the evaluation metrics in Section 3, closing the loop between training signal and evaluation protocol. Training objective. For each query we sample a group of K rollouts. Both reward components are group-normalized into advantages: AeA^out_e across the rollout group and An,tA^track_n,t across same-type decisions. The per-token advantage for Git Agent positions combines them as An,t=(1−λ)Ae⁡(n)+λAn,t.A_n,t\;=\;(1- _track)A^out_e(n)\;+\; _track\;A^track_n,t\,. (9) We optimize πθG _θ^G with a rollout-balanced variant of GRPO (Shao et al., 2024): ℒgrpo=−1K∑e=1K1|ℐe|∑(n,t)∈ℐemin(ρn,tAn,t,clip(ρn,t, 1−ϵ, 1+ϵ)An,t),L_grpo\;=\;-\, 1K _e=1^K 1 _e \! _(n,t)\,∈\,I_e\! \! ( _n,t\,A_n,t,\;\;clip\! ( _n,t,\;1-ε,\;1+ε )A_n,t ), (10) where ℐeI_e collects Git Agent output-token positions in rollout e and ρn,t=exp⁡(ℓn,t(θ)−ℓn,t) _n,t= \! ( _n,t(θ)- _n,t^roll ) is the importance ratio. The inner normalization by |ℐe| _e ensures that rollouts with richer version-resolution histories do not dominate the gradient update. 5 Experiments We evaluate GitHarness across five domains, two backbones, and three harnesses. We ask: RQ1: Does it improve performance and execution efficiency across models and harnesses? RQ2: Which components drive these gains? RQ3: Can interface-level RL improve the Git Agent, and how do training dynamics and reward balance affect adaptation? RQ4: Can non-parametric guidance distilled from prior inference improve performance without parameter updates? RQ5: Does GitHarness remain robust as interaction length and task concurrency increase? Table 1: Final-task performance across harnesses. Scores use each benchmark’s native metric. Best results are shown in bold, and second-best results are underlined. Qwen3-32B DeepSeek-V4-Flash Harness Cross-turn method Math SQL Search Code Research Math SQL Search Code Research TCRAG Native 72.0 53.0 1.0 3.0 25.02 74.0 69.0 34.0 56.0 42.54 + Restart 73.0 64.0 2.0 5.0 16.67 88.0 66.0 41.0 61.0 43.45 + U-Fold 67.0 38.0 7.0 9.0 14.46 68.0 71.0 14.0 59.0 45.72 + GCC 71.0 63.0 6.0 11.0 15.66 55.0 53.0 42.0 53.0 32.37 + GitHarness 89.0 70.0 8.0 19.0 38.45 93.0 80.0 56.0 62.0 46.65 + GitHarness-RL 84.0 64.0 7.0 13.0 38.02 79.0 77.0 47.0 60.0 44.78 StackPlanner Native 72.0 46.0 4.0 8.0 33.77 75.0 71.0 37.0 67.0 47.63 + Restart 80.0 66.0 3.0 16.0 19.50 76.0 72.0 45.0 68.0 46.83 + U-Fold 75.0 39.0 6.0 7.0 26.24 80.0 81.0 32.0 73.0 38.18 + GCC 62.0 61.0 11.0 10.0 21.04 61.0 56.0 46.0 66.0 41.45 + GitHarness 86.0 72.0 15.0 17.0 38.78 94.0 78.0 58.0 74.0 49.96 + GitHarness-RL 77.0 65.0 12.0 18.0 39.20 81.0 73.0 49.0 69.0 47.83 OpenHands Native 71.0 58.0 2.0 7.0 20.22 76.0 67.0 27.0 64.0 48.88 + Restart 72.0 43.0 3.0 10.0 18.20 72.0 64.0 39.0 65.0 49.76 + U-Fold 47.0 22.0 2.0 6.0 8.99 71.0 75.0 16.0 59.0 34.57 + GCC 81.0 77.0 10.0 11.0 13.32 62.0 63.0 38.0 65.0 39.01 + GitHarness 85.0 73.0 10.0 16.0 39.25 92.0 79.0 57.0 72.0 51.48 + GitHarness-RL 86.0 63.0 11.0 15.0 37.92 87.0 78.0 48.0 69.0 46.17 Figure 3: Performance versus token usage under StackPlanner with DeepSeek-V4-Flash. Bubble area denotes estimated API cost; lower right is better. 5.1 Experimental Setup Benchmarks. We extend five benchmarks into seven-turn interactions: GSM8K (Math; accuracy), BIRD (SQL; execution accuracy), BrowseComp-Plus (Search; answer accuracy), SWE-bench Verified (Code; resolved rate), and DeepResearch Bench (Research; RACE). Appendix C details the evaluation subsets, trajectory construction, and domain-specific protocols. Models and harnesses. For training-free GitHarness, Qwen3-32B (Yang et al., 2025) or DeepSeek-V4-Flash (DeepSeek-AI et al., 2026) serves as both the Git Agent and downstream task executor. For GitHarness-RL, the Git Agent is replaced by a LoRA-GRPO-trained Qwen3-8B, while downstream execution continues to use the model specified by the corresponding experimental setting. We evaluate these configurations with TCRAG (stack memory) (Jiang et al., 2025), StackPlanner (hierarchical multi-agent planning) (Zhang et al., 2026), and OpenHands (executable workspaces) (Wang et al., 2025). Appendix D provides additional details on the three harnesses. Baselines. We compare Native, Restart, U-Fold (Su et al., 2026), and GCC (Wu et al., 2025), representing native continuation, clean-workspace regeneration, intent-aware context folding, and Git-style context management, respectively. Appendix E details their implementations. 5.2 Main Results Table 1 compares methods within each fixed backbone–harness setting; absolute scores are not compared across harnesses because their tools and planning procedures differ. Overall Effectiveness (RQ1). Across two backbones, three agent harnesses, and five task domains (Table 1), GitHarness outperforms Native in all 30 settings and matches or exceeds the strongest competing baseline in 28, including 27 strict wins and one tie. The gains are especially pronounced on Search: with DeepSeek-V4-Flash, GitHarness improves over the strongest baseline by 14.0 points under TCRAG and 18.0 points under OpenHands. Consistency across Models and Harnesses (RQ1). Improvements over Native are observed with both backbones and all three harnesses. For example, with Qwen3-32B, GitHarness improves SQL by 26.0 points under StackPlanner and 15.0 points under OpenHands; with DeepSeek-V4-Flash, it improves Search by 22.0 points under TCRAG and 30.0 points under OpenHands. Performance and Execution Efficiency (RQ1). Compared with Native, GitHarness reduces average token usage by 35.8% on SQL, 54.5% on Search, 73.6% on Code, and 36.7% on Research while improving performance in all four domains (Figure 3 and Table 10). It also achieves both the best performance and the lowest token usage among all compared methods on Search, Code, and Research. This lower cost is consistent with reusing compatible work and limiting re-execution after local requirement changes. 5.3 Ablation and Analysis Component Ablation (RQ2). Table 2 shows that both requirement resolution and branch execution contribute to performance and efficiency. Removing historical version selection and falling back to latest-state resolution, which fixes the current head as the base instead of selecting an earlier version, reduces the Code resolved rate from 74.0 to 44.0 while increasing token usage from 1.29M to 4.51M; without Inspect, the resolved rate falls to 42.0 with 4.22M tokens. Disabling ReuseAndPatch lowers performance and increases token usage across all five domains, while disabling FreshSolve also degrades every task, including drops of 10.0 points on SQL and 11.0 points on Search. These results show the value of historical version selection and choosing the execution mode. Table 2: Inference-time ablations under StackPlanner with DeepSeek-V4-Flash. Each task reports its native performance metric and average total token usage (thousands). Math SQL Search Code Research Component Variant Acc.↑ Tok.↓ EX↑ Tok.↓ EM↑ Tok.↓ Res.↑ Tok.↓ RACE↑ Tok.↓ Full GitHarness 94.0 60.0 78.0 96.1 58.0 653.9 74.0 1291.4 49.96 1327.8 Requirement Resolution w/o Historical Version Selection 84.0 104.6 62.0 142.1 42.0 1892.6 44.0 4513.5 45.59 2299.6 w/o Inspect 82.0 97.6 70.0 123.4 44.0 1583.5 42.0 4215.4 43.50 2412.3 w/o Exact-State Reuse 88.0 107.8 76.0 130.3 54.0 963.3 63 2534.8 49.88 1360.6 Branch Execution w/o ReuseAndPatch 92.0 65.4 75.0 104.3 53.0 862.4 69.0 1531.4 46.63 1597.0 w/o FreshSolve 89.0 114.2 68.0 102.4 47.0 793.9 72.0 1032.5 42.56 1433.5 Figure 4: Harness RL adaptation with fixed downstream execution: (a) final-task performance on the held-out test set, (b) training reward, and (c) reward-weight sensitivity on the validation set. Table 3: Effect of skill injection under DeepSeek-V4-Flash. Parentheses report changes from the corresponding skill-free GitHarness. StackPlanner OpenHands Method Math SQL Search Code Research Math SQL Search Code Research GitHarness 94.0 78.0 58.0 74.0 49.96 92.0 79.0 57.0 72.0 51.48 GitHarness-Skills 95.0 (+1.0) 83.0 (+5.0) 58.0 (0.0) 75.0 (+1.0) 52.03 (+2.07) 94.0 (+2.0) 81.0 (+2.0) 58.0 (+1.0) 74.0 (+2.0) 53.60 (+2.12) Table 4: Long-horizon performance under StackPlanner with DeepSeek-V4-Flash. Math Research Method H=10H=10 H=15H=15 H=20H=20 H=25H=25 H=30H=30 H=10H=10 H=15H=15 H=20H=20 H=25H=25 H=30H=30 Native 73.0 72.0 69.0 63.0 62.0 42.92 41.57 37.86 35.39 34.53 Restart 71.0 71.0 67.0 61.0 59.0 41.05 40.08 39.14 35.88 27.70 U-Fold 82.0 83.0 81.0 79.0 78.0 37.53 37.13 35.41 33.52 34.16 GitHarness 92.0 90.0 87.0 85.0 84.0 49.53 49.27 48.71 47.52 47.32 Harness RL Adaptation (RQ3). Table 1 reports the frozen test performance of the RL-adapted Git Agent, with the same held-out test comparison shown in Figure 4(a) under StackPlanner. With the downstream executor fixed, Harness RL improves the Qwen3-8B Git Agent from 51.0 to 81.0 on Math and from 55.0 to 73.0 on SQL, yielding gains of 30.0 and 18.0 points. Although the remaining gap to the training-free DeepSeek Git Agent may partly reflect the smaller 8B policy capacity, the RL-adapted configuration still outperforms the Qwen3-32B configuration on four of five StackPlanner domains. Training Dynamics and Reward Balance (RQ3). Figure 4(b) reports the per-update training reward and its five-update moving average over 40 updates. Figure 4(c) compares query-reward weights on the 200-task validation set: compared with task-only training at λ=0λ=0 (47.0 Query Eq. and 70.0 Task Score), λ=0.2λ=0.2 improves both metrics. Increasing the weight to λ=1λ=1 raises Query Eq. slightly to 53.0 but reduces Task Score to 65.0, showing that overemphasizing requirement tracking can hurt downstream completion. This result motivates the balanced reward used in the final policy. Memory-Introduced Guidance (RQ4). In Table 3 and 11, we build a non-parametric guidance memory by distilling reusable strategies from multi-turn inference trajectories on separate source datasets and retrieve relevant guidance at test time. The memory is fixed and collected following SkillRL Xia et al. (2026) when training, and contains no evaluation instances, reference answers, or task-specific evidence; Search, Code, and Research provide no trajectories for its construction. Memory guidance improves 13 of 15 settings, including a 5.0-point gain on StackPlanner SQL and Research gains across all three harnesses, ranging from 2.07 to 4.27 points. These results show that experience accumulated during prior inference improves most of the evaluated settings, including held-out tasks, without parameter updates or test leakage. Performance under Long-Horizon Interleaving (RQ5). Table 4 evaluates 10–30-turn sessions interleaving two to four tasks. GitHarness ranks first at every horizon on both Math and Research. At H=30H=30, it exceeds the strongest baseline by 6.0 points on Math and 12.79 RACE points on Research. From H=10H=10 to H=30H=30, its Research score decreases by only 2.21 points, compared with at least 3.37 points for the baselines, demonstrating robustness to increasing interaction length and task concurrency. Construction details are provided in Appendix C. 6 Conclusion, Limitations and Future Work GitHarness presents a Git-style version-tracking framework for long-horizon agent collaboration under dynamic user requirements. Instead of mixing evolving requirements and accumulated work in a flat interaction history, GitHarness binds each effective requirement to its corresponding harness state and organizes them as a branchable version history. Given users’ new feedback, a Git Agent reconstructs the current requirement, locates a compatible historical state, and guides the underlying harness to preserve valid work, discard obsolete states, and update only the affected content. Across five task domains, two backbone models, and three agent harnesses, the training-free GitHarness configuration outperforms native cross-turn execution in all 30 settings and matches or exceeds the strongest competing baseline in 28 of 30 settings, including 14 of 15 settings under DeepSeek-V4-Flash. Moreover, after interface-level RL adaptation, the 8B Git Agent retains strong performance despite its smaller capacity, outperforming native cross-turn execution in 29 of 30 settings. For future work, GitHarness depends on accurate requirement interpretation and historical-state selection, which can be challenging under ambiguous or conflicting feedback. Restoring a compatible state also does not guarantee that the underlying agent preserves all unaffected work. Future work will explore uncertainty-aware clarification and finer-grained dependency tracking, and evaluate the framework in longer, real-world interactions. AI use statement Large language models were used for language polishing, literature discovery, synthetic trajectory construction, figure-design assistance, and AI-assisted programming. LLMs helped transform public benchmark tasks into multi-turn requirement trajectories and provided visual drafts, code suggestions, and debugging support. All generated data, figures, citations, and code were reviewed and verified by the authors, with benchmark verifiers and human inspection used to validate synthetic trajectories. The research questions, methodology, experimental design, analyses, and conclusions were determined by the authors. Ethics statement All experiments use publicly available benchmarks, including GSM8K, BIRD, BrowseComp-Plus, SWE-bench Verified, and DeepResearch Bench, under their respective licenses and terms. The study involves no human or animal subjects and uses no private conversations or personally identifiable information. The multi-turn interactions are generated from public benchmark tasks using author-designed construction protocols and LLM assistance, rather than collected from real users. Software-engineering tasks are executed in isolated benchmark environments to limit unintended effects on external systems. Reproducibility statement We will release the implementation of GitHarness, the constructed multi-turn trajectories, and the metadata required to reproduce their requirement transitions and verification. The appendix reports, prompts, model configurations, training settings, baseline implementations, and evaluation procedures. Evaluation scripts, LLM-judge configurations, and commands for reproducing the main results will be added to the anonymized repository at https://anonymous.4open.science/r/GitHarness-7A2E/. All experiments rely on publicly accessible benchmarks and model interfaces; no private data is required. References Bubeck et al. (2023) S. Bubeck, V. Chandrasekaran, R. Eldan, J. Gehrke, E. Horvitz, E. Kamar, P. Lee, Y. T. Lee, Y. Li, S. M. Lundberg, H. Nori, H. Palangi, M. T. Ribeiro, and Y. Zhang Sparks of artificial general intelligence: early experiments with GPT-4. CoRR abs/2303.12712. External Links: Link, Document, 2303.12712 Cited by: §1. Chen et al. (2025) Z. Chen, X. Ma, S. Zhuang, P. Nie, K. Zou, A. Liu, J. Green, K. Patel, R. Meng, M. Su, et al. Browsecomp-plus: a more fair and transparent evaluation benchmark of deep-research agent. arXiv preprint arXiv:2508.06600. Cited by: Appendix C. Cobbe et al. (2021) K. Cobbe, V. Kosaraju, M. Bavarian, M. Chen, H. Jun, L. Kaiser, M. Plappert, J. Tworek, J. Hilton, R. Nakano, C. Hesse, and J. Schulman Training verifiers to solve math word problems. External Links: 2110.14168, Link Cited by: Appendix C. DeepSeek-AI et al. (2026) DeepSeek-AI, A. Xu, B. Lin, B. Xue, B. Wang, B. Xu, B. Wu, B. Zhang, C. Lin, C. Dong, C. Ling, C. Lu, C. Zhao, C. Deng, C. Hou, C. Xu, C. Shao, C. Ruan, C. Sun, D. Dai, D. Guo, D. Yang, D. Chen, D. Li, D. Ji, E. Li, F. Wei, F. Lin, F. Yuan, F. Xia, F. Dai, G. Hao, G. Chen, G. Cao, G. Meng, G. Li, H. Yu, H. Zhang, H. Xu, H. Li, H. Liang, H. Zhang, H. Luo, H. Wei, H. Yuan, H. Zhang, H. Luo, H. Chen, H. Ji, H. Zhang, H. Ding, H. Tang, H. Cao, H. Gao, H. Qu, H. Zeng, J. Yang, J. Zhu, J. Luo, J. Song, J. Yu, J. Huang, J. Cai, J. Liang, J. Zhou, J. Ye, J. Li, J. Xu, J. Hu, J. Yang, J. Chen, J. Yan, J. Chen, J. Zhou, J. Xiang, J. Yuan, J. Cheng, J. Zhou, J. Zhu, J. Yu, J. Sun, J. Ran, J. Jiang, J. Qiu, J. Li, J. Zheng, J. Song, K. Dong, K. Gao, K. Guan, K. Zhou, K. Huang, K. Yu, L. Wang, L. Zhang, L. Wang, L. Xia, L. Zhang, L. Zhao, L. Guo, L. Luo, L. Ma, L. Zhu, L. Wang, L. Cai, L. Zhang, L. Chen, M. Di, M. Xu, M. Mei, M. Wang, M. Zhang, M. Zhang, M. Tang, M. Li, M. Zhou, M. Han, N. Wang, P. Huang, P. Wang, P. Cong, P. Wang, P. Zhang, Q. Wang, Q. Zhu, Q. Li, Q. Chen, Q. Du, Q. Jiang, R. Tian, R. Xu, R. Lu, R. Xu, R. Ge, R. Zhang, R. Pan, R. Wang, R. Chen, R. Yin, R. Xu, R. Shen, R. Zhang, R. Chen, S. Liu, S. Lu, S. Sun, S. Zhou, S. Chen, S. Cai, S. Nie, S. Wu, S. Chen, S. Hu, S. Liu, S. Hu, S. Ma, S. Wang, S. Yu, S. Zhou, S. Pan, S. Yu, S. Zhou, T. Ni, T. Yun, T. Jin, T. Pei, T. Ye, T. Lin, T. Ji, T. Cui, T. Yue, T. Yu, T. Wang, W. Zhang, W. Xiao, W. Zeng, W. An, W. Zhao, W. Liu, W. Liang, W. Pang, W. Luo, W. Yao, W. Gao, W. Yang, W. Huang, W. Hou, W. Zhang, W. Ma, X. Gao, X. He, X. Wang, X. Wang, X. Bi, X. Liu, X. Wang, X. Chen, X. Zhang, X. Nie, X. Sun, X. Wang, X. Cheng, X. Liu, X. Xie, X. Liu, X. Liu, X. Yu, X. Li, X. Yang, X. Zhang, X. Chen, X. Wang, X. Su, X. Chen, X. Lin, X. Fu, Y. Yan, Y. Wang, Y. Ma, Y. Luo, Y. Zhang, Y. Xu, Y. Ma, Y. Huang, Y. Li, Y. Li, Y. Xu, Y. Zhao, Y. Sun, Y. Wang, Y. Qian, Y. Shao, Y. Yu, Y. Zhang, Y. Ding, Y. Shi, Y. Wu, Y. Xiong, Y. Ma, Y. He, Y. Tang, Y. Zhou, Y. Luo, Y. Zhong, Y. Piao, Y. Wang, Y. Zhang, Y. Chen, Y. Tan, Y. Wei, Y. Ma, Y. Liu, Y. Yang, Y. Guo, Y. Wu, Y. Wu, Y. Li, Y. Cheng, Y. Ou, Y. Xu, Y. Li, Y. Wang, Y. Yang, Y. Xu, Y. Wu, Y. Meng, Y. Zou, Y. Zha, Y. Xiong, Y. Chen, Y. Lin, Y. Cao, Y. Wang, Y. Zhang, Y. Yan, Y. Lin, Y. Gu, Y. Luo, Y. You, Y. Liu, Y. Zhou, Y. Zhou, Y. Huang, Z. Wu, Z. Wang, Z. Zhao, Z. Ren, Z. Zhang, Z. Sha, Z. Fu, Z. Ju, Z. Xu, Z. Xie, Z. Zhang, Z. Gao, Z. Hao, Z. Gou, Z. Ma, Z. Yan, Z. Shao, Z. Huang, Z. Chen, Z. Wu, Z. Ren, Z. Wu, Z. Li, Z. Zhang, Z. Xu, Z. Wang, Z. Qu, Z. Gu, Z. Zhu, Z. Li, Z. Zhang, Z. Xie, Z. Gao, Z. Wan, Z. Pan, and Z. Yao DeepSeek-v4: towards highly efficient million-token context intelligence. External Links: 2606.19348, Link Cited by: §5.1. Dongre et al. (2025) V. Dongre, R. A. Rossi, V. D. Lai, D. S. Yoon, D. Hakkani-Tür, and T. Bui Drift no more? context equilibria in multi-turn llm interactions. arXiv preprint arXiv:2510.07777. Cited by: §1. Du et al. (2025) M. Du, B. Xu, C. Zhu, X. Wang, and Z. Mao Deepresearch bench: a comprehensive benchmark for deep research agents. arXiv preprint arXiv:2506.11763. Cited by: Appendix C, §1. Faltings et al. (2023) F. Faltings, M. Galley, K. Brantley, B. Peng, W. Cai, Y. Zhang, J. Gao, and W. B. Dolan Interactive text generation. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, p. 4450–4468. Cited by: §1. Guo et al. (2025) D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi, et al. Deepseek-r1: incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948. Cited by: §1. Hu et al. (2025) M. Hu, T. Chen, Q. Chen, Y. Mu, W. Shao, and P. Luo Hiagent: hierarchical working memory management for solving long-horizon agent tasks with large language model. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 32779–32798. Cited by: §1, §2. Hu et al. (2026) Y. Hu, H. Qian, S. Wang, J. Liu, Z. Zhao, J. Tan, Z. Liu, and Z. Dou SAM: state-adaptive memory for long-horizon reasoning agent. arXiv preprint arXiv:2605.24468. Cited by: §1, §2. Jaech et al. (2024) A. Jaech, A. Kalai, A. Lerer, A. Richardson, A. El-Kishky, A. Low, A. Helyar, A. Madry, A. Beutel, A. Carney, et al. Openai o1 system card. arXiv preprint arXiv:2412.16720. Cited by: §1. Jiang et al. (2025) X. Jiang, Y. Fang, R. Qiu, H. Zhang, Y. Xu, H. Chen, W. Zhang, R. Zhang, Y. Fang, X. Ma, X. Chu, J. Zhao, and Y. Wang TC-RAG: turing-complete rag’s case study on medical LLM systems. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2025, Vienna, Austria, July 27 - August 1, 2025, W. Che, J. Nabende, E. Shutova, and M. T. Pilehvar (Eds.), p. 11400–11426. External Links: Link, Document Cited by: Appendix D, §2, §5.1. Jiang et al. (2026) X. Jiang, Z. Zhang, Z. Yang, J. Gao, R. Qiu, S. Chen, X. Chu, J. Zhao, and Y. Wang Harness-rl: black-box reinforcement learning with action-args decoupling for central-agent multi-agent harnesses. arXiv preprint arXiv:2608.29641. Cited by: §4.3. Jimenez et al. (2024) C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan Swe-bench: can language models resolve real-world github issues?. In International Conference on Learning Representations, Vol. 2024, p. 54107–54157. Cited by: Appendix C, §1. Laban et al. (2026) P. Laban, H. Hayashi, Y. Zhou, and J. Neville Llms get lost in multi-turn conversation. In International Conference on Learning Representations, Vol. 2026, p. 54738–54778. Cited by: §1, §2. Lee et al. (2022) M. Lee, M. Srivastava, A. Hardy, J. Thickstun, E. Durmus, A. Paranjape, I. Gerard-Ursin, X. L. Li, F. Ladhak, F. Rong, et al. Evaluating human-language model interaction. arXiv preprint arXiv:2212.09746. Cited by: §1. Lee et al. (2025) Y. Lee, B. Lee, J. Zhang, Y. Hwang, B. Ko, H. Kim, D. Yao, X. Rong, E. Joo, S. Han, B. Ko, and H. Choi MultiVerse: a multi-turn conversation benchmark for evaluating large vision and language models. External Links: 2510.16641, Link Cited by: §1. Li et al. (2025) J. Li, J. Li, Y. Wang, Y. Chang, and Y. Wu Structflowbench: a structured flow benchmark for multi-turn instruction following. In Findings of the Association for Computational Linguistics: ACL 2025, p. 9322–9341. Cited by: §1, §2. Li et al. (2023) J. Li, B. Hui, G. Qu, J. Yang, B. Li, B. Li, B. Wang, B. Qin, R. Geng, N. Huo, et al. Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls. Advances in Neural Information Processing Systems 36, p. 42330–42357. Cited by: Appendix C. Li et al. (2026) M. Li, L. Xu, Q. Tan, L. Ma, H. Song, T. Cao, and Y. Liu Sculptor: empowering llms with cognitive agency via active context management. In International Conference on Learning Representations, Vol. 2026, p. 153411–153440. Cited by: §1, §2. Liu et al. (2026) G. Liu, F. Zhu, R. Feng, C. Ma, S. Wang, and G. Meng Intent mismatch causes llms to get lost in multi-turn conversation. External Links: 2602.07338, Link Cited by: §1, §2. Ma et al. (2026) M. Ma, J. Zhang, F. Yang, Y. Kang, Q. Lin, S. Rajmohan, and D. Zhang Dover: intervention-driven auto debugging for llm multi-agent systems. In International Conference on Learning Representations, Vol. 2026, p. 28059–28087. Cited by: §2. Qi et al. (2026) Y. Qi, Z. Yin, X. Shi, H. Peng, S. Lu, Y. Liu, R. Xuan, Y. Liu, Z. Hu, X. Wang, et al. TRAJDEBUG: tracing error lifecycle to identify critical failures in long-horizon agent trajectories. arXiv preprint arXiv:2608.06346. Cited by: §2. Shao et al. (2024) Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y. Li, Y. Wu, et al. Deepseekmath: pushing the limits of mathematical reasoning in open language models. arXiv preprint arXiv:2402.03300. Cited by: §4.3. Shekar et al. (2026) P. C. Shekar, A. H S, and A. Krishnan GitOfThoughts: version-controlled reasoning and agent memory you can replay, diff, and merge. arXiv preprint arXiv:2606.14470. Cited by: §2. Su et al. (2026) J. Su, R. Fang, Y. Li, X. Wang, S. Cai, P. Xie, N. Zhang, and F. Yuan U-fold: dynamic intent-aware context folding for user-centric agents. In Findings of the Association for Computational Linguistics: ACL 2026, p. 18043–18057. Cited by: Appendix E, §1, §2, §5.1. Subramonyam et al. (2024) H. Subramonyam, R. Pea, C. Pondoc, M. Agrawala, and C. Seifert Bridging the gulf of envisioning: cognitive challenges in prompt based interactions with llms. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems, p. 1–19. Cited by: §1. Tack et al. (2026) J. Tack, P. Laban, and J. Neville LLMs get lost in evolving user intent. arXiv preprint arXiv:2607.20734. Cited by: Appendix A, §1, §1, §2. Wang et al. (2025) X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, H. H. Tran, F. Li, R. Ma, M. Zheng, B. Qian, Y. Shao, N. Muennighoff, Y. Zhang, B. Hui, J. Lin, and et al. OpenHands: an open platform for AI software developers as generalist agents. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, External Links: Link Cited by: Appendix D, §5.1. Wu et al. (2025) J. Wu, M. Hu, J. Zhu, J. Pan, Y. Liu, M. Xu, and Y. Jin Git context controller: manage the context of llm-based agents like git. arXiv preprint arXiv:2508.00031. Cited by: Appendix E, §2, §5.1. Xia et al. (2026) P. Xia, J. Chen, H. Wang, J. Liu, K. Zeng, Y. Wang, S. Han, Y. Zhou, X. Zhao, H. Chen, Z. Zheng, C. Xie, and H. Yao SkillRL: evolving agents via recursive skill-augmented reinforcement learning. External Links: 2602.08234, Link Cited by: §5.3. Xiong et al. (2026) Z. Xiong, G. Wu, L. Yao, M. Pan, X. Du, and H. Wang WebWeaver: breaking topology confidentiality in LLM multi-agent systems with stealthy context-based inference. CoRR abs/2603.11132. External Links: Link, Document, 2603.11132 Cited by: §1. Yang et al. (2025) A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv, et al. Qwen3 technical report. arXiv preprint arXiv:2505.09388. Cited by: §5.1. Yuan et al. (2025) Y. Yuan, Z. Abbasiantaeb, M. Aliannejadi, and Y. Deng Query understanding in llm-based conversational information seeking. In Proceedings of the 48th International ACM SIGIR Conference on Research and Development in Information Retrieval, p. 4098–4101. Cited by: §2. Zhang et al. (2025) F. Zhang, D. Zhu, J. Ming, Y. Jin, D. Chai, L. Yang, H. Tian, Z. Fan, and K. Chen DH-rag: a dynamic historical context-powered retrieval-augmented generation method for multi-turn dialogue. External Links: 2502.13847, Link Cited by: §2. Zhang et al. (2026) R. Zhang, X. Jiang, Z. Yang, Z. Zhang, J. Gao, Y. Xiao, H. Lai, X. Chu, J. Zhao, and Y. Wang StackPlanner: a centralized hierarchical multi-agent system with task-experience memory management. arXiv preprint arXiv:2601.05890. Cited by: Appendix D, §5.1. Zhou et al. (2024) S. Zhou, F. F. Xu, H. Zhu, X. Zhou, R. Lo, A. Sridhar, X. Cheng, T. Ou, Y. Bisk, D. Fried, et al. Webarena: a realistic web environment for building autonomous agents. In International Conference on Learning Representations, Vol. 2024, p. 15585–15606. Cited by: §1. Zhu et al. (2026) T. Zhu, W. H. Lim, and M. Kan When models edit too much: on the fidelity of minimal code edits. External Links: 2609.04061, Link Cited by: §1. Zhuang et al. (2026) Y. Zhuang, K. Chen, Y. Duan, S. Zheng, J. Li, and X. Zhang AgentRewind: recoverable execution for long-horizon llm agents. arXiv preprint arXiv:2608.14380. Cited by: §1, §2. Appendix A Dataset Construction Table 5: Requirement operators used to construct multi-turn interactions. Operator labels are hidden from evaluated agents. Change type Operator Effect Completion Reveal Disclose previously unstated source-task information OutputControl Revise format, structure, length, or presentation Refine Request additional explanation, evidence, or detail Elicitation Constrain Add a newly formed executable constraint Comparison Add an object, method, metric, or comparison dimension Pivot Introduce a related function while retaining compatible context Shift ParameterUpdate Replace an active parameter or constraint value Correct Correct an active premise, goal, or requirement Withdraw Deactivate an active requirement Final-anchor construction. Following the retrospective construction of Tack et al. (2026), we use the source task and its verifier as the final anchor: i,Ti=isrc,Vi=Visrc, I_i,T_i= I_i^src, V_i=V_i^src, (11) We then construct plausible preceding states that lead to this anchor. Single-turn and multi-turn evaluation therefore share the same final objective and native verifier, isolating the effect of evolving requirements without new answer annotations. Requirement transition operators. We instantiate the three requirement-change directions in Section 3 with nine operators: Completion _Completion =Reveal,OutputControl,Refine, =\ Reveal, OutputControl, Refine\, Elicitation _Elicitation =Constrain,Comparison,Pivot, =\ Constrain, Comparison, Pivot\, Shift _Shift =ParameterUpdate,Correct,Withdraw. =\ ParameterUpdate, Correct, Withdraw\. (12) These hidden construction variables are distinct from the Git Agent’s Inspect, Commit, and Reuse actions and the update agent’s domain tools. Multi-turn interaction construction. Given the final anchor, we construct preceding requirement states and present them chronologically. At turn t, the constructor selects a historical anchor bi,tb_i,t, applies an operator oi,to_i,t, and realizes the change as natural-language feedback qi,tq_i,t: Δi,t=oi,t(i,bi,t),i,t=i,bi,t⊕Δi,t. I_i,t=o_i,t( I_i,b_i,t), I_i,t= I_i,b_i,t I_i,t. (13) Intermediate states may depart from the source task through a transient edit δ and later recover through a semantic compensating edit δ¯ δ: (⊕δ)⊕δ¯≡.( I δ) δ≡ I. (14) For example, Withdraw can remove a temporary OutputControl, while ParameterUpdate and Correct can restore parameters or premises. A trajectory is retained only if its terminal requirement is semantically equivalent to the source anchor. Construction labels, anchors, and reference states are used only for validation and reward computation and are hidden from evaluated agents. Appendix B Additional Method Details Inference procedure. Algorithm 1 summarizes requirement resolution, branch execution, and version commitment in GitHarness. Normal harness termination and runtime checks do not use the benchmark answer. The task verifier remains restricted to reward computation and offline evaluation. Algorithm 1 GitHarness inference. 1: Feedback qtq_t, version graph <tG_<t, checkpoint binding ℬB, and domain harness Γd _d 2: Updated work state t W_t or Failure 3: η←∅η← and ξt←⊥ _t← 4: repeat 5: ak∼πθG(⋅∣qt,<t,η)a_k _θ^G(· q_t,G_<t,η) 6: (ok,ξt)←EnvG⁡(<t,ak)(o_k, _t) _G(G_<t,a_k) 7: η←η⊕(ak,ok)η←η (a_k,o_k) 8: until ξt≠⊥ _t≠ 9: Unpack ξt=(t,bt,vt,ht) _t=( Q_t,b_t,v_t,h_t) 10: if ℬ(vt)≠⊥B(v_t)≠ then 11: return Restored⁡(ℬ⁡(vt))Restore_d(B(v_t)) 12: end if 13: if bt=∅b_t= or ℬ(bt)=⊥B(b_t)= then 14: zt←FreshSolvez_t← FreshSolve 15: else 16: zt←Rψ(t,bt)z_t← R_ψ( Q_t, W_b_t) 17: end if 18: if zt=FreshSolvez_t= FreshSolve then 19: ~t0←Emptyd⁡() W_t^0 _d() 20: else 21: ~t0←Forkd⁡(ℬ⁡(bt)) W_t^0 _d(B(b_t)) 22: end if 23: (st,~t)←Executed⁡(~t0,t,ht)(s_t, W_t) _d( W_t^0, Q_t,h_t) 24: if st≠Finisheds_t≠ Finished then 25: return Failure 26: end if 27: ct←PersistCheckpointd⁡(~t)c_t _d( W_t) 28: ℬ⁡(vt)←ctB(v_t)← c_t 29: return ~t W_t Update agent. For execution modes that require new work, the update agent operates only on an isolated candidate state. Its domain-specific action space is partitioned as dU=dinspect∪dtask∪dedit∪Finish,A_d^U=A_d^inspect _d^task _d^edit∪\ Finish\, (15) where inspect actions read recovered state, task actions invoke native domain tools, edit actions update candidate artifacts, and Finish requests normal termination. At update step j, ut,j∼πU(⋅∣t,ht,zt,~t,j,ζt,<j),(~t,j+1,ot,jU)=Envd(~t,j,ut,j),u_t,j π^U\! (· Q_t,h_t,z_t, W_t,j, _t,<j ), ( W_t,j+1,o^U_t,j)=Env_d( W_t,j,u_t,j), (16) where πUπ^U is the fixed update-agent policy and ζt,<j _t,<j is its within-execution action–observation history. Concrete tools, artifact representations, and stopping protocols remain domain specific. ReuseAndPatch denotes continued execution from a fork rather than a deterministic file patch, while FreshSolve and ReuseAndPatch are runtime initialization decisions rather than update-agent editing actions. Table 6: Semantic action classes available to the update agent. Class Generic operations Purpose Inspect Glob, Grep, Read Inspect files or recovered work units Task Domain tools Perform domain-specific task operations Edit Write, Patch, Delete Modify only the isolated candidate state Finish Finish Return the result and request runtime finalization Harness RL rollout extraction. An episode contains interleaved calls to the Git Agent, version runtime, update agent, and domain tools. For interface call n, we record ξe,n=(Xe,n,Ye,n,ℓe,nroll) _e,n=(X_e,n,Y_e,n, ^roll_e,n), where Xe,nX_e,n is the assembled context, Ye,nY_e,n the sampled response, and ℓe,nroll ^roll_e,n its rollout log-probabilities. The training mask is me,n,j=[ξe,nis a Git-Agent call and token j∈Ye,n],ℐe=(n,j):me,n,j=1.m_e,n,j=I\! [ _e,n\ is a Git-Agent call and token j∈ Y_e,n ], _e=\(n,j):m_e,n,j=1\. (17) Only positions in ℐeI_e contribute to the policy update. User, system, runtime, tool-observation, and update-agent tokens remain in the rollout context but receive no gradient. Episode rewards are assigned to the corresponding Git-Agent segments before group normalization and the GRPO update defined in Section 4.3. Appendix C Experiment Datasets We evaluate GitHarness on five benchmarks spanning mathematical reasoning, text-to-SQL generation, web search, software engineering, and deep research. Only Math and SQL provide training trajectories for RL adaptation; Search, Code, and Research are held out entirely from RL training and serve as out-of-domain transfer evaluations. The Math and SQL candidate pools contain 400 tasks in total: 200 are used for RL training and 200 are reserved for validation. Table 7 summarizes the task-disjoint training, validation, and test splits. ❶GSM8K (Cobbe et al., 2021) (Math). GSM8K contains 8.5K linguistically diverse grade-school math problems requiring multi-step arithmetic reasoning. From 200 candidate tasks, we use 100 for RL training and hold out 100 for validation; a separate 100-task test set is used for final evaluation. We evaluate the final answer using normalized exact-match accuracy, where extracted numerical answers are normalized before comparison with the gold answer. ❷BIRD (Li et al., 2023) (SQL). BIRD is a large-scale, database-grounded text-to-SQL benchmark containing 12,751 question–query pairs across 95 databases and 37 domains. From 200 candidate tasks, we use 100 for RL training and hold out 100 for validation; a separate 100-task test set is used for final evaluation. We report execution accuracy by executing the predicted and gold SQL queries on the same SQLite database and comparing their returned results; gold SQL and execution results remain evaluator-only. ❸BrowseComp-Plus (Chen et al., 2025) (Search). BrowseComp-Plus extends BrowseComp with a fixed, human-verified document corpus designed to provide controlled conditions for evaluating search agents. We use 100 queries and evaluate the final answers using normalized exact-match accuracy. Citation validity is additionally recorded as diagnostic information but is not used to determine the primary accuracy score. ❹SWE-bench Verified (Jimenez et al., 2024) (Code). SWE-bench Verified contains 500 human-validated software engineering tasks derived from real GitHub issues. We construct a fixed subset of 100 tasks and evaluate the resulting patches in isolated environments using the official SWE-bench evaluation harness, with the resolved outcome as the success criterion. ❺DeepResearch Bench (Du et al., 2025) (Research). DeepResearch Bench contains 100 PhD-level research tasks spanning 22 expert-curated domains, with 50 English and 50 Chinese queries. We use all 100 tasks and evaluate generated reports using RACE, which measures report quality against the benchmark’s reference reports under its predefined evaluation criteria. Table 7: Task-disjoint training, validation, and test subsets. Only the training trajectories are used for RL adaptation. Dataset RL Train Validation Test Lang. GSM8K 100 100 100 EN BIRD 100 100 100 EN BrowseComp-Plus 0 0 100 EN SWE-bench Verified 0 0 100 EN DeepResearch Bench 0 0 100 EN/ZH ❻Multi-turn interaction construction. For each source task, we construct a multi-turn interaction sequence using three controlled transition classes. Preserve retains the current goal and active requirements while revealing compatible information, changing presentation, or requesting further explanation. Extend keeps the current task active while adding a constraint, comparison dimension, or related task function. Revise corrects, replaces, withdraws, or restores an active requirement. By construction, the final effective query is semantically equivalent to the original source task, allowing the final artifact to be evaluated with the benchmark’s original evaluator. ❼Interleaved long-horizon conversations. To evaluate multi-requirement tracking and cross-task interference, we compose multiple task-disjoint seven-turn interaction sequences into a single conversation with H∈10,15,20,25,30H∈\10,15,20,25,30\ user turns. The conversation interleaves two to four active tasks, and each turn may update one task or jointly update several tasks. When needed to reach the target length, we insert continuation or progress-check requests (e.g., “continue working” or “report the current progress”) that leave the active requirements unchanged. Hidden task states and transition labels remain unavailable to the agent. The final turn requests the outputs of all active tasks, which are verified separately using their benchmark-specific evaluators and then macro-averaged. Appendix D Harness and Adapter Details We evaluate all methods with three agent harnesses: TC-RAG, StackPlanner, and OpenHands. Each harness retains its native reasoning and tool-use procedure, while a lightweight adapter connects it to the corresponding benchmark interface. ❶TC-RAG. TC-RAG Jiang et al. (2025) employs a memory-stack mechanism for adaptive retrieval, reasoning, and planning. Through Push and Pop operations, it manages intermediate states, controls the retrieval process, and mitigates the accumulation of erroneous knowledge. ❷StackPlanner. StackPlanner Zhang et al. (2026) is a centralized hierarchical multi-agent framework that decouples high-level coordination from subtask execution. It employs active task-level memory control and structured experience memory to support long-horizon coordination and the reuse of prior coordination experience. ❸OpenHands. OpenHands (Wang et al., 2025) is a general-purpose platform for developing AI agents that interact with their environment by writing code, operating through a command line, and browsing the web. It also provides sandboxed environments for safe code execution. Appendix E Baseline Implementation Details We compare GitHarness with four baselines that adopt different strategies for cross-turn context management: native state retention, context reconstruction, context compression, and versioned context management. ❶Native. Native directly relies on the conversational state and workspace maintained by the underlying task harness, without introducing any additional cross-turn context-management module. Information from previous turns is therefore retained only through the harness’s native state mechanism. ❷Restart. Restart reconstructs the accumulated user requirements at each turn into a self-contained query and executes it in a fresh harness session with a clean workspace. Previous reasoning traces and intermediate artifacts are discarded, so each turn is solved independently based on the reconstructed requirement. ❸U-Fold. U-Fold (Su et al., 2026) retains the full user–agent dialogue and tool-call history while constructing a compact working context at each turn. It maintains an intent-aware, evolving dialogue summary together with a compact, task-relevant tool log, which are used to support the current interaction. ❹GCC. GCC (Wu et al., 2025) organizes agent context as a version-controlled persistent file system. It provides four explicit operations—COMMIT, BRANCH, MERGE, and CONTEXT—to checkpoint progress, explore alternative reasoning paths, integrate branch states, and retrieve historical context at different levels of granularity. Appendix F Implementation Details Domain-specific execution environments. We instantiate the downstream update agent with the capabilities required by each benchmark while leaving requirement resolution unchanged. Table 8 summarizes the model-visible tools, persistent work products, and final verification for each domain. Within each backbone–harness block, all compared methods use the same downstream model, task inputs, model-visible tools, execution budget, and verifier. Across all domains, gold annotations, hidden evaluation resources, and verifier feedback remain evaluator-only; method-specific persistent state remains part of the system being evaluated. Table 8: Domain-specific tools and persistent work products. Domain Model-visible tools and constraints Persistent work products Math Deterministic calculator and scoped workspace read/write/patch operations answer.md and calculation evidence SQL SQL generation from the public schema and BIRD evidence; no database access during inference answer.sql Search Read-only BrowseComp retrieval returning top-5 passages with 512-token snippets answer.json and runtime-recorded retrieval evidence Research Bounded read-only BoCha web search report.md, report outline, and runtime-recorded retrieval evidence Code Repository inspection, editing, shell execution, and repository-local test execution in an isolated workspace; no access to hidden tests Repository patch Reinforcement-learning adaptation. We train only the Qwen3-8B Git Agent with LoRA GRPO. During RL training, the fixed downstream executor and query-equivalence judge use DeepSeek-V4-Flash, and all non-Git-Agent components remain frozen. Each optimizer update contains four prompt groups, with two Math and two SQL cases, and samples eight independent rollouts per group. Advantages are normalized only among rollouts generated from the same prompt. The terminal episode score is assigned to every trainable Git-Agent segment in that episode, while tokens produced by the runtime, downstream executor, tools, and verifiers are excluded from the loss. The selected checkpoint is trained for 40 updates, corresponding to 160 prompt groups and 1,280 sampled episodes. The reward weight λ=0.2λ=0.2 is selected on the 200-task validation set described in Appendix C. Table 9 reports the complete training configuration. Long-horizon finalization. When the final message requests outputs for several active tasks, the experiment scheduler extracts one task-local request for each referenced task and invokes the same GitHarness procedure independently on its version history and workspace. Each invocation produces one terminal Commit or Reuse, after which the scheduler aggregates the task outputs into one response. Thus, a global final message may trigger several task-local terminal actions without changing the single-handoff semantics of GitHarness. Table 9: LoRA-GRPO training configuration for the Git Agent. Parameter Value Parameter Value Models and execution Trainable policy Qwen3-8B Git Agent Downstream executor model DeepSeek-V4-Flash Query-equivalence judge DeepSeek-V4-Flash Adaptation LoRA Git-Agent tool steps 4 Downstream tool steps 16 Git-Agent context / response limit 16,384 / 4,096 tokens Downstream response limit 4,096 tokens Sampling Updates 40 Checkpoint interval Every update Prompt groups/update 4 (2 Math + 2 SQL) Rollouts/group 8 Sampled episodes 1,280 Temperature / top-p 0.8 / 1.0 Optimization LoRA rank / alpha 16 / 32 LoRA dropout 0 Target modules Q/K/V/O and MLP projections Precision bfloat16 Optimizer AdamW Learning rate 2×10−62× 10^-6 Adam betas / weight decay (0.9,0.95)(0.9,0.95) / 0 Schedule Constant GRPO clip range 0.1 Maximum gradient norm 1.0 Base-policy KL coefficient 0.01 Query-reward weight λ 0.2 Appendix G Additional Experiments ❶Efficiency and Cost Details. Figures 5 and 6 complement the main-text efficiency analysis. The former reports the Math and Code token–performance trade-offs omitted from Figure 3 for readability, while the latter compares estimated API cost across all five domains. We aggregate all model calls over each seven-turn interaction and average over completed samples. GitHarness achieves the lowest token usage and estimated cost on Search, Code, and Research; Math and SQL exhibit task-dependent trade-offs. Table 10 provides the corresponding numerical results. Figure 5: Performance versus token usage on Math and Code under StackPlanner with DeepSeek-V4-Flash. Bubble area denotes estimated API cost; lower right is better. Figure 6: Performance versus estimated API cost across five domains under StackPlanner with DeepSeek-V4-Flash. Bubble area denotes average token usage; lower right is better. Table 10: Detailed token usage (thousands) and API cost (USD) under StackPlanner with DeepSeek-V4-Flash. Math SQL Search Code Research Method Tokens Cost Tokens Cost Tokens Cost Tokens Cost Tokens Cost Native 43.13 0.03 149.68 0.09 1,438.03 0.77 4,900.13 2.28 2,095.92 1.11 Restart 26.82 0.02 137.39 0.08 874.40 0.47 3,649.91 1.69 1,483.71 0.79 U-Fold 54.09 0.04 89.79 0.05 669.87 0.36 2,266.16 1.05 1,742.79 0.92 GCC 53.05 0.04 142.29 0.08 1,536.62 0.82 2,034.28 0.94 1,604.36 0.85 GitHarness 59.98 0.04 96.10 0.06 653.87 0.35 1,291.43 0.63 1,327.77 0.70 Figure 7: Requirement-resolution actions across all domains and branch-execution strategies for SQL and Search. Figure 8: Branch-execution strategies for Math, Code, and Research. Table 11: Effect of skill injection with TCRAG under DeepSeek-V4-Flash. Method Math SQL Search Code Research GitHarness 93.0 80.0 56.0 62.0 46.65 GitHarness-Skills 96.0 (+3.0) 81.0 (+1.0) 55.0 (-1.0) 63.0 (+1.0) 50.92 (+4.27) ❷Decision Behavior Analysis. Figures 7 and 8 show that GitHarnessdoes not collapse to a single resolution action or execution strategy. During requirement resolution, the Git Agent most frequently selects Commit in Math, SQL, Search, and Research, whereas Code more often reuses an existing requirement version; Inspect is particularly common in Code and Research. During branch execution, FreshSolve is most frequent in Math and SQL, ReuseAndPatch dominates Research and is common in Search, and ExactReuse dominates Code. These domain-dependent patterns show that GitHarness adapts both its historical-version selection and downstream execution strategy to the current update. ❸Additional Skill-Injection Results. Table 11 complements the main analysis with results under TCRAG, a harness based on stack-structured task memory. Skill injection improves four of the five domains, including gains of 3.03.0 points on Math and 4.274.27 points on Research. Together with the StackPlanner and OpenHands results in Table 3, these results show that reusable version-decision experience transfers across harnesses with different state-management mechanisms. Appendix H Computational Resources and Software Environment Compute. Most inference experiments ran on a shared Ubuntu 22.04.5 LTS server with two Intel Xeon Platinum 8358 CPUs, 1007 GiB of RAM, and eight NVIDIA A800-SXM4-80GB GPUs. Harness-RL training was conducted separately on one NVIDIA H800 GPU. Model serving. Qwen3-32B was served through an OpenAI-compatible vLLM 0.19.0 endpoint using two A800 GPUs, tensor parallelism of 2, bfloat16 precision, and a 61,440-token context limit. DeepSeek experiments used the official deepseek-v4-flash API with its default thinking configuration (enabled with high reasoning effort) and a 1M-token context window. All cross-turn methods within a backbone–harness–task cell used the same reasoning configuration, generation limits, and agent-step budget. Task environments. BIRD predictions were executed against the benchmark’s local SQLite databases and scored by execution accuracy. BrowseComp-Plus used its fixed 100,195-document corpus with Qwen3-Embedding-8B and FAISS retrieval on GPU; each search returned five passages truncated to 512 tokens. SWE-bench Verified instances ran in dedicated Docker 29.1.3 containers and were graded with the official harness. Research reports were evaluated with the official DeepResearch Bench pipeline, using GPT-5.5 for RACE. Cost accounting. We report model-token cost per completed sample using peak cache-miss pricing from September 14, 2026: $0.44 per million input tokens and $1.32 per million output tokens. Appendix I Prompt Templates Table 12: Values used for the domain-specific semantic-check placeholder. Domain Additional semantic check Math Preserve the mathematical goal, givens, variables, units, relationships, active constraints, and requested output. SQL Preserve the database question, requested columns or aggregation, filters, grouping, ordering, limits, comparisons, and aliases. Treat fixed schema and SQL transport wrappers as harness context. Search Preserve the information need, entities, disambiguating clues, time range, requested answer granularity, and evidence or citation requirements. Research Preserve the research question, scope, subjects, time and region bounds, requested synthesis, deliverable structure, evidence, and citation requirements. Do not reduce the task to short-answer search. Code Preserve the software issue goal, repository-scoped entities, affected symbols or files, reproduction and failure behavior, expected behavior, version constraints, requested change scope, and active testing or output requirements. This section presents the core prompts used by GitHarness. Because some prompts are lengthy, we omit repeated low-level instructions and examples for presentation; the released code provides the complete prompts used in all experiments. I.1 Requirement Resolution The Git Agent uses the following prompt to convert each user turn into a complete resolved requirement and to choose among Inspect, Commit, and Reuse. The box is an abridged presentation rather than a verbatim serialization; the implementation terms state_forest and resolved_query correspond to the paper’s version graph and resolved requirement, respectively. Git Agent Requirement-Resolution Prompt (Abridged) You track the user’s current requirement state over a version graph. Use only the provided version-graph tools. Do not answer or execute the task. Critical update procedure: 1. Unless current_request explicitly withdraws or restores content, use active_state.resolved_query as the mandatory source. Edits are cumulative. Do not inspect or base an ordinary correction on an ancestor; reuse an ancestor only when its complete requirement exactly matches the desired requirement. 2. Treat entities, attributes, numbers, relationships, filters, projections, and outcomes as semantic slots. Replace every stale occurrence of a corrected slot, including evidence and question wording; preserve other slots and their required dependencies. Never leave conflicting values for one slot. Steps 3–4, the context-schema explanation, repeated validation rules, formatting sanitization, and illustrative examples are omitted here for space. 5. Before Commit or Reuse, verify the latest requested outcome and output specification, the latest slot values and dependencies, all unmentioned active requirements, and the absence of withdrawn content. If any check fails, do not issue a terminal action. Every resolved_query must be the complete, self-contained current requirement, never a delta such as “change X and keep everything else.” Content fidelity has priority over brevity. Silently distinguish the stable requirement core, persistent updates, temporary constraints, and presentation requirements such as precision, tables, or output format. Apply this decision priority: explicit withdrawal or restoration, explicit goal change, persistent local edit, temporary addition, and exact no-op. A higher-priority instruction overrides lower-priority preservation rules. For an ordinary local edit, apply only the requested change to the active resolved requirement and preserve every unmentioned requirement-bearing clause. For an explicit goal change, rebuild the complete requirement around the new requested outcome while retaining accepted facts needed for that outcome and dropping content that served only the previous goal. Detailed rules for comparison construction, restoration-scope edge cases, formatting sanitization, and illustrative examples are omitted here for space. For explicit withdrawal or restoration, use the version index and parent links to identify the historical version immediately preceding the withdrawn content, inspect that candidate, and replay only later edits that remain active. If the desired requirement exactly matches an inspected version, call reuse_resolved_state; otherwise call commit_resolved_query with the appropriate base version. commit_resolved_query and reuse_resolved_state are terminal on success. Runtime input: current_request, active_state, and history_index. Output: Return exactly one structured tool call. Inspection is non-terminal; commit and reuse are terminal. Fields marked optional may be omitted, and no additional fields are allowed. inspect_state_forest "tree_id":"<string, optional>", "state_id":"<string, optional>" commit_resolved_query "base_state_id":"<string or null>", "resolved_query":"<complete requirement>", "summary":"<short change summary>" reuse_resolved_state "state_id":"<string>", "summary":"<short reuse summary>" I.2 Downstream Execution Routing When a verified workspace is available, the following prompt decides whether the downstream executor should solve from scratch, reuse and patch the workspace, or inspect it before deciding. The change_hint is a non-authoritative summary generated by the Git Agent from model-visible interaction history; it contains no evaluator reference, gold answer, or gold edit. Downstream Execution Router Prompt You choose how the downstream executor should complete a new resolved task when a verified base workspace is available. Use exactly one routing tool per response. The current_resolved_task is authoritative. The base_resolved_task describes what the existing workspace was built for. change_hint is only a hint, never a deterministic patch. Prefer correctness over reuse. Consider recomputation cost, validation cost, stale-work risk, and how much verified work remains applicable. • select_fresh_solve: independently solve the complete current task. Prefer this when recomputation is cheap, inherited reasoning is risky, or checking old work costs as much as rebuilding it. Short calculations are often safer to recompute. • select_reuse_and_patch: fork the verified base workspace and update only what the complete current task requires. Prefer this when valuable reports, research, evidence, code structure, style, or interfaces would be expensive to recreate. Set preserve_base_calculations=true only when verified base calculations are supplied and every supplied calculation remains required and unchanged. It may be true when the task adds new calculations, but must be false if any base calculation is replaced, withdrawn, stale, or no longer required. • inspect_base_workspace: read one relevant file before deciding. Inspect only when the task comparison and manifest are insufficient. After inspection, select a final strategy. If uncertainty remains, call select_fresh_solve. These are considerations, not fixed domain rules. Do not choose reuse merely because a base exists. Do not output Runtime IDs, patches, verification claims, or an answer to the underlying task. A final strategy tool call ends routing. Runtime input: current_resolved_task, base_resolved_task, change_hint, and the base-workspace manifest. Output: Return exactly one structured tool call per response. Inspection is non-terminal and must be followed by a selection call; either selection call is terminal. Fields marked optional may be omitted, and no additional fields are allowed. inspect_base_workspace "path":"<string>", "offset":<integer ≥0≥ 0, optional>, "limit":<integer in [1,12000], optional>, "reason":"<string>" select_fresh_solve "reason":"<non-empty string>" select_reuse_and_patch "reason":"<non-empty string>", "preserve_base_calculations":<true or false> I.3 Workspace Execution The following shared suffix governs how the downstream executor reads and updates the selected workspace. Domain-specific prefixes define the available tools, artifact schema, and completion conditions and are provided separately. Shared Workspace Method-Selection Suffix Treat current_resolved_task as the complete current task specification. Choose the working method yourself before acting. Do not read prior workspace content merely because it exists. First decide whether the task is self-contained and cheap to complete independently. For a small math problem, short question, or small generation task, solve directly from current_resolved_task without inspecting prior output. Read prior files only when the task depends on valuable accumulated work such as existing code structure, report content, references, style, or interfaces that would be wasteful or unsafe to recreate. For a localized change to such work, inspect only relevant files and patch the smallest necessary region. For a structural change, use existing files as reference and rewrite only affected artifacts. If existing work already satisfies the task, finish without editing. Do not report this choice as Runtime metadata; express it through your tool actions. Runtime input: current_resolved_task, the selected workspace, its manifest, and any domain-specific execution context. Output: Return exactly one available structured tool call per response. The shared workspace calls are shown below; a domain may restrict paths or add a task tool such as calculate or browsecomp_search. No additional fields are allowed. glob_workspace "pattern":"<string>" grep_workspace "pattern":"<string>", "paths":<array of strings, optional> read_workspace "path":"<string>", "offset":<integer ≥0≥ 0, optional>, "limit":<integer in [1,50000], optional> write_workspace "path":"<string>", "content":"<string>" patch_workspace "path":"<string>", "replacements":["old_text":"<string>", "new_text":"<string>"] delete_workspace "path":"<string>" finish_work_memory "final_response":"<string>" I.4 Evaluation Prompt The following frozen prompt is used only to evaluate whether the final resolved query expresses the same complete task as the hidden reference. It is not shown to the Git Agent and does not generate the downstream task answer. At runtime, domain_specific_semantic_check is filled from Table 12. Query-Equivalence Judge Prompt Judge whether PREDICTION and REFERENCE express the same complete current task. Account for the requested goal, all active facts, constraints, comparisons, output requirements, withdrawals, and replacements. Judge semantic effect rather than textual minimality. Equivalent paraphrases are correct. Extra accepted background is allowed only when it is non-conflicting and cannot change the requested goal, answer, scope, or active constraints. Do not apply this allowance to stale or withdrawn clauses, or to facts that could affect the answer or scope. Missing active clauses, retaining material stale or withdrawn clauses, changing values, or introducing contradictions are not equivalent. Ignore differences in purely decorative step-by-step or boxed-answer wrappers; enforce explicit structured-output fields, precision, and task constraints. Domain-specific semantic check: domain_specific_semantic_check Input (JSON): "prediction": "candidate_resolved_query", "reference": "hidden_reference" Output: Return exactly one judge_query_equivalence tool call. "equivalent": <true or false>, "error_type": "<none | missing | stale | contradictory | different_goal>" Do not solve the task.

Instant research discovery