Pool by Poolside: A Deep-Dive Review of the Terminal Agent That Ships With Its Own Sandbox

I've spent enough time wrestling with AI coding agents that promise the world and deliver a mess of unconfigurable, insecure workflows — so when Poolside released Pool, a terminal-based coding agent with enterprise-grade sandboxing and a three-tier configuration hierarchy, I paid attention. Pool isn't just another CLI wrapper around an LLM; it's the same agent infrastructure Poolside uses internally for reinforcement learning training and evaluation of their Laguna models, now available as a research preview. That production-parity angle alone sets it apart from most coding agents that are built for demos, not deployment. But it's still a beta product with real limitations — tool-call looping, sandbox enforcement gaps, and trajectory storage bloat are documented issues. In this review, I'm breaking down every architectural detail, benchmark, configuration mechanism, and trade-off I could extract from the documentation so you can decide whether Pool deserves a spot in your workflow.

What Is Pool? — A Terminal-Based Agentic Coding Environment

Pool is Poolside's terminal-native coding agent, but calling it merely a CLI tool undersells the architecture. At its core, Pool functions as a dual Agent Client Protocol (ACP) client-server implementation, standardizing how the agent communicates with its execution sandbox. Released as a research preview alongside the open-weight Laguna XS.2 model, it targets enterprise development workflows rather than casual scripting. I see this as a deliberate positioning move: Poolside isn't shipping a chat wrapper, but a runtime environment engineered for production agentic tasks.

What immediately stands out to me is the production parity between training and deployment. Poolside uses this exact terminal environment internally for agent reinforcement learning training and evaluation. That is rare. Most agent frameworks split their training harness from their inference tooling, which introduces subtle environment mismatches that degrade real-world performance. By keeping the evaluation environment identical to the training environment, Poolside removes an entire class of distribution-shift bugs. When the agent learns file system navigation or dependency management during training, it executes those patterns in precisely the same sandbox during actual deployment.

Why Terminal-Native Architecture Matters

The terminal-based design isn't retro styling; it aligns directly with how agentic coding workflows actually operate. Agents need deterministic shell access, process isolation, and raw stdout/stderr streams to reason about tool execution. Pool delivers that by embedding the agent inside the same interface it uses to manipulate code.

• Dual ACP client-server: The architecture separates the agent's reasoning loop from its execution environment through a standardized protocol. This means the LLM client can live in one process while the sandbox runs elsewhere, connected via ACP.
• Standardized communication: Rather than ad-hoc shell spawning or brittle JSON-RPC wrappers, ACP provides a strict contract between the agent and its tools. I notice this makes it significantly easier to swap models or execution backends without rewriting integration logic.
• Enterprise targeting: The protocol abstraction and sandbox isolation map cleanly to enterprise requirements for auditability, reproducibility, and security boundaries.

Multi-Surface Deployment and Local LLM Serving

Pool isn't locked to a single IDE or interface. It ships across multiple surfaces: the Poolside Assistant extensions for VS Code and Visual Studio, the Poolside Agent CLI, Poolside Chat, and OpenAI-compatible API integrations. This flexibility tells me Poolside wants the agent runtime to travel with the developer rather than forcing context switches into a proprietary GUI.

The Ollama integration deserves specific attention. Users can point Pool's LLM client to a local endpoint at http://localhost:11434, which provides API-compatible access while keeping all data on the local machine. For enterprises evaluating coding agents, this is a critical feature. Sensitive codebases never leave the network perimeter, yet the agent still benefits from the full ACP client-server loop and sandboxed execution.

Releasing Pool alongside the Laguna XS.2 weights signals a broader strategic priority. Poolside is building the full agentic coding stack, not just dropping model checkpoints. The combination of open weights, a terminal-native ACP runtime, and local serving via Ollama creates a complete loop: train the model, evaluate it in the same sandbox users get, and deploy it behind a firewall without cloud dependencies. I view this as a direct bet that agent infrastructure—the protocol layer, the sandbox, and the evaluation harness—matters just as much as the base model's parameter count.

The Three-Tier Configuration Hierarchy — Enterprise-Grade Settings Control

When I analyze Pool's configuration architecture, the three-tier hierarchy immediately stands out as a deliberate solution to enterprise-scale policy management. Instead of relying on a monolithic global file or scattered environment variables, the agent reads from three distinct settings.yaml sources in a strict order of precedence:

1. .poolside/settings.local.yaml — personal, project-specific overrides with the highest precedence; explicitly excluded from version control.
2. .poolside/settings.yaml — shared, project-specific defaults committed to version control.
3. ~/.config/poolside/settings.yaml — personal defaults that apply across all projects, carrying the lowest precedence.

This structure directly addresses the tension between enforcing organizational baselines and giving individual developers the flexibility to override sensitive parameters without triggering security incidents.

How Precedence Protects Credentials

The precedence rule is straightforward: local > project > global. When identical settings exist across multiple files, the most specific file wins. In practice, this means a team can commit a shared .poolside/settings.yaml to version control that establishes baseline rules—such as approved MCP servers or default sandbox memory limits—while individual developers maintain sensitive overrides inside .poolside/settings.local.yaml. Because that local file is explicitly excluded from version control, the risk of leaking API keys or sandbox credentials into a shared repository drops to near zero. I view this hard split between committed project config and uncommitted local overrides as a practical, zero-config defense against credential exposure.

The Six Top-Level Keys

The configuration schema separates concerns across six top-level keys, giving administrators defense-in-depth without unnecessary complexity:

• pool: Governs API connection parameters.
• tools: Defines approval rules with allow/deny lists that support wildcard patterns, plus a disabled boolean toggle to completely shut off tool access if needed.
• paths: Controls filesystem access through allow/deny entries, with an optional write: true flag that explicitly grants edit permissions rather than assuming read-write by default.
• secrets: Manages credential management in isolation from other settings.
• mcp_servers: Configures external tool integrations.
• sandbox: Tunes the isolated execution environment.

This separation means a security team can lock down the paths key to read-only access for sensitive directories while the sandbox key restricts CPU and memory, all without touching network-related pool settings or developer-specific secrets. Each layer operates independently, so a policy change in one domain doesn't cascade into unintended side effects in another.

Enterprise-Grade Control in Practice

What stands out to me is how the tools and paths keys translate high-level policy into enforceable, machine-readable constraints. The tools key doesn't just list approved binaries; it uses wildcard patterns so an admin could allow docker-* while denying specific subcommands, and flip the entire subsystem off with disabled: true. Similarly, the paths key's explicit write: true requirement forces a deliberate choice about mutability—defaulting to safer read-only access unless a developer specifically opts in. By combining hierarchical overrides with granular, key-based restrictions, Pool delivers a configuration model that is rigid enough to enforce compliance yet flexible enough to let developers move fast without waiting for IT tickets.

Sandboxed Execution — Isolated Container Environments for Agent Runs

When I look at Pool's sandbox architecture, what stands out immediately is how deliberately the configuration maps to real-world security boundaries. The entire setup lives in settings.yaml under the sandbox section, and it gives you six levers to pull: image, env_vars, secrets, filesystem, filesystem.mounts, and network. That granularity matters because it lets you treat the agent's runtime as a proper containerized workload rather than a loose script running on your host.

The image field lets you pin a specific base like poolsideengineering/ubuntu-with-tools, which means you can standardize the toolchain across your team. I like that env_vars and secrets are handled separately—env vars are injected directly, while secrets are fetched by name from the agent's secret manager. That split keeps sensitive values out of plain-text configuration and enforces least-privilege access on a per-sandbox basis.

Workspace Access and Filesystem Mounts

Filesystem isolation is where I see the most practical engineering decisions. The filesystem.workspaces.access setting is binary—read-only or read-write—and that simplicity forces you to make an explicit choice about whether the agent can mutate project files. There is no ambiguous middle ground.

For host-path integration, the filesystem.mounts array demands absolute paths on both the host and the sandbox side. Each mount target must be unique, and the system actively prevents overlaps with already-mounted workspace directories. That constraint might feel strict if you are used to more permissive Docker bindings, but it eliminates an entire class of path-traversal and shadowing bugs. I appreciate that the mounts are explicit; you cannot accidentally expose your entire host filesystem through a relative path typo.

Network Egress and Policy Enforcement

On the networking side, Pool gives you three policy modes under network.policy: off, allow-list, and unsafe-allow-all. The naming alone tells you which one the developers expect you to use in production. When you select allow-list, the network.egress controls kick in with allowed_domains and allowed_cidrs. For example, you can restrict outbound traffic to [poolside.ai] and [10.0.0.0/8], which is exactly the kind of tight boundary you need when an agent is fetching dependencies or calling internal APIs.

A secure enterprise setup might look like this: read-only workspace access, a single read-only data volume mounted from a specific host path, and an egress policy locked to internal Poolside domains plus private IP ranges. That configuration minimizes the blast radius if the agent encounters a malicious package or an unexpected network call.

Session Persistence and Workspace Tailoring

One detail I find genuinely useful is that these sandboxes are not ephemeral throwaways. They support volume mounts for persistent data, and you can define workspace-specific settings so that different projects get different sandbox profiles. Even better, Pool handles session restoration when you switch conversations or restart the IDE. That means I do not have to rebuild the environment every time I context-switch between tasks, which saves a significant amount of time during long debugging sessions or multi-step refactors.

Overall, the sandbox model treats the agent as an untrusted guest by default. Every mount is explicit, every network destination is whitelisted, and every workspace permission is deliberately scoped. That is the kind of defensive design I want running code on my machine.

Agent Client Protocol (ACP) — Editor Integration Without Context Switching

When I look at how Poolside handles editor integration, the pool acp command immediately stands out as the backbone for agent communication. Rather than forcing me to abandon my IDE to interact with an LLM, ACP pipes agent workflows directly into the editors I already use—JetBrains, Zed, and Neovim. I can fire off a prompt, receive a structured response, and apply code generation, refactoring, or documentation updates without my cursor ever leaving the buffer. That tight feedback loop is exactly what keeps the inner-loop development process from stalling out, and I notice that the protocol treats the editor as a first-class participant rather than an afterthought.

Why the Dual Client-Server Architecture Matters

What caught my attention architecturally is that Pool doesn't merely consume ACP; it implements both sides of the protocol as a dual client-server. This means the agent can act as a client that initiates its own actions, while simultaneously running as a server that responds to external orchestration requests. In practice, this bidirectional capability lets Pool participate in complex multi-step agentic workflows where it isn't just passively waiting for human commands—it can trigger operations autonomously and then accept further instructions from another system, editor hook, or orchestration layer. Because both endpoints speak the same protocol natively, standardized communication between the agent and its execution environment happens without brittle translation layers or ad-hoc socket management.

• Bidirectional control flow: Pool initiates agent actions and responds to external orchestration without protocol translation layers.
• Standardized messaging: A single protocol governs both prompt ingestion and execution environment feedback, reducing integration fragility.
• Autonomous workflow support: The agent can self-trigger steps within a larger pipeline, which is essential for non-trivial automation.

Remote Sessions and Sandbox Synergy

The remote session support is another detail I find genuinely useful for real-world development. I can run the agent on a remote machine or container while my local editor remains the control plane. That setup becomes especially powerful when combined with Pool's sandboxing. Instead of worrying that an agent-generated script might pollute my local environment or install conflicting dependencies, I can isolate execution in a sandboxed remote instance and still drive everything from my local Neovim or JetBrains session. ACP creates the secure bridge, and the sandbox creates the safety boundary.

• Remote-local split: Agent compute lives on remote infrastructure; editor interaction stays local.
• Isolated execution: Sandboxes prevent agent operations from corrupting local development environments.
• Environment management: The pairing directly addresses the pain point of managing runtime states and dependencies for LLM-generated code.

Eliminating Workflow Fragmentation

Looking at the broader picture, I see ACP as a direct, engineering-focused response to workflow fragmentation. Every context switch—opening a browser tab, copying code into a chat interface, pasting results back, fixing indentation errors—introduces friction and failure points. By keeping prompts and responses inside the editor, ACP collapses that gap. When I factor in the dual client-server design alongside sandboxed remote execution, it is clear to me that Poolside is aiming for something more sophisticated than a simple chat overlay. The architecture supports genuine agent autonomy within a controlled, editor-native interface, which is a notable step up from the typical LLM plugin model that still treats the model as an external consultant rather than an integrated runtime participant.

Laguna Models Under the Hood — Benchmarks That Actually Matter

When I look at Poolside's Laguna family, what stands out immediately is the deliberate architectural split between efficiency and raw capability. Both Laguna XS.2 and Laguna M.1 rely on Mixture of Experts, but the gap in their activated parameter budgets tells the whole story. XS.2 activates just 3B parameters per token out of a 33B total parameter pool, while the flagship M.1 scales that to 23B activated parameters from a 225B total footprint. To me, this isn't just a scaling exercise; it's a clear bet that you can deliver top-tier software engineering performance without burning through compute budgets unnecessarily.

The XS.2 Efficiency Play

XS.2 is where Poolside proves that claim. Trained completely in-house on 30T tokens, this second-generation architecture ships under the Apache 2.0 license—a notable move for a company building terminal-native agents. Looking at the benchmarks, I see why they were confident releasing the weights openly: SWE-bench Verified 68.2%, SWE-bench Multilingual 62.4%, SWE-bench Pro 44.5%, and Terminal-Bench 2.0 30.1%. Those numbers place it in the same conversation as Qwen3.5 (35B-A3B) and Gemma 4 (31B dense), despite operating on roughly an eighth of the active parameter budget that M.1 demands.

What catches my eye from a practitioner standpoint is the local deployment angle. Because the model is compact enough to run on a Mac with 36 GB of RAM via Ollama, XS.2 removes the usual cloud-dependency friction. Poolside also ships a Laguna XS.2-base variant, which gives teams the flexibility to fine-tune on their own codebases rather than relying solely on the instruction-tuned release.

Inside the M.1 Flagship

If XS.2 is the efficiency play, M.1 is the performance ceiling. The 225B total parameter MoE architecture pushes activated capacity to 23B parameters per token, and the benchmark gains are measurable: SWE-bench Verified 72.5%, SWE-bench Multilingual 67.3%, SWE-bench Pro 46.9%, and Terminal-Bench 2.0 40.7%. When I compare the Terminal-Bench 2.0 jump from 30.1% to 40.7%, it signals to me that the extra activated capacity directly translates to better reasoning in terminal-centric tasks.

The training infrastructure behind M.1 is equally aggressive. Poolside scaled 6,144 interconnected NVIDIA Hopper GPUs using their custom Titan training codebase. They also incorporated asynchronous on-policy reinforcement learning, which suggests they optimized the policy update pipeline to keep GPU utilization high without waiting on synchronous consensus steps.

Training Stack and Hardware Optimization

Beyond raw scale, the data strategy is what separates M.1 from a generic large-scale pretraining run. The dataset included approximately 4.4T+ tokens of synthetic data, and Poolside used AutoMixer to dynamically optimize the data mixture rather than relying on static blending heuristics. I also notice they implemented a distributed variant of the Muon optimizer, which is still relatively rare in production training stacks and indicates they prioritized update quality across their massive GPU mesh.

On the inference side, both models are tightly coupled to NVIDIA's ecosystem. XS.2 is supported from day one in NVIDIA TensorRT-LLM, and Poolside provides an NVFP4 quantized version specifically tuned for NVIDIA Blackwell architecture. M.1 weights aren't fully open, but they are accessible for institutional research upon request, which keeps the model available to academic and enterprise research groups without a full public release.

Known Issues and Beta Limitations — The Trade-Offs You Need to Know

When I evaluate the Poolside March 2026 release, the beta label feels justified. The platform ships with impressive capabilities, but several documented rough edges force you to rethink how you architect your workflows. The most disruptive issue I see is tool-call looping in Malibu 2.2 during long sessions. When you stack complex custom system prompts, load up numerous MCP tools, or simply let a session run long, the agent can fall into a cycle where it issues the same tool call repeatedly. Poolside provides guardrails that detect these looping patterns and interrupt execution with a warning, but in my view, that is a safety net, not a fix. You still need to simplify your prompts or reduce tool complexity to keep sessions stable.

Sandbox Gaps and File Handling Edge Cases

The sandbox model has teeth, but it is not bulletproof. I noticed that local sandbox execution cannot be strictly enforced—users retain the ability to run agents outside the sandbox, which breaks the isolation model if your team assumes containment is mandatory. Inside the sandbox, file handling exposes another weakness:

• Binary files in read-only mode may be incorrectly rendered or wrongly included in line-count diffs, which corrupts your change tracking. The workaround is manual: remove built binaries before using Apply Changes, or add them to .gitignore to keep diff calculations clean.
• Minimal default images: The bundled sandbox images ship with a sparse toolset, so do not expect common development utilities to be present out of the box. You will likely need to extend the images or accept that some standard tools are missing.

Registry Authentication and Approval Labeling

Infrastructure integration reveals two more friction points. Poolside Assistant cannot negotiate container registry authentication, meaning your runtimes must be pre-authenticated before the agent attempts to pull from private registries. There is no credential helper or login flow handled by the assistant itself, so you need to handle that plumbing beforehand. I also found that sandbox mode tool approvals can be misleading: some approvals may be incorrectly labeled as user-enabled unsafe auto-allow, which creates audit confusion because the UI suggests you explicitly opted into automatic execution when you did not.

Platform Storage and Model Constraints

At the platform level, trajectory storage is a hidden scalability tax. Because all execution trajectories are stored in the database, the storage footprint expands rapidly as usage scales. Poolside offers a pruning script for administrators to delete old trajectory data based on retention policies, but this is reactive maintenance, not a structural fix. On the model side, Laguna XS.2 is strictly text-in, text-out and offers no vision input support, so any workflow requiring image understanding needs to route through a different model entirely. Finally, performance is not automatic. It hinges on three variables:

1. The quality of your instructions and context provided to the agent.
2. The availability of tools for the agent to invoke.
3. Environmental validation, such as tests or executable checks, that let the agent verify its own output.

If your context is thin or your environment cannot verify its own output, the agent struggles regardless of the underlying model strength.

The Pros — What Pool Gets Right

When I look at Pool's architecture, the first thing that stands out is the absence of the usual demo-vs-reality gap. Pool is literally the same terminal agent that Poolside runs internally for agent RL training and evaluation of Laguna models. That production parity matters because the evaluation environment is identical to the training environment — there is no sanitized demo build hiding rough edges from the public release.

The configuration system reflects that same operational maturity. Pool uses a three-tier settings.yaml hierarchy — local overrides project, which overrides global — and organizes everything under six top-level keys: pool, tools, paths, secrets, mcp_servers, and sandbox. I see this as genuine defense-in-depth. By separating concerns across network policy, tooling, filesystem access, and secrets, organizations can enforce baseline policies at the global or project level while developers override sensitive configs locally. That structure prevents credential exposure in shared repositories without locking teams into rigid central control, and the six-key layout makes it obvious where to look when auditing agent capabilities.

Sandboxed Execution and Session Continuity

The sandbox implementation is where Pool shifts from configuration to enterprise-ready runtime. Each agent gets a disposable, reproducible container with controls that I would expect from a security-hardened CI pipeline:

• Workspace access: Configurable as read-only or read-write depending on the task risk.
• Filesystem mounts: Strict path requirements prevent arbitrary host access.
• Network egress: Three modes — off, allow-list, and unsafe-allow-all — with domain and CIDR filtering.

I view this granularity as essential for preventing lateral movement and data exfiltration. Too many agent tools default to full internet access; Pool treats unrestricted egress as an explicit opt-in labeled "unsafe," which is exactly the right security posture.

I appreciate that these sandboxes support session restoration when you switch conversations or restart your IDE. That design eliminates the painful environment rebuild overhead that typically comes with agent context switches.

Model Performance and Hardware Flexibility

On the inference side, Laguna XS.2 punches well above its weight class. It hits 68.2% on SWE-bench Verified while activating only 3B parameters. That efficiency makes local deployment actually practical — I can run it on a Mac with 36 GB of RAM via Ollama. For teams worried about cloud inference costs or data residency, that local viability is a genuine architectural option, not a theoretical checkbox.

Poolside backs that efficiency with open-weight licensing. Laguna XS.2 ships under Apache 2.0, which means community replication and extension are legally unambiguous. Hardware support is equally uncompromising: day-one integration with NVIDIA TensorRT-LLM and NVFP4 quantized versions targeting the Blackwell architecture. I notice they are not treating quantization or hardware-specific optimization as afterthoughts.

Editor Integration Without Context Switching

Finally, the ACP integration removes the usual friction of copying code between a chat UI and your editor:

• Native editor support: Running pool acp connects directly to JetBrains, Zed, and Neovim.
• Remote sessions: The agent can run on a remote machine while I control it from a local editor.

I find that split particularly useful — it keeps heavy inference or sandboxed execution off my laptop without forcing me into SSH juggling or browser-based terminals.

The Cons — Where Pool Falls Short

Pool ships as a research preview, and I can see that distinction matters when I compare the headline sandbox features against the day-to-day operational reality. Enterprise teams should treat this as an experimental toolchain rather than a production-grade platform. The APIs are still evolving, which means integration work done today might need refactoring tomorrow. That instability alone makes it hard for me to recommend dropping Pool into a critical-path CI/CD pipeline without extensive guardrails.

Sandbox Gaps and Security Ambiguity

The sandbox architecture is Pool’s central selling point, but when I examine the enforcement model, I notice a significant gap: local sandbox execution is not strictly mandatory. Agents can still run outside the sandbox if configured to do so, which means the isolation guarantee becomes optional rather than architectural. In scenarios where containment is actually critical—think untrusted code generation or third-party dependency execution—that opt-out capability undermines the entire security model.

I also spotted a labeling issue that complicates the trust model. Some sandbox mode tool approvals are incorrectly tagged as user-enabled unsafe auto-allow, which makes it difficult to audit what is actually running under explicit user consent versus what the system autonomously permitted. That confusion adds operational overhead because administrators cannot rely on the UI labels alone to assess the real security posture.

Then there is the container registry friction. Poolside Assistant cannot negotiate authentication against private registries, so runtimes must be pre-authenticated on the host before pulling images. For enterprises running hardened, private base images, this is a notable deployment blocker that forces infrastructure workarounds before the agent can even start.

Tooling Loops and Storage Bloat

In longer sessions, Malibu 2.2 exhibits a frustrating tendency to fall into repetitive tool-call loops. I see this pattern intensify when developers layer complex custom system prompts or load numerous MCP tools into the context. The current workarounds—activating guardrails and simplifying prompts—are functional but tedious. They shift the burden onto the user to keep the agent focused rather than fixing the root cause in the model’s trajectory planning.

The default sandbox images compound the friction. They ship with a minimal toolset, so most real-world development environments require heavy customization before they become usable. There is also a rendering bug: binary files created in read-only mode may be incorrectly displayed or erroneously included in line-count diffs, which pollutes code reviews and makes output harder to trust.

On the infrastructure side, trajectory storage grows without bound. Every execution path is persisted to the database, and without automated retention policies, the storage footprint expands rapidly. Administrators are left with only a manual pruning script to keep the database healthy, which feels like an afterthought rather than operational hygiene.

Model Limitations and Environmental Dependency

Laguna XS.2 is strictly text-in, text-out. When I look at modern coding workflows that increasingly rely on screenshots, diagrams, and UI mockups, the absence of vision support stands out as a real limitation. Multimodal coding tasks are simply off the table.

Performance itself is tightly coupled to environment quality. The agent’s output is only as good as the instructions, context, and validation tooling—such as test suites or executable checks—that surround it. In poorly configured environments, Pool produces poor results, which means it demands upfront investment in dev environment hygiene rather than working out of the box.

Finally, model access remains restricted. Laguna M.1 weights are available only to institutional researchers upon request, and both Laguna variants are currently accessible through Poolside’s API and OpenRouter during a limited free preview. There is no long-term pricing clarity yet, which makes budget planning impossible for teams considering adoption.