BAND connects local coding agents to its network through Docker Sandboxes

Why it matters

BAND is testing whether developers will adopt a separate coordination layer for agents that run in different places, including the local agent that can change real code. The kit's published setup guide also shows the gap between an announced integration and a production-ready workflow.

BAND connected its multi-agent collaboration platform to Docker Sandboxes on September 24th, according to its announcement, giving a coding agent running beside a developer's local code a way to communicate with hosted agents and people in a shared room. CEO and co-founder Arick Goomanovsky is extending BAND's central bet: agents will be distributed across different environments, and they will need a common way to coordinate.

Goomanovsky has built infrastructure companies before. He co-founded cybersecurity companies Sygnia and Ermetic, both later acquired, before starting BAND. His earlier experience in cybersecurity and infrastructure helps explain why this integration pairs agent-to-agent communication with controls around where code runs and which credentials an agent can reach.

The announcement describes a BAND Python kit for Docker Sandboxes that connects a sandboxed agent to a BAND room. An outbound WebSocket connection makes the agent a room participant, where it can receive messages, be routed work through @mentions and report execution events. BAND supplies the shared rooms, identities and communication layer; Docker Sandboxes supply the microVM in which the local coding agent runs.

That division of labor addresses a practical gap in multi-agent workflows. A hosted planner or research agent may not need access to a developer's repository. A coding agent does. With the proposed setup, the hosted agents can plan or investigate and pass work to the local agent, which can change files and run tests in its sandbox, then return results to the room. BAND says the setup avoids building separate routing, identity and communication infrastructure for the local agent.

The founder's bet moves closer to the code

Goomanovsky has described BAND as infrastructure for agents that may be hosted, local or spread across different environments. In the announcement, he said, "Agents shouldn't have to live in the same environment to work together." The Docker integration makes that thesis concrete: an agent with access to a local repository can join the same workflow as agents that never touch it.

That is a different job from building another agent framework. BAND positions itself as a layer that can sit across frameworks and environments, while Docker provides the execution boundary. BAND's existing materials list support for tools and frameworks including LangGraph, Claude, OpenClaw and CrewAI. The commercial question is whether engineering teams will add a separate collaboration and governance layer on top of the frameworks and runtimes they already use.

Goomanovsky's co-founder and CTO, Vlad Luzin, brings a background in distributed systems. Before BAND, Luzin led AI and cloud platform work at Verint, held senior product and engineering roles at CME Group, and led a multi-agent AI incubation team at Samsung Telecom Research, according to his Team8 profile. That experience fits BAND's infrastructure-first approach: make agents built and hosted in different places behave like participants in one workflow.

BAND came out of stealth in April with $17 million in seed funding from Team8, Hetz Ventures and Sierra Ventures. The funding gave the founders capital to build the interaction layer; the Docker kit is a more specific test of whether developers will use it to bridge the boundary between hosted coordination and local execution. The round's valuation was not disclosed.

The kit is available; the setup still needs care

Docker's sandbox product already targets coding agents that need to work with real development files while running inside isolated microVMs. Docker says each sandbox has its own kernel, filesystem and Docker daemon, with network access governed by policy. The BAND integration adds a path for an agent in that environment to communicate with agents outside it. Docker's product overview describes Sandboxes as a way to run coding agents with control over network access and a separate execution environment.

There is a gap between the announcement's one-command description and the currently published setup instructions. BAND's Docker guide labels the sandbox kit an evolving surface, says the published 3.1.1 kit is rejected by Docker Sandboxes versions 0.42.1 and 0.43.0, and provides a compatibility workaround. Its starter example is a deterministic echo bot, not a reasoning agent; developers are instructed to replace it with their own runnable Python agent. The kit is available, but the guide shows that getting from the package to a working agent can require more than connecting an existing model with one command.

The security boundary also has a defined job. The release says network access is deny-by-default and credentials can be managed through a host-side proxy instead of placed directly in the microVM. That can reduce direct exposure of secrets, but it does not answer how the integration performs under real workloads, how reliable its WebSocket connection is, or how much operational work production deployments require. BAND has not named customers or deployments using the Docker integration, and the announcement gives no usage or adoption figures.

The BAND Python SDK and Docker kit provide developers with a route to try the architecture. For Goomanovsky, the strategic step is clear: BAND is extending its coordination layer to the agent that has the most sensitive job in the workflow, the one that can read and alter a local codebase. Whether that becomes a useful shared layer for engineering teams will depend on the details the launch announcement does not measure yet: setup friction, security controls in practice and sustained use beyond a demo.