Deep Agents Sandbox Architecture: sandbox-as-tool or Full-Agent-in-Sandbox?

When building a research-synthesis agent on LangGraph, the Deep Agents sandbox documentation lays out two paths: sandbox-as-tool (the agent stays outside the sandbox and calls into it on demand to execute specific operations) and full-agent-in-sandbox (the entire coordinator-worker tree runs inside the sandbox). A developer on Reddit is grappling with this decision, and his question hits a pain point for many people building multi-agent systems—especially when multiple sub-agents need to share working state, where exactly do you draw the boundary?

The Core Trade-off Between the Two Modes

The original post spells out the pros and cons quite plainly. The appeal of sandbox-as-tool is lower per-step overhead: you don't need to spin up a VM on every call, the debugging chain is shorter, and agent state naturally lives alongside LangGraph's graph state. The cost is that every call is a boundary round-trip; if a sub-agent needs to run several pieces of code in sequence to complete a subtask, that round-trip cost gets paid over and over.

full-agent-in-sandbox is better suited to a coordinator-worker structure: sub-agents each own a working filesystem, and the agent plane itself doesn't need to be trusted. The trouble is heavier cold starts, plus you need extra plumbing to pull sub-agent progress out of the sandbox and into LangSmith for observability. The developer currently leans toward sandbox-as-tool, on the grounds that in his scenario each sub-agent's tool operations are short and state mainly lives in the agent's own files and to-do lists.

LangGraph is an orchestration framework from the LangChain team for building stateful multi-agent applications. Its core abstraction is the "graph": nodes represent agents or tool-call steps, edges define control flow, and graph state persists throughout execution, passing between and being modified by nodes. It is precisely this explicit state-management mechanism that makes "agent outside the sandbox + call the sandbox on demand" a natural choice—the agent's reasoning state stays isomorphic with graph state, and the sandbox is simply wired in as a tool node. Understanding this is what makes clear the real meaning of "agent state naturally lives alongside LangGraph's graph state" in sandbox-as-tool mode: state doesn't need to be synced across a boundary, because the agent plane itself never leaves the graph.

LangSmith is the companion observability platform, used to trace agent call chains, tool execution latency, and intermediate outputs. When the agent runs outside the sandbox, tool-call boundaries are clean, and LangSmith can automatically capture the latency and parameters of each sandbox round-trip; when the entire agent tree runs inside the sandbox, those internal events are invisible to LangSmith, and you must manually instrument or build a log pipeline to get the data out of the sandbox—which is exactly where the "extra plumbing" of full-agent-in-sandbox mode comes from.

Backend Options and API Fit

Backends listed in the docs include Modal, Daytona, Deno, and Node VFS. The poster additionally mentions GMI AgentBox, drawn to its create/upload/exec/result/delete API—this five-step interface seems almost tailor-made for sandbox-as-tool mode: upload, execute, fetch results, destroy, with each action mapping to one tool call and clean semantics.

This fit at the API-design level is worth noting: it lowers the mental burden of wrapping a sandbox as a single tool, and it makes the lifecycle boundary of each tool call explicit. For research-synthesis agents, frequent code execution tends to be fine-grained; the closer the interface is to a "one-shot operation" model, the more acceptable sandbox-as-tool's round-trip cost becomes.

Modal, Daytona, Deno, and Node VFS represent several different forms of sandbox backend. Modal and Daytona provide full remote container/VM execution environments with filesystems, network isolation, and process management, suitable for running arbitrary code; the Deno sandbox leans toward lightweight JavaScript/TypeScript runtime isolation with a finer-grained permission model but a more limited ecosystem; Node VFS is a virtual filesystem abstraction, not a true execution sandbox, and is more often used to simulate file operations within the agent process. These backends differ significantly in cold-start latency, persistence, and API granularity, which directly determines the actual round-trip cost of each tool call in sandbox-as-tool mode. The poster's preference for GMI AgentBox is essentially a search for a backend whose API semantics align with the "one-shot tool call" model, avoiding the need to write an extra adapter layer for state management.

The Really Thorny Problem: Sub-Agent Shared State

The post's central question isn't the mode choice itself, but what to do about sub-agent state when the sandbox is managed on a per-tool-call lifecycle. If sub-agent A writes a file and sub-agent B needs to read it in the next step, there are only two options: either keep the sandbox warm for the entire sub-agent run—but that's already close to full-in-sandbox—or materialize state back into the agent filesystem between each call.

This tension is very representative. The selling point of sandbox-as-tool is lightness and clean boundaries, but once multiple sub-agents need to share working artifacts, the complexity of state synchronization bites back. The poster himself realizes that "keeping the sandbox warm" and "full-in-sandbox" aren't very different in engineering terms—just nominally different modes.

A warm sandbox refers to keeping a sandbox instance alive between tool calls rather than destroying it. Compared with cold starts, a warm sandbox saves the overhead of booting a VM and remounting the filesystem, at the cost of sustained resource usage and more complex lifecycle management. In multi-sub-agent scenarios, "keeping the sandbox warm" in effect blurs the line between sandbox-as-tool and full-agent-in-sandbox: the former assumes each call is independent and destroyed after use, whereas a warm strategy turns the sandbox into a stateful, long-lived entity whose lifespan the agent must explicitly manage—already very close, in engineering complexity, to putting the entire agent tree inside the sandbox. The poster's intuition—"keeping the sandbox warm and full-in-sandbox aren't very different in engineering terms"—stems precisely from this.

A Decision Framework: Start From State-Sharing Density

From this discussion one can distill a practical decision axis: the density of state sharing among sub-agents. If subtasks barely exchange files and each tool operation is independent and short, sandbox-as-tool's round-trip cost is manageable, and debugging and observability are easier. If, in a coordinator-worker structure, sub-agents need to continuously read and write the same working directory, then putting the entire agent tree inside the sandbox and accepting the cold-start and extra-instrumentation costs is often the more honest choice.

The poster ends by asking the community: in scenarios where multiple sub-agents share working state, do people converge on full-in-sandbox, or stick with sandbox-as-tool and route state through agent files? There's no standard answer yet, but the question draws the real dividing line in Deep Agents sandbox design—not performance numbers, but which side state should live on.

Originally from a Reddit community discussion; the observations about GMI AgentBox are the poster's own experience and have not been cross-verified by other sources.

One-line Summary

Deep Agents sandbox mode choice depends on the density of state sharing among sub-agents, not on raw performance comparisons.

Paragraph Summary

Drawing on a developer discussion on Reddit, the article analyzes two Deep Agents sandbox modes for building research-synthesis agents on LangGraph: sandbox-as-tool has low per-step overhead and a short debugging chain but pays a boundary round-trip cost on every call; full-agent-in-sandbox better suits coordinator-worker structures at the cost of cold starts and observability pipelines. It notes that GMI AgentBox's five-step API fits sandbox-as-tool well, but the really thorny issue is multi-sub-agent shared working state—keeping the sandbox warm is already close to full-in-sandbox, otherwise state must be materialized between calls. It distills a decision framework based on state-sharing density: choose sandbox-as-tool for independent, short subtasks, and full-in-sandbox when a shared working directory is continuously accessed.