Context loss, database duplication, and wasted tokens turn into direct operational costs when an agent system encounters a network timeout. If an autonomous agent has drafted a response to a customer inquiry, initiated a draft save, and dropped due to a timeout, the system faces a choice: repeat the write operation, check the result, or halt execution entirely. Such an incident immediately raises the question of accountability: after a restart, should it repeat the write, check the result, or stop?
The emergence of duplicates, lost work, and the reliability of agent reports depend directly on this logic. The reliability of an autonomous system is determined by its architectural harness—the software layer around the model that manages context, tools, state, and task execution. In Google Cloud documentation, this layer is officially defined as encompassing the execution loop, state persistence, tools, memory, and constraints. Meanwhile, repeated calls and harness failures directly impact the cost and reliability of the system.
Control loops and tool isolation
While the model merely proposes an action, the harness and its execution environment determine operation availability and result handling rules. Ready-made agent environments such as Codex, Claude Agent SDK, Gemini CLI, and Hermes Agent from Nous Research illustrate these capabilities, whereas LangGraph and Google ADK handle process management directly in code. There is also Harness², an experimental approach to modifying the harness itself. Documentation and materials for these architectures were reviewed on October 20, 2026.
Google Cloud documentation defines this layer as encompassing the execution loop, state persistence, tools, memory, and constraints.
Vendor infrastructure is gradually asserting control: in OpenAI's official Codex harness documentation, the architecture highlights dialog state, event streams, tools, sandboxes, and confirmation policies. Through an app-server, the calling application can create threads, run turns, receive events, and process permission requests. However, a connected tool server on its own does not describe the entire process of management and failure recovery. Who then assumes responsibility for passing state between sessions?
Persistence mechanisms and the illusion of automated reliability
The answer lies in the rigorous transfer of structured artifacts between sessions. In an Anthropic experiment with long-running tasks, an initial agent prepares the working environment and a list of requirements, while subsequent sessions implement changes step by step. To transfer the work, artifacts are used: function lists, progress logs, Git history, and application checks, since simple dialog compression alone failed to resolve the issue.
A prevailing viewpoint suggests that out-of-the-box agent environments automatically solve failure recovery and state management, rendering custom harness development redundant. Yet tool documentation refutes the universal applicability of standard solutions.
Gemini CLI features checkpointing: before files are modified by a supported tool, a project snapshot, conversation history, and pending calls are saved.
The built-in /restore command allows reverting to this saved state, but verified documentation shows this feature is disabled by default and must be enabled manually through settings. Furthermore, a local project snapshot rollback cannot cancel an already executed API request to a third-party service.
Similar architectural constraints apply to memory management. Memory documentation separates compact persistent facts from past session retrieval. Facts enter the system context via a snapshot at session startup, meaning that writing to disk does not guarantee the currently running session has re-read that data. For operational procedures, a skills system stores on-demand procedures, and through skill_manage, the agent can create and modify them. To control writes, a skills.write_approval option prepares modifications for human review prior to execution.
The industry anticipated that integrating ready-made agent environments and expanding context windows would automatically eliminate infrastructure failures during complex task execution. In practice, base models still demand rigid external state-fixation contracts, absent which any execution error translates into an uncontrolled surge in rerun costs.
How the picture shifted
Teams used to rely on simple conversation compression to keep AI agents coherent, but actual reliability came down to passing structured artifacts between sessions and handling network timeouts. The model merely suggests an action, leaving execution loops, wasted tokens, and duplicate external writes entirely to the surrounding harness. Out-of-the-box mechanisms like the /restore command do not solve this automatically, as the feature remains disabled by default in verified documentation and cannot undo an external network request that already went through. A single failure at the session boundary turns a harness architecture flaw into direct bills for wasted tokens and duplicate database records.