Containing Agent Chaos: Make the Environment Independent

From delivery scripts to teams of agents

Platform engineers build polished tools for developers, yet often assemble their own delivery machinery from Bash scripts and YAML. Solomon Hykes identifies that mismatch as Dagger’s starting problem: the people responsible for developer productivity need better tools for building, testing, and moving saved code toward production.

Dagger is an open-source workflow engine that turns this delivery work into modular, code-driven workflows running in containers. Those workflows can run locally or in continuous integration (CI), where automated builds and tests execute. Its core community consists of platform engineers—the people who build and operate tools that make other developers productive.

Users pulled Dagger into AI by inserting large language models into workflows and running agents in CI. Hykes sees a broader transition behind those experiments: supervising several coding agents becomes platform engineering. Developers increasingly need to provide environments and enable other workers to be productive.

His example is a livestreamed coding session with AI. When work shares one development environment without clean isolation, changes effectively proceed one set at a time. Adding agents leaves that bottleneck in place. Dagger is adapting its delivery technology to give agents isolated, reusable environments that can move independently of a particular app, model, or cloud provider.

Keep containers; make the environment portable and inspectable

Hykes compares agent platforms with the early cloud market: integrated services offered a complete experience, but users could not easily carry their working environments elsewhere. His recommendation is to retain containers as the base isolation layer and redesign the development tools around them.

His criticism is partly self-directed. In his account, Docker failed to follow through on development tooling while the surrounding ecosystem kept advancing infrastructure such as Kubernetes, storage, and networking. He acknowledges dev containers and other experiments, but argues that development interfaces remained fragmented around Dockerfile and Docker Compose. He sees developers’ continued preference for working directly on laptops as a failure to make container tooling compelling enough.

For agent environments, he proposes four requirements: - Isolation for parallel work: agents can work simultaneously without interfering with one another. - Portability across tools and providers: environments can move between models, clouds, and development editors. - End-to-end observability: model activity and outputs, tool execution, and environment state are visible together. - Shared human and agent access: a person can take over the environment to verify an agent’s claim of completion. These describe the intended experience, not a claim that every capability is already implemented.

Hykes sees vendors moving toward vertical integration instead. An editor adds proprietary environment customization, then observability, then hosting for background agents. Each addition answers a customer request; together they bind the working environment to one platform. The proposed standardization boundary is the environment in which the agent works: an independent component connecting the surrounding tools.

Running a command does not preserve its setup

An interviewer describes directing an editor’s coding agent to execute commands through docker compose exec. The agent changes the running container, but those changes do not propagate back into the Dockerfile or Compose configuration. Its environment setup work is left unpreserved. Changing an environment and recording how to recreate it are separate operations in this workflow.

A participant speaking from Docker’s original design team describes Dockerfile as a 2013 stopgap and Compose as an acquired tool stitched on top. Rapid adoption created pressure to freeze the syntax because other platforms already depended on it. Maintaining those interfaces preserved compatibility, but also constrained their evolution.

The proposed redesign starts with how people develop alongside agents, then builds on existing foundations such as containers, Git, and the OpenAI API specification and its derivatives. Dagger is the vehicle for exploring that experience, including the balance between simplicity and modularity. The container example exposes one requirement: environment changes need a path back into reusable setup.

Compose workflows without rebuilding everything

An interviewer connects this to their experience with Temporal, a workflow orchestration system, and a similar move from specialized configuration languages toward TypeScript or Go. But language choice addresses only part of the problem. A development workflow evolves alongside its product, like a factory designed around the things it makes.

Workflow tooling has two opposing failure modes: - Excessive flexibility leaves users rebuilding everything. A general tool saves little effort if each team must assemble its system from scratch. - Excessive simplification blocks integration. A streamlined tool becomes unusable when it cannot accommodate the team’s existing systems.

The Lego analogy captures the dual design responsibility: make each component useful while designing the larger system those components form. A new standard must repay its adoption cost. It adds another dependency to maintain, so it needs to save effort, money, or something else the team values.

Agent loops also bring orchestration and software delivery closer together. They are asynchronous, event-triggered processes that need somewhere to run. One participant distinguishes Temporal’s focus on running applications from CI systems’ focus on delivery; the response predicts convergence. Workflows will invoke language models, models will invoke workflows, and CI already provides events, job dispatch, and compute.

Coding agents make that overlap concrete. Running an agent is a runtime problem, but its priorities differ from real-time voice or video. The emphasis here is repeatable artifacts and traceable creation: how was a binary produced, can that process be repeated, and did unexpected model behavior affect it?

Isolation needs both execution and files—and a local test

The interviewer introduces a constraint from conversations with founders building short-lived, sometimes single-use apps. Setup time, teardown time, resource consumption, and cost become especially consequential when applications are quickly created and discarded. Those founders reportedly found existing tools too slow or expensive at the required granularity, pushing some toward shortcuts and away from containers.

Parallel coding requires two complementary forms of separation: - Containers isolate execution: agents run tools in separate environments. - Git worktrees isolate files: agents work in separate file trees. The remaining engineering problem is connecting these mechanisms into a coherent environment. Either piece alone leaves assembly work for the developer.

Hosted vendors have an incentive to optimize how quickly and cheaply environments run on their own infrastructure. The concern raised here is that this makes developers’ local execution an afterthought. A hosted service can succeed commercially while solving only part of the environment-standardization problem.

The proposed test is whether developers can run the environment locally and enjoy using it. Local execution is only one requirement, but it tests the ambition to become ubiquitous. Attempts to reproduce GitHub Actions locally illustrate the compatibility burden when local operation must be reconstructed around a hosted system.

Earn adoption while remaining a component

Asked what would persuade a major cloud or model lab to adopt Dagger, the response makes no adoption prediction. The interviewer reports a Microsoft team’s interest in extending Dev Container and worries about fragmentation. The answer favors competition on interface quality: small teams can compete on developer experience more readily than on foundation models, where the speaker believes scale strongly favors a few contenders.

A useful interface still needs an ecosystem. Microsoft is described as having a distribution advantage, but startups can build a solution, attract users, and gain momentum without waiting for an incumbent’s permission.

Dagger’s product tradeoff follows from that modular ambition: it remains a component of a larger platform. Its goal is to compose portable environments and workflows while adapting to a team’s authentication, interface, storage, and networking choices. Providing a complete platform would require customers to adopt Dagger’s choices in those areas.

Two boundaries make that division concrete: - Existing CI supplies runners. Dagger runs on top of the CI platform, aiming to simplify it into infrastructure that executes jobs. - Other systems supply authentication. Teams choose their authentication solution; Dagger promises to integrate with it.

The environment bounds the agent’s freedom

The closing exchange returns to building coding agents. The interviewer says Dagger’s workshop proposal clarified its direction, then imagines language models generating their own infrastructure. That prospect raises concerns about spending and unrestricted access to an AWS account. The response makes environment control a way to decide how much freedom an agent receives.

The June 2025 companion preview advertised three conference appearances: - Tuesday: a workshop on building software engineering agents. - Wednesday: a talk on trusting agents with software delivery. - Thursday: Solomon’s “Containing Agent Chaos” keynote.

The recording closes with a conditional teaser: the keynote speaker estimates a 50% chance of having additional unreleased material ready beyond the workshop. Its appearance depended on finishing in time.