# Containing Agent Chaos

Solomon Hykes, Dagger | AI Engineer World's Fair 2025 | 23:48

Source: https://www.youtube.com/watch?v=bUBF5V6oDKw
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/containing-agent-chaos
Published: 2025-06-28
Tags: agents, coding-agents, computer-use, harness-engineering, mcp

## TL;DR
- Coding agents need platform engineering because running many agents makes shared environments, manual supervision, and delayed code review break down.
- Container use gives each agent an isolated, repeatable environment for files, configuration, tools, and execution, rather than only sandboxing its output.
- Immutable snapshots stored with Git let engineers inspect, compare, discard, merge, and resume agent work without cleaning up failed experiments.

## Summary
Solomon Hykes argues that coding agents create a platform engineering problem. One agent can be watched, but a group of agents quickly conflicts when they share files and environments. Fully managed agent services avoid some setup while limiting the engineer's choice of models, compute, and tools. Hykes wants a middle ground where agents can work in the background, follow project-specific rules, and remain available for direct intervention. His proposed foundation is container use. Each agent develops inside an isolated environment, and each action runs in an ephemeral container that is then snapshotted. Files and container state are persisted in Git objects alongside the repository. This lets an engineer inspect the agent's environment, watch its history, discard a bad branch, or merge a useful result. The Dagger-backed demonstration also shows that these environments can run locally, on a remote machine, or from CI. The software is unfinished, and the demo makes that clear.

## Key ideas
### A team of coding agents turns ordinary development into platform engineering
[02:01](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=121s)
Hykes says that using coding agents changes the engineer's job. Instead of only building and shipping software, the engineer now has to enable robots to do that work productively. A single agent can operate in a computer environment, but it may also do something "very crazy," so the current approach is to watch and approve its actions. That breaks down when the number of agents grows. Running ten agents in "yolo mode" makes them step on each other's toes because they share an environment. Fully managed background systems solve some of the operational work, but they can leave the engineer waiting for a pull request and unable to intervene at the right moment.

### A useful agent system needs background work, guardrails, intervention, and choice
[05:52](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=352s)
Hykes describes the workflow he wants for a team of agents. Work should happen in the background, while project rules constrain what the agents do. Those rules can cover the project's context, coding style, tools, build process, tests, base image, and permitted secrets. The engineer also needs a practical way to step in without watching every action or waiting for a pull request. Hykes adds optionality because models, compute providers, and agent tools are changing quickly. He does not want to lock the team into one complete package. The environment therefore needs isolation for background work, customization for the rules, multiplayer access for collaboration, and an open design that allows different components to be chosen.

### Container use gives the agent a development environment, not just a security sandbox
[08:38](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=518s)
Hykes introduces Dagger's idea of "container use," alongside terms such as computer use and browser use. The agent can create an environment and work inside it, rather than producing code that is only executed later in a separate sandbox. He draws a distinction between securing an agent's output and having the agent develop inside containers throughout its workflow. The approach is intended to work with existing coding agents instead of replacing them. In the demonstration, the same containerized environment can attach to Claude Code, Codex, or another agent, from an IDE or command line and also in the cloud or CI. The container is the portable environment around the agent's work.

### Every agent action runs in an ephemeral container and produces a snapshot
[12:26](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=746s)
In the demonstration, the agent creates an environment, edits files inside it, builds the application, tests it, and runs it in ephemeral containers. Hykes stresses that this is not one Docker container left running. Each action starts a container, then snapshots it and returns the result. The agent can determine the environment it needs, such as the Go version, and configure that environment in a repeatable containerized way. Hykes inspects the environment through a terminal and sees the files and tools available to the agent. The workspace remains clean by default because the work happens in a sandbox. The state of the files and containers is persisted locally in special Git objects alongside the repository.

### Git history creates a workable collaboration loop between supervision and delayed review
[16:06](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=966s)
Hykes uses Git history to make the agent's work inspectable. Each snapshot appears in a history that behaves like a Git log, so the engineer can see what happened and choose a result. The workflow sits between two uncomfortable options. The engineer does not need to watch every tool call while agents modify a shared environment. The engineer also does not need to wait for a pull request before seeing whether the work is useful. An environment can be merged when its result is acceptable. If an experiment is wrong, the engineer can discard the environment instead of cleaning up its changes. Multiple experiments can branch from the same state, then be compared, applied, or merged.

### Isolation includes execution and configuration, and it can span local or remote infrastructure
[20:38](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=1238s)
Hykes defines isolation broadly. It covers the files, context, configuration, and execution of an agent. When an agent runs a service, the service stays in its containerized environment and is tunneled to the engineer's machine on another port, avoiding conflicts. The demonstration itself runs on a home server rather than the conference computer, with files streamed between the remote environment and the machine on stage. Hykes says the same setup can run on a cluster or from CI. This gives the environment a portable execution model without requiring the engineer to use one hosted service. Secrets can also be plugged into an environment from a password manager such as 1Password, although he does not demonstrate that part.

### The proposed tool is deliberately an integration layer around existing agents
[19:03](https://www.youtube.com/watch?v=bUBF5V6oDKw&t=1143s)
Hykes is careful to explain that Container Use is not a coding agent. It provides portable environments that can attach to the agent an engineer already prefers. In the demo, the integration starts through MCP, while other integrations are being developed. Dagger supplies the underlying container primitives, and the command-line experience adds a small amount of glue around Git and the chosen agent. Hykes describes the design as open source and shows a command for listing environments, opening a terminal, and viewing history. The user can choose an IDE, command line, local machine, remote server, or CI. The agent remains replaceable because the environment layer is separate from the model and its user interface.

## Notable quotes
- "The famous definition of course is it's an LLM that's wrecking everything in a loop on behalf of a human." (03:47)
- "I want a middle ground here and the fourth thing is I want optionality." (06:51)
- "Every time an action needs to be taken, there's an ephemeral container running and then being snapshotted and returning." (13:13)
- "When I say the environment's isolated, it's the files, its context, its configuration and its execution." (21:03)
- "We did not solve prompt engineering." (21:27)

## Tools & references mentioned
- Docker
- Dagger
- Container Use
- MCP
- Git
- Claude Code
- Codex
- Goose
- 1Password

## Who should watch
- You are running multiple coding agents and shared files or environments are creating conflicts that are hard to clean up.
- Your team wants agents to work asynchronously while retaining a direct way to inspect, interrupt, discard, or merge their work.
- You want to use different models, agent clients, compute providers, or CI systems without adopting one all-in-one hosted platform.

## Related talks

- [Agents, codebases, and teams](https://aietalks.com/talks/agents-codebases-and-teams) (Aditya Khandelwal, Amazon AGI Lab, 16:57)
- [Develop at Idea Velocity](https://aietalks.com/talks/develop-at-idea-velocity) (Jeffrey Lee-Chan, Snapchat, 15:28)
- [Conquering Agent Chaos](https://aietalks.com/talks/conquering-agent-chaos) (Rick Blalock, Agentuity, 14:40)
- [Making Codebases Agent Ready](https://aietalks.com/talks/making-codebases-agent-ready) (Eno Reyes, Factory AI, 15:33)
- [CI/CD Is Dead, Agents Need Continuous Compute and Computers](https://aietalks.com/talks/ci-cd-is-dead-agents-need-continuous-compute-and-computers) (Hugo Santos, Namespace & Madison Faulkner, NEA, 18:37)