Updated 3 days ago
Docker’s BAND kit brings local agents into shared collaboration rooms

Docker’s BAND kit brings local agents into shared collaboration rooms

Docker’s October 21 walkthrough connects a repository agent in a sandbox to people and remote agents through BAND rooms. Model choice, credentials, workspace tools and network access remain distinct setup decisions.

A shared room connects agents running in different places

Docker’s [October 21 walkthrough](https://www.docker.com/blog/band‑ai‑agents‑docker‑sandboxes/) introduces an official BAND AI kit for Docker Sandboxes. It connects a local repository agent to a BAND room where humans and other agents can collaborate, including agents running in the cloud or on other infrastructure. BAND supplies identities, shared rooms, message history, tool‑execution events and work routed through `@mentions`. Each participant can bring its own model, framework, tools and workspace. The integration’s reader consequence is a common collaboration surface for agents whose execution environments remain separate.

The repository stays with the participant that needs it

The [example uses Repo Doctor](https://github.com/dockersamples/band‑ai‑sbx‑demo), a Python agent running against a local project in a Docker Sandbox. Docker describes separate sandboxes as separate microVM environments, each with its own kernel, filesystem, Docker daemon and network. The local agent can work in its mounted workspace while other room participants run elsewhere. In the post’s larger‑team example, only Repo Doctor needs access to the local repository. A planner or research agent can mention it when work reaches that repository. The room routes the request; the local participant’s configured tools perform the work. This is an integration pattern, not independent evidence that a room or sandbox prevents every unwanted action.

The connection and credentials still need configuration

According to the [walkthrough](https://www.docker.com/blog/band‑ai‑agents‑docker‑sandboxes/), the sandbox opens an outbound WebSocket connection to BAND and posts replies through its API. The described arrangement does not require another participant to initiate a connection into the sandbox. Docker says its secret‑handling mechanism keeps real keys on the host, inserts them into outbound requests and exposes placeholders to the agent, with credentials scoped to the sandbox. Those are Docker’s documented design statements, not an OpenTools security audit. The sample also adds network permission for the chosen model API. Joining a room should therefore be distinguished from configuring the agent’s credentials, network access and workspace tools.

Claude is the example’s choice, not a kit requirement

To reproduce the [published example](https://www.docker.com/blog/band‑ai‑agents‑docker‑sandboxes/), Docker lists an installed, signed‑in Docker Sandboxes environment, a BAND account and an Anthropic API key with API credits. The BAND agent key authenticates the platform connection. The post explicitly says the kit itself does not require a particular model provider. Its `band.yaml` identifies the agent and Python entrypoint. The demonstrated entrypoint uses Claude, while another implementation can use BAND adapters for coding agents such as Claude Code or Codex with the required tools and authentication configured. OpenTools has not created accounts, supplied keys or run this example.

Keep the example version and policy evidence with the setup

The [post](https://www.docker.com/blog/band‑ai‑agents‑docker‑sandboxes/) introduces the image as `bandhq/band‑python‑kit:latest`, while its create command uses the concrete tag `6.0.0`. Those are different references; the walkthrough does not establish that a mutable `latest` tag will always resolve to the sample version. Docker points readers to the [kit documentation](https://docs.docker.com/ai/sandboxes/customize/kits/) for configuration, credentials and network rules, and recommends checking `sbx policy log` against the intended network policy. Its page was published October 21 and records an October 23 modification time; that timestamp does not identify which feature changed. This report describes the retained integration and access requirements without claiming a tested runtime, productivity gain or isolation guarantee. *Docker’s LinuxCon 2016 booth, photographed August 22, 2016. Archive company‑context photo; not the BAND kit demonstration, its developers or a current product interface. Photo: [Open Grid Scheduler / Grid Engine (Raysonho)](https://commons.wikimedia.org/wiki/User:Raysonho), via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:DockerLinuxConBooth.jpg); [CC BY‑SA 4.0 International](https://creativecommons.org/licenses/by‑sa/4.0/deed.en). Resized and cropped for display; image adaptations retain the same licence.*

Share this article

PostShare

Related News