Poolside launches Desktop Assistant for supervising coding agents

• Poolside shipped a macOS Desktop Assistant plus IDE assistants for VS Code and Visual Studio; the launch announcement says the tool is now public after a year of internal use.
• The product frames long-running agent work as supervision of sessions; Poolside's ACP framing says compatible agents can run without a Poolside server.
• The core workflow pieces are parallel agents in isolated Git worktrees and session handoff with context preserved, according to Poolside's feature list.
• Poolside is using the app to showcase Laguna S 2.1 with pool, plus offline Laguna XS 2.1 through MLX, according to Poolside's model note.
• Zed framed the launch as an ACP interoperability proof point; Zed's post says Laguna models power an ACP agent while Poolside's desktop app is an ACP client for public-registry agents.

Poolside's launch post includes the practical handoff case: start a plan in one agent, implement in another, review with a third, or switch after a rate limit. The ACP introduction defines the seam as editor-to-agent communication, with local agents over JSON-RPC stdio and remote agents over HTTP or WebSocket. The pool CLI docs make the same harness span terminal sessions, pool exec, ACP editors, MCP servers, and skills. Sebastian Raschka's architecture notes put Laguna S 2.1 at 118B sparse MoE parameters, 8B active, with 36 sliding-window and 12 global gated-GQA layers.

Poolside initially described Desktop Assistant as one place to run coding agents across macOS, VS Code, and Visual Studio. Poolside's clarification narrowed the naming: Poolside Desktop Assistant is the macOS app, while Poolside Assistant covers VS Code and Visual Studio.

The launch path is direct: Poolside's availability post points to downloads, the product post, and a Discord channel for bugs, feedback, and feature requests.

ACP is the load-bearing bit. The terms map cleanly to the ACP introduction: ACP standardizes communication between code editors or IDEs and coding agents, with local agents running as editor subprocesses over JSON-RPC stdio.

The same docs say ACP reuses MCP JSON representations where possible and adds coding-agent UX types such as diffs. Poolside's interface note put the product principle plainly: the interface should be independent of the model or harness.

Zed's post adds the ecosystem angle. Laguna models power an ACP agent that can run in ACP clients, including Zed, and Poolside's new desktop app is itself an ACP client for agents in the public registry.

Poolside's workflow primitives are small enough to list:

• Agent mix: pool, Claude Code, Codex, and Gemini in one workspace.
• Parallelism: multiple agents can run at once.
• Isolation: each agent can work in its own Git worktree.
• Handoff: a session can move to another agent while keeping context.

Poolside's launch post gives the fuller version: conversations sit beside terminals, files, diffs, and repo state, with layouts built around operating agent sessions instead of scrolling through one column.

Out of the box, Desktop Assistant pairs Laguna S 2.1 with pool, the agent harness Poolside says it uses for reinforcement learning and evaluation. The same post says Laguna XS 2.1 can be downloaded in the app and run fully offline with MLX.

The pool CLI docs describe pool as a coding agent for interactive terminal sessions, one-shot pool exec tasks, ACP-compatible editors, and ACP client use against other agent servers. The same docs list file edits, command execution, MCP servers, skills, approval prompts, permissions, and sandboxes as part of the harness.

Laguna S 2.1 is a 118B total parameter MoE with 8B active parameters per token and a 1M-token context window, according to Poolside's model release post. rasbt's notes add the practical sizing detail: Laguna S 2.1 used under 80 GB of RAM on a DGX Spark in his test.

One early hands-on report called onboarding easy and showed live switching between Codex, Poolside Local, and Poolside. The attached screenshot also exposes the supervision surface Poolside is aiming for: token usage, Codex weekly-limit status, agent handoff markers, command logs, and a failed shell command blocked by user denial.