CI that keeps up
explainerby Kyle Penfound

What is Dagger's role in an agentic software factory?

In an agentic software factory, AI agents write most code changes, and a system verifies each change before it ships. Dagger is that system. It runs each change, from an agent or a person, through the same builds and tests, before or after push (dagger.io). Agents use Dagger to run checks, to see which test failed, and to run only that test again. The agent harness plans the work, and Dagger runs and verifies it.

What an agentic software factory is

A software factory is the set of systems that build, test, and ship code. In an agentic factory, AI agents make most of the changes, and many agents work at the same time. Each change needs builds and tests, so the factory runs many more of them than a team of people does. Each result must also be precise, because an agent acts on it with no person to read the log.

Where Dagger fits

Dagger is CI for this load. Dagger describes itself as third-generation CI, after Jenkins and GitHub Actions, built to match the speed and scale of agents that write code (dagger.io). The same checks run on a laptop, for an agent, and in Dagger Cloud after a push.

A check is a command that verifies your project and passes or fails, such as a test run or a linter (Checking your code). Official modules add checks for common tools, such as Go, pytest, Vitest, and ESLint, with no change to your tests (modules).

John McBride, co-founder of Paper Compute, says: “Dagger runs it all! It’s what gives us confidence to move fast with AI agents and factories.” (dagger.io)

What agents do with Dagger

An agent uses the same commands as a developer:

  • Run the checks. dagger check runs all checks of the workspace, and exits with a non-zero code when one fails (Checking your code).
  • Run one test. Filters select one test, one file, or one package, such as dagger check --go-test=TestGet (select collection items).
  • Start what a test needs. A test can call Dagger modules to start its own dependencies, such as a database (self-orchestrating tests).
  • Run on a remote engine. Many agents can run their checks on a shared engine, on your servers or on Dagger Cloud, and not on one machine (remote execution).

Execution is sandboxed, so developers, agents, and CI can share compute and cache with safety (dagger.io). When an agent stops at a failure, dagger check -i lets a developer open a shell in the container where the command failed (dev shells).

Why test-native results matter for agents

An agent needs to know what failed, not only that a job failed. Dagger sees each test, not only the job that runs it (test-native CI). The trace shows each test with its status, its duration, and its logs. The agent reads which test failed, fixes the code, and runs only that test again.

Why the cache matters for agents

Agents run the same checks many times while they change code. The Dagger engine caches the result of each operation (Introduction). When the inputs of an operation do not change, the engine uses the cached result and does not run it again. Dagger Cloud bills repeat work at one fifth of the price of new work (pricing).

One engine for the full run

Dagger’s sandbox, scheduler, container runtime, build cache, and tracing share one execution and data model (dagger.io). For example, the scheduler knows what the cache has, and the trace shows each test that the run executed. Dagger says this gives a level of compute and token efficiency that CI built from separate tools cannot reach.

What Dagger does not do

Dagger does not replace the agent harness. The harness reads the task, plans the change, and edits the code. Dagger builds and tests the change, and reports the result. Each system has its own job.

Bottom line: In an agentic software factory, Dagger runs and verifies the work that agents plan. It runs each change through the same checks for agents, developers, and CI. It shows which test failed, and it reuses cached results across many runs.