Claude: The State of Managed Agents, More Crucial Than Calculation

The Discovery of an Unexpected Loss

On a Tuesday morning at 9:03 AM, a research agent greeted the executive, but it was to reveal a troubling void in the work directory. The six hours of analysis carried out the previous night had vanished. Everything, from the cloned repository to the installed packages, along with the meticulously written notes, had evaporated. The executive had naively believed that an agent could simply pick up its work where it left off after a night's break. This assumption turned out to be wrong. To understand what had happened, he had to rebuild the same workflow on three different platforms: Tensorlake, Cloudflare, and Daytona. What proved most complex in managing Claude agents was not the model itself, but everything beneath it.

The exact code that was run, what failed, and the mistake that took two weeks to understand.

Understanding Managed Claude Agents

For those unfamiliar with managed Claude agents, it is crucial to understand their architecture. If you already know this system, you can skip this section. Anthropic is responsible for reasoning, while execution is handled by the user. The agent loop, session state, work queue, and retry logic are all hosted on Anthropic's infrastructure. The user sets up a self-hosted environment via the Claude console. Once the application is launched, Anthropic queues the work, the orchestrator picks it up, creates a sandbox, and the model begins to issue tool calls within that sandbox. Each command, whether it be bash, read, write, grep, or edit, executes in an environment fully controlled by the user. Anthropic never intervenes directly. The user defines what this environment looks like, its access, and what happens between sessions. Anthropic's intelligence is constant. The user's engineering determines whether this intelligence operates in a stable, persistent environment or on a blank slate that forgets everything as soon as it goes idle.

The Project and Its Importance

The goal was to create an agent capable of conducting in-depth research on a codebase: cloning a repository, analyzing the structure of modules, understanding how the different parts fit together, writing notes, and proposing refactoring strategies. This type of work, which would take a senior engineer an entire day, can be accomplished in about six hours by an AI agent. The main constraint was that the agent could not do everything at once. Sometimes, a session was started at 8 PM, left to run until midnight, and then picked up again the next morning. The file system created during that first session (with analysis notes, installed tools, and partially read source files) needed to be available when the next session began. Rebuilding each time was not a viable option. This constraint guided every vendor decision that was made.

Unforeseen Needs

At the outset, it was thought that a simple Linux environment would suffice to run managed Claude agents. In the end, it became clear that three essential elements were needed. All of them were found in the same place, but only after exploring two other options.

• A file system that survives between work sessions.
• Near-zero cost while the agent is idle.
• The ability to branch from an already completed analysis state.

These requirements did not reveal themselves immediately. They were discovered through a series of mistakes.

Starting a Session: Code Before the Sandbox

To launch a session, the reference orchestrator is used with a simple command:

[make](/outil/make) session [PROMPT](/glossaire/prompt)="Clone the repository at github.com/tensorlakeai/tensorlake. \Read through the module structure. Write a summary to /workspace/analysis.md. \Note any components that look like they could be simplified."

The orchestrator sends this prompt to Anthropic as a new session. Anthropic takes it on, starts the agent loop, and immediately begins issuing tool calls. These tool calls arrive in the sandbox. The agent reads files, executes bash commands, writes notes. The session continues until the task is completed or the user stops it. The agent's flow looks something like this while it operates:

• [thinking] The repository appears to be a Python SDK for…
• [bash] git clone https://github.com/tensorlakeai/tensorlake
• [bash] ls -la /workspace/tensorlake/
• [read] /workspace/tensorlake/tensorlake/sandbox.py
• [write] /workspace/analysis.md
• [thinking] The Sandbox class manages…

Each event in brackets is a tool call entering the sandbox. The session accumulates a state inside /workspace/ through all these calls. At the end of a six-hour session, this directory contains the cloned repository, installed packages, analysis files, and interim notes. It is this state that must survive the night.

First Attempt: Cloudflare

The first hypothesis was that a platform capable of efficiently running managed Claude agents was needed. Cloudflare is optimized for high-concurrency execution. The problem turned out to be different. The agent being built accumulated hours of file system state between work periods. Notes, cloned repositories, installed dependencies, and interim analyses needed to survive the night. Cloudflare's execution model was not designed around this requirement. It was the first time it was realized that what was being sought was not computation, but persistent state.

Second Attempt: Daytona

The second build solved part of the problem. The agent could accumulate state throughout a session, which initially seemed like progress. Then, the aim was to test three different refactoring strategies starting from the same six-hour analysis. Instead of branching from that state, the setup work had to be repeated each time: rebuilding the context, reinstalling dependencies, and rerunning the analysis before the actual experiment could begin. It was at that moment that the second requirement was discovered. Preserving state was not enough. A way to branch from an existing state without repeating hours of work was also needed.

Third Attempt: Tensorlake

The first thing that caught the executive's attention was not a feature. It was an architectural decision. Most platforms preserve state by keeping computation active. This one treated computation and state as distinct problems. The documentation described a suspended sandbox capable of preserving its state and resuming in about 0.6 seconds. It was the first time a design directly addressed the problem being faced. The aim was to find out whether it actually worked. Experimentation began with…