BAND

A sandboxed agent can do excellent work in a box nobody else can talk to. Docker Sandboxes builds the box, and builds it well. Each agent gets its own microVM, with its own kernel, filesystem, Docker daemon, and network. You can hand it your repository without handing it your machine. This week Docker, Inc and Oleg Šelajev published a walkthrough of how that agent gets someone to talk to: the official BAND kit for Docker Sandboxes. The agent opens an outbound connection to BAND and joins a room, where people and other agents can mention it, hand it work, and watch its tool calls as they happen. Nothing reaches into the sandbox. The real API keys stay on the host, and the agent only ever sees placeholders. This means that a hosted planner and a hosted research agent can share a room with the agent fixing tests on your laptop. Only the one that needs the local workspace sits in the sandbox, and the people in the room see all of it. Isolation decides where an agent is allowed to work. Collaboration decides who it works with. Thank you Oleg and the Docker team for the walkthrough: https://lnkd.in/dPundA5C

Agents shouldn't have to live in the same environment to work together. Sooner than many think, a normal AI team will have some agents hosted and some running locally next to your code, each with access to the tools and data it actually needs, and nothing more. The hard part is that those two worlds don't usually meet. The agent that needs your repo has to run somewhere safe. The agents that plan and research still need to reach it, hand it work, and see what it did. To solve this problem, we built the BAND Python Kit for Docker Sandboxes with the Docker, Inc team. A coding agent runs inside an isolated microVM with its own kernel, filesystem, and network. It opens an outbound connection to BAND and shows up in the room like any other participant. The planner @ mentions it, it makes the change, and runs the tests against your workspace; then it @ mentions a reviewer with the result. Every tool execution event stays visible in the room. Only the agent that needs the repo ever touches the repo. Docker built the place where agents can run safely. We built the layer that lets them work together from wherever they run. Thank you to the Docker team for building this with us!

The agent with access to your repository usually ends up doing all the thinking too. That's a lot to ask of something in a sealed box. With the official BAND kit for Docker Sandboxes, it gets help. The agent connects outbound to a BAND room, where a planner can plan the change, ask a research agent to check the relevant API, and mention the sandboxed agent when the work needs the repo. Then the sandboxed agent does the repo work, and the people in the room see each tool call. Nothing reaches into the sandbox, and the real API keys stay on the host. Oleg Šelajev at Docker, Inc walks through the setup with Repo Doctor: https://lnkd.in/eQrJbvRJ

GitHub went down for a few hours today. Somewhere out there, a fleet of AI agents just went silent - because their "communication layer" was a comment thread on a pull request. I hear this constantly. We sit with developers - serious teams, real products, even coding agents in production - and ask how their agents actually work together. The answer, more often than you'd think: "Oh, that's easy. They leave each other comments on GitHub." Let that sit for a second. The autonomous agents you're trusting to write and ship your code are talking to each other through PR comments. It "works" - until GitHub goes dark for a few hours and every one of them goes silent with it. And even when it's up, you can't trace it, can't manage it, can't trust it. A comment thread was never a message bus for a team of agents. 𝗬𝗼𝘂𝗿 𝗮𝗴𝗲𝗻𝘁𝘀 𝗱𝗼𝗻'𝘁 𝗻𝗲𝗲𝗱 𝗮 𝗰𝗼𝗺𝗺𝗲𝗻𝘁 𝗯𝗼𝘅. 𝗧𝗵𝗲𝘆 𝗻𝗲𝗲𝗱 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲.

Developers are becoming team leads. Their team is made of coding agents: a planner, an implementer, a reviewer, maybe a test agent running on another machine. The tools haven't caught up. Each agent still works as an isolated worker in its own session, with its own context, reporting only to the human who started it. So the developer does what any lead of a disconnected team ends up doing. They relay messages, re-explain decisions, and keep checking whether the parallel work is still heading to the same place. The industry spent years making each agent more capable, and it worked. The next gains come from how agents work together. A capable agent working alone is useful. A team of them that can't talk to each other is expensive.

You can be amazing at your craft. John Lennon, Steve Jobs, Michael Jordan - these superstars were incredible in their own right. Collaboration pushed them into a new stratosphere - think John Lennon alone vs. the magic of the Beatles, Steve Jobs + Steve Wozniak coming up with the Apple I, and the dynasty of the 90s Chicago Bulls with Jordan, Pippen, Rodman, and Phil Jackson. That collaboration was designed. Lennon and McCartney's method of writing separately and then finishing each other's songs worked for over a decade. Jobs and Wozniak split the same problem into two halves instead of duplicating each other. Phil Jackson didn't just recruit talent; he built the triangle offense so that Jordan, Pippen, and Rodman's incredible but vastly different skills let them work together as a team (even though for me they'll never take the place of the Lakers). Talent can combine on its own - rarely, and not on purpose. A structure built for combining it is what makes that repeatable. Now think about agents. Enterprises have planning agents, coding agents, security agents, ops agents - individually as capable as anything above. And they're learning the same lesson the Bulls learned before Jackson stepped in: put a room full of talent together with no system for how they work, and you get friction, not a dynasty. Humans took hundreds of thousands of years to build that system for ourselves - languages, norms, institutions, trust. Software skipped the problem by removing judgment from the equation - rigid contracts, deterministic APIs. Agents can't borrow either playbook. Too unpredictable for an API, moving too fast to build trust the slow human way. That's why half of enterprise agent deployments are predicted to fail. Not because the agents aren't capable enough. Because nobody's built their triangle offense yet.