Dagger lets teams define containerized software workflows as code and run the same workflows locally or in CI.
2
Agents become more reliable when they receive a focused set of tools, use existing build and test functions, and work inside isolated environments.
3
A Dagger agent can turn a GitHub issue into a pull request by reading the issue, editing code, running tests, and pushing the result through GitHub Actions.
Summary
Kyle Penfound and Jeremy Adams build a software development agent with Dagger during a hands-on workshop. They start with a project that has Dagger functions for building and testing an application, then add a workspace module with tools to list, read, and write source files. The agent receives an assignment, a focused tool environment, and a prompt that tells it to inspect the project, avoid unnecessary changes, run tests, and continue until the assignment is complete. Dagger runs the work in sandboxed containers and returns an immutable completed workspace. The workshop then connects the agent to GitHub. A GitHub issue labeled "develop" triggers GitHub Actions, which runs the Dagger function and opens a pull request. The speakers also show tracing in Dagger Cloud, cross-language module use, nested Dagger agents, and MCP exposure. Their practical argument is that existing delivery workflows can give agents useful limits and validation without removing their ability to choose how to solve a task.
Kyle Penfound describes Dagger as both a container runtime and a workflow engine. Teams can use it to orchestrate containers and tasks for CI/CD, with the same workflow running on a laptop, in Kubernetes, or in GitHub. Jeremy explains the difference from Docker: Docker originally focused on making one application portable, while Dagger makes a whole workflow portable. The workflow can contain multiple containers and other objects, with everything sandboxed by default. Dagger code can be written in Go, Python, TypeScript, Java, or PHP, and modules written in different languages can interoperate through native bindings.
Existing build and test code can become the agent's tools
The workshop starts with a Hello Dagger application and adds functions that know how to build and test it. Those functions are useful to developers and CI, but they can also be passed to an agent. The agent can run the actual project test function instead of guessing which command to use. This gives it a way to check generated code, receive test failures, and iterate. The speakers connect this design to the large pull requests created by AI coding tools, including an example of a 25,000-line pull request that kept changing while someone reviewed it. They argue that automated build, test, and validation workflows are needed to handle that volume of generated code.
An agent needs a focused environment rather than every available tool
Kyle and Jeremy create a separate workspace module for the agent. It exposes only the operations needed for the demo: list files, read a file, write a file, and run tests. Kyle says the agent needs enough tools to choose its own path through a complex task, but too many tools can make it generalized, confused, and unreliable. The right scope depends on the task. Dagger modules can be installed as dependencies, so teams can reuse specialized modules from the Daggerverse instead of writing every capability themselves. The workspace becomes the agent's playground, with a deliberate boundary around what it can change.
The agent is a typed function with an environment and a prompt
In Dagger, the agent is another function, called develop. It takes an assignment and a source directory, with the repository supplied by default when no source is passed explicitly. The function builds an environment containing the assignment, the workspace tools, and a workspace output called completed. Dagger objects are immutable, so the input workspace remains unchanged while the agent produces a new completed version. The speakers describe this as connecting a brain to a robot body: the environment contains tools, inputs, outputs, and state, while the LLM receives that environment along with the task prompt.
Prompt instructions and validation keep the agent on track
The develop prompt tells the model that it is working as a developer on the project. It must inspect the workspace before writing code, avoid unnecessary changes, run the tests, and continue until the assignment is complete and the tests pass. The speakers say these instructions come from observing how agents fail. Dagger Cloud shows the prompt, available objects, tool calls, arguments, and returned values, which helps them revise tool descriptions and prompts. After the agent returns a completed directory, the Dagger function runs the test function again before exporting the result. This creates a final check before changes reach the developer's disk.
Container isolation lets agents work without changing local state
The agent edits files inside a Dagger container rather than directly modifying the developer's filesystem. Kyle says this allows multiple agents to work in separate sandboxed workspaces without interfering with local state. The same environment can include the tools needed by the workflow, such as Python for the Dagger code and Node for the application. A laptop only needs Dagger and an internet connection because language runtimes and other dependencies are supplied through containers. The result can be inspected, built, or served before it is exported back to disk. Dagger Cloud provides a visualization of the run, but the work itself still runs locally in the Dagger engine.
A GitHub issue can trigger an agent-generated pull request
The workshop wraps the develop agent in a develop issue function. It reads a GitHub issue, uses the issue body as the assignment, passes the repository source to the agent, and turns the completed directory into a pull request. The GitHub issue module supplies functions for reading issues, comments, and pull requests. A short GitHub Actions workflow runs when an issue receives the develop label. It passes the issue ID, repository name, GitHub token, LLM key, and optional Dagger Cloud token to the Dagger function. In the demonstration, labeling an issue causes the agent to edit the application, run tests, and open a pull request that closes the issue.
Agents can be composed and exposed through other interfaces
The speakers show that an agent is just a Dagger function, so one agent can be placed inside another agent's environment. Kyle describes an example that writes Dagger documentation in several languages, including nested Dagger execution with privilege nesting so an inner container can talk to the engine. Dagger modules can also be exposed as MCP servers, and existing agent SDKs can use Dagger for their container and workspace tools. Kyle demonstrates an OpenAI Agents SDK example where the SDK supplies the agent while Dagger supplies the sandboxed file and build environment. This gives teams a choice between using Dagger's built-in LLM component and bringing another agent framework.
"The main thing is like you want the right amount of tools to for that agent to solve its task, whatever that task is."22:59
Who should watch
You are building coding agents and need them to run project-specific builds and tests instead of issuing unrestricted shell commands.
Your team wants GitHub issues or pull requests to trigger automated code changes while keeping a review step before merging.
You already have CI or developer workflows and want to put those same workflows inside isolated environments that agents can use.
