Agents increasingly require isolated workspaces, often provided by sandboxes, to run code, install packages, and manage files securely. Two main architectures exist for integrating these agents with sandboxes. The first, termed "Agent IN Sandbox," places the agent directly inside the sandbox, communicating over a network. This setup mirrors local development but introduces security risks, such as potential credential exposure if the sandbox is compromised. Additionally, updates necessitate rebuilding the container, which can slow down development cycles. The second architecture, "Sandbox as Tool," allows the agent to run on a local machine or server while calling a remote sandbox via API for code execution. This method streamlines updates, keeps API keys secure, and maintains a clear separation between the agent's state and the execution environment. It also supports parallel execution across multiple sandboxes, which can be more cost-effective. However, it does introduce network latency, particularly for workloads with numerous small executions. Choosing between the two patterns depends on specific needs. Pattern 1 is better for tightly coupled systems requiring consistent environments, while Pattern 2 suits rapid iteration and enhanced security. Examples using the open-source framework deepagents illustrate how these patterns can be implemented, highlighting the practical aspects of each approach.