Can AI Agents Adapt When the World Changes?

Abstract

Autonomous AI agents increasingly operate inside repositories, tool ecosystems, and computer workflows that do not remain fixed while work is in progress. Another developer may edit the code, a service may rotate credentials, a request may change, or a tool may become unavailable after the agent has already formed a plan. In these conditions, a correct action for an earlier state may be an incorrect or destructive action for the present one. This research perspective examines the gap between task completion in stable environments and safe adaptation under mid-task state changes. It synthesizes work on tool-using agents, stateful benchmarks, concurrent user participation, and controlled perturbations, including recent studies directly testing agent responsiveness and coding-agent counter-edits. We propose the State-Shift Evaluation Protocol (SSEP): a paired, executable study design that records an initial task state, introduces a controlled and independently verified transition at a decision-relevant point, captures the agent's response, and scores both task success and preservation of legitimate intervening work. We define shift classes, outcome metrics, proposed hypotheses, a sample study design, verifier controls, and validity limitations. SSEP is a research proposal, not an implemented benchmark or report of new measured results. Its aim is to make one practical question testable: when the world changes during a task, does an agent update its behavior without compromising the work it was meant to protect?

Keywords AI agents; dynamic environments; concurrent edits; state drift; evaluation; safe reconciliation; executable benchmarks; robustness.

1. The bug is not where you left it

A coding agent is asked to repair a failing payment adapter. It reads the repository, identifies an outdated interface, and prepares a patch. While the agent is examining tests, a teammate modifies the same adapter to preserve a new business rule. The agent then writes its originally planned patch. The repository compiles; the visible failure disappears; the teammate's correction is lost. This scenario is illustrative, not a documented incident. It shows how a task can appear solved while the agent has operated on an outdated picture of the world.

The same pattern extends beyond code. A support agent may approve a request using an earlier account status. A terminal agent may restart a service after its configuration has been replaced. A computer-use agent may submit a form just after a new message changes the necessary attachments. In each case the hazard is not merely that the agent lacks information. The agent may possess information that used to be correct and fail to recognize that its decision depends on a state which no longer exists.

A large context window can preserve observations; additional planning can improve deliberation; retries can repair some mistakes. None of these mechanisms, by themselves, guarantees that the relevant preconditions still hold at execution time. The research question is therefore operational: can an agent detect or accommodate intervening changes, and complete the legitimate task while respecting the current state?

This article makes a deliberately bounded contribution. It does not introduce a trained agent, claim a novel theorem about concurrency, or report an empirical win. It proposes a research design for evaluating state-shift resilience across several task families, inspired by existing evidence that agents can struggle when tools, requirements, or shared workspaces change mid-episode [7-10].

2. What counts as a changing environment?

Let S(t) denote the environment state at time t, O(t) an observation returned to the agent, and A(t) an agent action. An observation normally reveals only part of S(t). An external transition U may change the state between a relevant observation and the action that relies on it. The problem is not that S(t) changes at all: routine tool calls already modify environments. The problem is that a change is driven by another actor or external process, has consequences for the agent's current plan, and may not be directly announced.

A mid-task state shift is a documented external transition S0 -> S1 that occurs after an agent begins work and before it finishes. It may affect code, configuration, service availability, data records, task requirements, permissions, or incoming messages. This definition excludes changes performed by the evaluated agent itself, although those changes are still part of the observed trajectory.

2.1 Four distinctions that matter

First, a shift can be benign, relevant, or conflicting. A comment-only edit does not demand the same response as a changed API signature. Second, it may be announced in a trusted channel, visible only through inspection, or initially unobservable. Third, a shift may be reversible or irreversible. Fourth, the agent may have authority to reconcile it, or it may need to stop and request clarification. Evaluation must make these distinctions explicit rather than reward an agent for overriding every unexpected change.

An important separation is between detection and authorization. An agent can correctly notice a user edit yet lack permission to discard it. Conversely, an agent that asks before a high-impact overwrite may behave appropriately even if it does not autonomously complete the entire workflow. The evaluator should score these outcomes in accordance with the task contract rather than assuming that maximum autonomy is always preferable.

3. What the research already establishes

3.1 Interactive agents and benchmark foundations

ReAct helped formalize the interleaving of reasoning and action, while Reflexion examined how verbal feedback can influence future agent attempts [1, 2]. These approaches emphasize the role of observations and feedback in agent behavior. They do not themselves establish that a workflow remains safe when an unrelated actor changes the world between two observations.

SWE-bench introduced repository-level evaluation grounded in real GitHub issues, and OSWorld established executable evaluation of agents working inside real computer environments [3, 4]. Both moved the field beyond static answer matching. ToolSandbox subsequently made state dependencies and intermediate milestones central to tool-use evaluation [5]. These are important foundations for the present proposal: an agent's correctness must be assessed against an environment, not only against the plausibility of its final message.

The tau-bench line adds policy-constrained tool-agent-user interaction; its successor, tau²-bench, studies dual-control environments in which a user and an agent can both take actions that affect shared state [6, 7]. This makes collaborative state evolution an explicit part of evaluation, particularly in service workflows.

3.2 Evidence directly about state changes

SWE-Touch, released as a 2026 preprint, investigates plausible user-authored Counter-Edits inserted into coding-agent repair trajectories. Its authors report an average reduction of 7.7 percentage points in resolve rate across the tested coding models on SWE-bench Verified. Their analyses associate failures with inadequate awareness or reconciliation of edits in a shared workspace. The result is specific to their protocol, models, and tasks; it should not be generalized as an expected degradation for every agent or repository [8].

Balyan and Sharma's October 2026 Scientific Reports study injects controlled tool denial, goal modification, and constraint changes into synthetic environments and measures responsiveness under announced and silent conditions. It shows that adaptation is sensitive to architecture and perturbation type; an explicit notice did not improve mean reward for any architecture in their tested design. These results justify measuring response and recovery separately from endpoint completion, while leaving open how the findings transfer to realistic repository and service states [9].

The OSWorld 2.0 preprint likewise identifies mid-workflow information arrival and dynamic environments as consequential features of long-horizon computer use. It goes beyond narrow one-step operations by evaluating complex, multi-application tasks, including incoming messages that change what the agent needs to do. Its specific tasks and scores should not be mistaken for a direct estimate of software-concurrency robustness [10].

3.3 The narrower research opportunity

These studies mean that mid-task changes are already an active research area. The gap proposed here is not to discover that change exists. It is to establish a cross-domain evaluation contract that jointly checks change-aware behavior, authorized reconciliation, preservation of external work, and durable task completion. A benchmark can observe successful final states and still miss overwritten edits, or observe correct caution and wrongly mark it as failure when clarification was the authorized action.

4. Failure modes between observation and action

The central risk is a mismatch between the state an action assumes and the state on which it executes. The following categories are analytical failure modes proposed for environment authoring; they are not measured prevalence estimates.

A crucial subtlety is that the first read may have been entirely accurate. The defect arises in using that read outside the period for which it supports an action. This resembles the familiar time-of-check/time-of-use problem in systems engineering, but the agent setting adds uncertain observations, natural-language reasoning, and policies that may change with the task.

Likewise, not every repeated read is useful. Re-reading an irrelevant file is overhead; re-checking a current authorization setting immediately before a destructive change may be essential. The point of evaluation is to test whether verification is selective and correctly tied to the action's preconditions.

5. A taxonomy of state shifts

A credible test collection should vary the properties of the change rather than rely on one dramatic interruption. The table below defines authoring dimensions that can be sampled, paired, and audited independently.

A useful negative control is a benign shift near the same decision boundary as a conflicting shift. Without it, an agent can improve its apparent safety score by stopping after any unexpected change. The control tests whether the agent distinguishes risk instead of merely avoiding work.

6. Safe adaptation is more than noticing a change

We propose four behavioral requirements for sound adaptation. The agent should (i) obtain or refresh relevant evidence, (ii) recognize what in its plan the evidence affects, (iii) choose an action authorized for the new state, and (iv) verify both the intended outcome and the protected state afterward. These requirements can be realized through different architectures; they are evaluation criteria, not a mandatory chain-of-thought template.

6.1 Revalidation at decision boundaries

For an action whose correctness depends on current state, the agent may need to check a version marker, inspect a diff, query current service health, or read a recent message. The important condition is that the check bears on the impending action. A ritualistic full re-scan before every command can waste resources without reducing meaningful risk.

6.2 Reconciliation rather than erasure

A conflicting edit does not always represent a malicious or incorrect user. It may encode a new requirement. A successful agent can preserve both intentions through a compatible patch, or identify that a conflict cannot be resolved from available information. An unauthorized overwrite should remain a failure even if it restores the original visible test.

6.3 Appropriate deferral

Some states create a genuinely under-specified choice. If the user changed a transaction threshold without describing the new intended behavior, the best supported action may be to ask. These cases require a separate, explicitly labeled correct-deferral outcome; they must not be conflated with completed-task success in the primary experimental analysis.

7. The State-Shift Evaluation Protocol

The State-Shift Evaluation Protocol (SSEP) is a proposed design for a paired, reproducible agent study. Its novelty claim is limited to this organization of controls and outcome checks for the question at hand. It does not claim to invent stateful evaluation, concurrent edits, or perturbation testing; those have established precedents [5, 7-10].

7.1 Stage 1: specify the original contract

Freeze an initial environment S0, the task instruction, allowed operations, immutable protected assets, and a set of valid outcomes. Establish at least one reference path showing the baseline task is solvable. The protected-state contract must describe not only what the agent should change but also which unrelated or later changes it must preserve.

7.2 Stage 2: introduce one controlled transition

Define an external transition U with an exact precondition, payload, and post-state S1. Apply it through the environment controller rather than through the evaluated agent. Triggering can be event-based - for example, after the agent has read a target file but before its next write - provided the rule is predeclared and instrumented. A trial whose trigger does not fire must be recorded as such rather than silently dropped.

7.3 Stage 3: observe the agent's response

Record tool inputs and outputs, state-version observations, relevant file diffs, permission checks, user questions, subsequent actions, and final artifacts. The evaluation should prefer observable behavior over uninspectable claims about what the model internally "noticed." A proposed study can classify post-shift behavior by meaningful inspection, reconciliation attempt, safe deferral, or unsafe modification.

7.4 Stage 4: verify independent outcomes

After the rollout, an evaluator outside the agent's control checks functional correctness against the applicable task contract and separately checks preservation, constraints, and durability. The reference grader must not be editable by the agent. The verifier should reject superficially green results obtained by disabling tests, bypassing policies, or reverting legitimate external changes [11].

7.5 Stage 5: compare matched conditions

Compare each original task to matched shifted conditions. The primary outcome is not simply whether an agent continued acting, but whether it reached an authorized, functionally correct, state-preserving final outcome. Report untriggered episodes, excluded infrastructure failures, and uncertainty across task seeds separately from agent failures.

8. Authoring task changes that teach us something

Realism without control invites ambiguous conclusions; control without realism invites benchmark artifacts. SSEP proposes three environment families: repository maintenance, service/terminal operations, and structured computer-use workflows. Each family can support the same external-transition specification while retaining domain-specific verification.

An environment author should document why the shift is consequential, why the task remains solvable or appropriately deferrable, and which alternate correct responses must pass. Arbitrary edits that happen to be difficult may test distraction or tool brittleness rather than adaptability.

Before release, a separate reviewer should validate that the transition does not reveal the solution, corrupt the environment irreparably, or make the target behavior logically impossible. A reference response should be checked in both the baseline and shifted conditions; a no-operation baseline should fail when genuine work is required. For tasks where the permitted response is escalation, the verifier must encode the required evidence and stop condition rather than merely detecting a final file.

9. Worked example: a migration during a repair

Consider a small repository with a failing test for API response parsing. The initial task is to update a consumer after a schema migration. The agent reads an adapter and plans to change a field name. At a recorded boundary, an external collaborator changes the same adapter to preserve a newly required null-handling rule. This second change is legitimate, task-relevant, and intentionally conflicts with a naive search-and-replace patch.

The grading distinction is important. A patch that makes the original test green but deletes the new null-handling rule fails the preservation requirement. An agent that detects the edit and then produces a compatible implementation can pass. If the teammate's change is genuinely ambiguous, a scoped clarification may be appropriate, but this belongs in a separately scored deferral stratum rather than the primary completion rate.

To distinguish adaptation from accidental success, a matched benign condition can change nearby comments or nonfunctional metadata at the same time. An agent that performs expensive full-repository recovery for both variants may remain safe but inefficient; one that ignores both may be efficient but unsafe. Reporting only final pass/fail would miss this trade-off.

10. Research questions and a proposed study

SSEP is designed around falsifiable questions that can be tested without assuming an advantage for any particular model or prompting strategy. The study described below is a proposal for future implementation; the quantities are planning parameters, not data already collected.

10.1 Preregisterable hypotheses

H1 - Change sensitivity. Averaged over the preregistered configurations and task seeds, silent conflicting shifts will lower strict joint-success probability relative to paired static controls.

H2 - The notice effect. Announced conflicting shifts will increase the proportion of relevant post-shift state checks relative to silent conflicting shifts, without necessarily improving strict joint success. The outcome remains a testable prediction, not an assumed benefit [9].

H3 - Preservation versus completion. Under conflicting shifts, final functional pass rate will exceed joint functional-and-preservation pass rate when unsafe overwrites are possible.

H4 - Selective revalidation. In a separately specified intervention ablation, a version-aware pre-write check will reduce unsafe overwrites on conflicting shifts while increasing median tool calls on benign shifts. This ablation is additional to the 3,600 main-study trials.

10.2 Proposed sample and conditions

A pilot could begin with 60 independently reviewed task seeds: 20 repository tasks, 20 service/terminal tasks, and 20 computer-use workflows. Each seed would be executed under five conditions: static control, benign silent shift, benign announced shift, conflicting silent shift, and conflicting announced shift. Testing three fully specified model-agent configurations with four independent repetitions would produce 60 x 5 x 3 x 4 = 3,600 planned trials, before exclusions and any replacement of invalid infrastructure runs. This is a worked design choice, not a statistical power guarantee.

For the primary causal comparison, the transition rule, tools, time budget, prompt, and outcome contract would be frozen across a task's paired conditions. Randomize condition order and scheduling where the runner permits, and use a fixed suite of agent setups. Differences attributable to provider version, tool policy, or memory availability must be documented as configuration differences rather than explained away as pure model capability.

10.3 Event timing and operational fairness

Use a predeclared trigger tied to a meaningful event, such as the first successful read of a target artifact or the start of a planned write operation. Log the trigger condition and whether it fired. A silent condition means the harness sends no special announcement; it does not mean the change is undiscoverable. Tasks should provide legitimate inspection routes, or else the correct outcome may be safe deferral rather than autonomous resolution.

To avoid favoring a particular agent style, create alternative trigger rules for agents that act differently, and analyze them in separate strata. Do not trigger only on trajectories known in advance to fail. Include intention-to-treat summaries covering all valid assigned trials, with triggered-only analyses clearly labeled as secondary.

11. Measurement and statistical analysis

For the main study, all selected tasks must remain resolvable after a shift. The primary outcome is strict joint success: functional completion AND preservation of protected and legitimate intervening state AND adherence to task authority constraints AND durability under the task's declared post-checks. A single veto-worthy violation makes strict success false. Truly unresolvable tasks belong in a separately reported deferral stratum, not this completion denominator.

For each configuration, report paired strict-success risk differences: P(success | shifted) - P(success | static), with uncertainty intervals clustered by task seed. Also report absolute success probabilities; ratios alone become unstable when baseline success is near zero. Use hierarchical or cluster bootstrap intervals across tasks, and disclose the number of valid trials, repeated draws, and untriggered events. Preregister a small number of primary contrasts and control multiplicity for broader exploratory tests.

Trajectory-derived outcomes are useful diagnostic measures but should be validated for false positives. For example, a diff command may occur after the shift without inspecting the relevant line; a post-hoc summary may claim awareness that no action demonstrates. A blinded reviewer could audit sampled trajectories against an explicit rubric, and disagreements should be retained in the published methodology.

A conservative analysis separates a failure of the agent from a failure of the runner, injection controller, or verifier. Both must be recorded, but infrastructure exceptions should not be silently counted as capability failures or discarded without an exclusion rationale. Repeated trials permit reliability estimation; they do not rescue an invalid task contract.

12. Independent verification and auditability

A resettable environment is necessary for repeatability, but an isolated sandbox does not by itself establish valid grading. The verifier must operate across an information boundary that the agent cannot rewrite. Harbor's public task documentation describes a task format with agent instructions, environment definitions, and test scripts; it also documents separate verifier environments [11]. Such a harness can support SSEP, but an implementation must still test whether its checks reject plausible wrong final states.

12.1 What the verifier should observe

For every task, maintain an evidence map linking requirements to independent checks: before/after state hashes, accepted write-set locations, semantic test behavior, protected user changes, permissions, restart persistence, and the exact shift-event record. A passing task should allow multiple legitimate approaches, rather than encode one preferred sequence of commands.

12.2 Essential negative controls

A verifier should be challenged with an untouched environment, a patch that only suppresses errors, a patch that removes the collaborator's change, a patch that tampers with the test suite, and an outcome that passes briefly but fails after restart. Each mutant should be rejected for the intended reason. A reference solution is necessary evidence of solvability, but it does not guarantee that the test suite rejects every shortcut.

12.3 Required research artifacts

A reproducibility bundle would include task and environment versions, the frozen shift specification, deterministic event-controller logs, reference checks, model/harness settings, full tool trajectories where release is permitted, verifier code, grader test fixtures, trial exclusion reasons, and analysis scripts. Hashes should bind reported results to their corresponding task and verifier versions. Sensitive information and unused production credentials must not enter the released artifacts.

13. From benchmark results to deployment decisions

A deployment team should not interpret a high static pass rate as proof that an agent can operate safely in a shared workspace. Nor should a strong score under one scripted state change imply robustness to every external process, user behavior, or concurrency pattern. The evidence has to specify which changes were allowed, observed, and checked.

SSEP suggests several practical questions for evaluation buyers: Can the system detect that relevant evidence may be stale? Does it protect edits created by other authorized actors? Can it distinguish a harmless change from one that invalidates a plan? Does it obtain fresh evidence before high-impact actions? Can it escalate an unresolved conflict without fabricating an authorization? Can its final claim survive independent checks and restart?

These questions connect software-agent benchmarking to operational assurance. A useful release gate might require zero protected-state violations on a defined high-risk test set, plus a predeclared level of successful completion on compatible shifts. Such thresholds are policy choices and should be justified against the application's stakes; this paper does not recommend a universal percentage.

14. Where Deaimer could contribute

Deaimer publicly describes custom, resettable RL environments, coding-agent evaluations, independent verifier development, reference solutions, and model-run analysis. Its published ColdStart methodology already emphasizes functional recovery together with state safety, durability, integrity, and evidence quality [12, 13]. Those capabilities suggest a practical route to an SSEP pilot, but they do not establish that Deaimer currently operates or has validated the protocol proposed in this article.

An initial pilot could adapt a small collection of approved terminal and repository environments by adding an external state-transition controller, a protected-change manifest, and paired trial configurations. Independent reviewers would validate whether each shift is fair, observable when appropriate, and correctly graded. A follow-on study could expand from code and services into document workflows where incoming instructions or records change during execution.

For model developers and dataset buyers, the value of such a collection would depend on task diversity, verified causal control, negative-control strength, and transparent reporting - not simply on the number of perturbations added. A disciplined pilot should therefore begin with fewer well-audited environment families before scaling to a much larger corpus.

15. Limitations, responsible study, and future work

The central limitation is ecological validity. Synthetic or scripted changes can be reproduced, but real workplaces feature messy timing, multi-user intent, intermittent services, incomplete audit trails, and evolving policies. An agent that succeeds when a test harness injects one change may fail when several independent changes interact. Conversely, a scripted "conflict" can be harder than a genuine collaborative workflow because it excludes human explanation that would ordinarily be available.

Causal interpretation also depends on trigger design. Event-based injections standardize an important decision boundary but do not guarantee that all agents receive equally salient evidence. Models and tool wrappers vary in polling behavior, retries, context management, and permission handling. Results should therefore name the evaluated model-agent system and treat transport or harness changes as possible confounders. Right-censored latency and missed triggers must not be hidden.

Some outcomes require human judgment. A configuration update may be compatible with the task yet violate an unwritten organizational preference. Overwrite safety, escalation appropriateness, and equivalence among alternative repairs can be difficult to encode completely. An explicit contract and independent review reduce this problem but do not eliminate it.

For responsible research, perturbations should run only inside resettable test systems with synthetic records and least-privilege tools. No production service, personal account, or real collaborator should be modified as part of a benchmark run. Where failure trajectories demonstrate unsafe behavior, publication should favor reproducible defensive methodology over release of real credentials, destructive automation, or unbounded attack tooling.

Future research could examine multiple concurrent changes, long-running tasks with partial checkpoints, coordination among several agents, continuous user instruction updates, and selective inspection strategies under tight budgets. Another valuable direction is transfer: does training or prompting for one shift family improve behavior on held-out causes of state drift, or merely teach the agent to recognize a benchmark's characteristic signals?

16. Conclusion

Autonomous agents do not act in a frozen world. The files they read can be edited, the tools they depend on can change, and the user's intent can evolve before the next action begins. The most meaningful test is therefore not whether an agent can follow a plan to the end, but whether it knows when the plan's assumptions need to be checked again - and whether its revised actions preserve the legitimate work already present.

The proposed State-Shift Evaluation Protocol makes that question measurable through paired tasks, controlled external transitions, explicit authority rules, independent preservation checks, and transparent trial accounting. Existing research has already shown that mid-task perturbations matter [8-10]. A useful next step is to make their consequences comparable across executable task families without collapsing adaptability into a single pass score. The goal is not an agent that reacts to every change. It is an agent that responds appropriately to the changes that matter.

Declarations

Article status. Research perspective and experimental proposal, prepared 3 November 2026. This document has not been peer-reviewed and does not report new model experiments, implementation results, or measured benchmark improvements.

Authorship and organizational context. Prepared under the editorial attribution "Deaimer Research" for review. No individual author, title, institutional endorsement, or publication decision is asserted in this draft.

Competing interests. Deaimer offers custom agent environments and evaluation services; the proposed evaluation methodology could be relevant to that work. This association is disclosed rather than presented as empirical validation.

Data and code availability. No new dataset, code release, agent rollout, or measurement accompanies this article. Linked papers, repositories, and documentation are maintained by their respective authors or organizations.

References

1. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. R., and Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. International Conference on Learning Representations.

https://arxiv.org/abs/2210.03629

1. Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., and Yao, S. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. Advances in Neural Information Processing Systems 36.

https://papers.nips.cc/paper_files/paper/2023/hash/1b44b878bb782e6954cd888628510e90-Abstract-Conference.html

1. Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., and Narasimhan, K. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? International Conference on Learning Representations.

https://openreview.net/forum?id=VTF8yNQM66

1. Xie, T., et al. (2024). OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. Advances in Neural Information Processing Systems 37, Datasets and Benchmarks Track.

https://papers.nips.cc/paper_files/paper/2024/hash/5d413e48f84dc61244b6be550f1cd8f5-Abstract-Datasets_and_Benchmarks_Track.html

1. Lu, J., et al. (2025). ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities. Findings of NAACL 2025, pp. 1160-1183. DOI: 10.18653/v1/2025.findings-naacl.65.

https://aclanthology.org/2025.findings-naacl.65/

1. Yao, S., Shinn, N., Razavi, P., and Narasimhan, K. (2024). tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.

https://arxiv.org/abs/2406.12045

1. Barres, V., Dong, H., Ray, S., Si, X., and Narasimhan, K. (2025). tau^2-Bench: Evaluating Conversational Agents in a Dual-Control Environment. arXiv:2506.07982.

https://arxiv.org/abs/2506.07982

1. Tan, Y., Meng, J., Lei, F., Wang, M., He, S., Zhao, J., and Liu, K. (2026). SWE-Touch: Benchmarking Coding Agents When Users Touch the Code. arXiv:2608.02499. Preprint.

https://arxiv.org/abs/2608.02499

1. Balyan, A., and Sharma, S. (2026). Benchmarking the responsiveness of LLM-based agentic systems under controlled mid-task perturbations. Scientific Reports. Published 20 October 2026. DOI: 10.1038/s41598-026-72720-7.

https://doi.org/10.1038/s41598-026-72720-7

1. Yuan, M., et al. (2026). OSWorld2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks. arXiv:2606.29537. Preprint.

https://arxiv.org/abs/2606.29537

1. Harbor Framework. (2026). Tasks: documentation and separate verifier environments. Official repository documentation; accessed 3 November 2026.

https://github.com/harbor-framework/harbor/blob/main/docs/content/docs/tasks/index.mdx

1. Deaimer. (2026). RL Environments & Coding-Agent Evaluations. Public research and capability description; accessed 3 November 2026.

https://www.deaimer.com/rl-environments

1. Deaimer. (2026). ColdStart: Autonomous Recovery Agent Benchmark. Public benchmark methodology; accessed 3 November 2026.

https://www.deaimer.com/benchmarks/coldstart