Resilient Write: A Six-Layer Durable Write Surface for LLM Coding Agents
Authors: Justice Owusu Agyemang, Jerry John Kponyo, Elliot Amponsah, Godfred Manu Addo Boakye, Kwame Opuni-Boachie Obour Agyekum
Organizations: Sperixlabs, Ghana · Kwame Nkrumah University of Science and Technology, Kumasi, Ghana · VIA Cybersecurity Lab, Kwame Nkrumah University of Science and Technology, Kumasi, Ghana
LLM-powered coding agents increasingly rely on tool-use protocols such as the Model Context Protocol (MCP) to read and write files on a developer's workstation. When a write fails - due to content filters, truncation, or an interrupted session - the agent typically receives no structured signal, loses the draft, and wastes tokens retrying blindly. We present Resilient Write, an MCP server that interposes a six-layer durable write surface between the agent and the filesystem. The layers - pre-flight risk scoring, transactional atomic writes, resume-safe chunking, structured typed errors, out-of-band scratchpad storage, and task-continuity handoff envelopes - are orthogonal and independently adoptable. Each layer maps to a concrete failure mode observed during a real agent session in April 2026, in which content-safety filters silently rejected a draft containing redacted API-key prefixes. Three additional tools - chunk preview, format-aware validation, and journal analytics - emerged from using the system to compose this paper. A 186-test suite validates correctness at each layer, and quantitative comparison against naive and defensive baselines shows a 5x reduction in recovery time and a 13x improvement in agent self-correction rate. Resilient Write is open-source under the MIT license.
Figures & tables
Layer
MCP Tool
Mechanism
Failure Mode Addressed
L0
rw.risk_score
Deterministic regex + size classifier
Silent content-filter rejection
L1
rw.safe_write
Temp file, fsync, hash verify, atomic rename
Truncation, corruption, half-writes
L2
rw.chunk_*
Numbered chunk files with contiguity check
Payload too large for single call
L3
(error envelope)
Typed JSON error schema
Opaque, unstructured error signals
L4
rw.scratch_*
Content-addressed out-of-band store
Secrets that must not enter the tree
L5
rw.handoff_*
YAML+Markdown envelope with hash audit
Cross-session continuity loss
Table 1: The six layers of Resilient Write and the failure modes they address.
Figure 1: Six-layer architecture of Resilient Write . Arrows show data flow from the agent’s tool call through each layer to the filesystem. L3 error envelopes (orange) are cross-cutting; L4 scratchpad (green) writes out-of-band.
Layer
Module(s)
Tests
L0
test_risk_score
28
L1
test_safe_write, test_journal
17
L2
test_chunks
27
L3
test_errors
27
L4
test_scratchpad
21
L5
test_handoff
8
Table 2: Test distribution by component.
Figure 2: Test distribution across layers and extensions (186 tests total).
Metric
Original
With Resilient Write
Write attempts
6
2
Content lost
yes
no
Structured error
no
yes
Agent self-corrected
no
yes
Manual intervention
yes
no
Table 3: Comparison of the original failed session and the Resilient Write replay.
Metric
Naive
Defensive
Resilient Write
Recovery time (s)
10.0
5.5
2.0
Data loss prob. (%)
5.0
1.0
0.1
Self-correction (%)
5
15
65
Wasted calls (%)
25
12.5
3.0
Table 4: Estimated metrics across three write approaches.
Figure 3: Comparison of write approaches across four metrics. Lower is better for recovery time, data loss, and wasted calls; higher is better for self-correction rate.
Table 5: RAB Pass@1 on OpenRouter (13 models, 3 trials each). Anthropic models and GPT-5.5 score 100%; S0 and S4 are the most discriminative tasks. S3 (cursor drift) is the only scenario passed by every model tier.
Model
Provider
Intel
S0
Tool format?
Result
Kimi K2.6
DW
54
✓
✓
Correct chunked-read strategy
Gemma 4 31B
DW
39
✓
✓
Correct search-pagination strategy
DeepSeek V4 Pro
DW
50
✓
✓
Same strategy as OR ( ρ=1.0 )
GLM 5.1
DW
51
—
×
Describes approach, no tool call
Qwen3.6 35B
DW
43
—
×
Describes approach, no tool call
Qwen3.5 397B
DW
45
—
—
API blocked (routing rule)
Table 6: RAB on DoubleWord and local models (1 trial each). DW models use XML-embedded tool prompts; only models with strong instruction-following produce valid tool calls.
Large language model (LLM) agent reliability concerns dependable, safe, and verifiable behavior across tools, multi-step tasks, and changing environments.
Large Language Model (LLM) agents have significantly improved coding and programming workflows. Claude Code, in particular, is one of the most powerful LLM coding agents and is capable of conducting complex coding tasks. However, several drawbacks can undermine long-term agentic workflows. (1) Irrecoverable agent teams: The Agent Teams feature is powerful, but the working state accumulated by each teammate is lost and cannot be resumed once the process stops, for example, when a terminal is closed. (2) Compaction erodes working detail: Compaction condenses the conversation into a summary, causing an agent's working details to become vague. (3) Agentic "technical debt": Over time, a user's decisions and the agents' operations become trapped in compacted old chats, making the project increasingly difficult to maintain and review. (4) Heavy prompt writing: Assigning or handing off tasks requires users to repeatedly write long prompts to achieve the expected agentic performance. We propose ATWZ (Agent Team Work Zone), a filesystem-based operations layer built around Claude Code's native Agent Teams that addresses these problems. Its central design principle is to treat each agent and teammate as a human employee and preserve their important working state in files stored in a dedicated directory called a "workstation," together with the skills, hooks, and scripts that use and maintain these files. With ATWZ, an agent team can periodically back up its working state, allowing an agent's knowledge to be recovered after compaction. After a process ends, the team can be restored with a single command. These features also substantially mitigate the agentic "technical debt" described above. Moreover, within ATWZ, agent "employees" can send documents to one another, greatly reducing the effort required to write prompts.
Tool-using LLM agents are mostly evaluated assuming all tools work. When a tool times out, returns a week-stale value, or has its description poisoned in deployment, the developer needs a controlled way to reproduce the failure, test a fix, and confirm the fix worked before deployment. We present AgentCheck, an open-source web workbench that turns an MCP server into an intervention surface. AgentCheck runs an agent against its real tools and records every tool response, then re-runs the agent with the response perturbed by a fault (12 types) injector. Matching tool calls are replayed from cache, and later tool calls go live after the agent diverges. This yields a reproduce-intervene-confirm loop: the developer toggles a mitigation, re-runs against the identical fault, and sees if the failure goes away. Scoring has two parts: deterministic pass/fail rules, plus an LLM judge for interpretive labels, validated against human annotations. Across five agents, the best passes 105/120 scenarios and the weakest only 77. The failures are usually silent, confident use of incorrect tool outputs rather than crashes. On the weakest agent, a retry mitigation raises success on timeout error faults from as few as 30% of cases to 100%, whereas stale-data faults remain near 3-4 of 10 regardless of the mitigation. AgentCheck makes these failure modes reproducible, comparable, and verifiable before deployment.
LLM coding agents operate by constructing trajectories that accumulate reasoning, tool calls, and results to enable multi-step decision-making. However, the conventional append-only trajectory architecture found in practice tightly couples file-read actions with their observations, capturing snapshots that become permanently fixed in the chronological history. As files change through agent edits or concurrent human modifications, these snapshots become stale, causing reasoning errors and causing agents to redundantly re-read files, with each re-read appending yet another copy to the trajectory. To mitigate this, we propose CORVUS, a novel trajectory architecture that decouples file-read actions from their observations by maintaining a synchronized registry of relevant files and injecting only their current contents at each reasoning cycle. This structural change produces significantly lighter-weight trajectories that remain synchronized with the actual codebase state by construction, eliminating redundant file copies and stale snapshots that bloat conventional trajectories. We evaluated CORVUS on SWE- POLYBENCH_VERIFIED and SWE-BENCH PRO across four LLMs, achieving 9-50% reduction in average input tokens per task, 15-32% shorter final prompts, and up to 37% fewer reasoning cycles while maintaining comparable pass rates.
Mingwei Zheng, David OBrien, Siwei Cui +4
Department of Computer Science, Purdue University · 2AWS AI Labs