Rails behind Dagny’s Rails

At Dagny, 98% of commits are made by cloud agents, across millions of lines of code. Over the last 2 months, over 3,000 cloud agents raised over 2,500 pull requests. 87% of the cloud agents were launched by an automation, AI forward-deployed engineer agent, or another cloud agent.

At that volume, coordinating the work becomes a substantial engineering problem by itself. Every change needs context, review, testing and a path to release.

Every application we build creates work beyond the application’s first release. A request needs context. A change needs review. A database migration needs a safe path to production. Once the software is running, we have to understand what people are doing with the software and what should improve next.

Whether we’re building for a partner or ourselves, we want to build software people love using. The Mill brings structure to how we do that: turning a problem into clear work, giving agents the context to build, and reviewing and testing what they produce before the solution reaches users.

We think of the system around that work as our software factory, AKA The Mill. The Mill includes cloud agents, sandbox environments, shared engineering skills and tools. The Mill also includes how we manage work, critique each other’s work and decide that a change is ready. These are the rails behind the solutions we build.

Start with the person using the Mill

We approach an internal tool with the same product questions we bring to a partner’s application. Who is using the solution? What is the problem they want to solve? Where does the current process make that difficult? Even a tool with one user needs to fit that person’s work well enough that they want to use the tool.

AI shortens the time needed to research a problem, try different variations of the solution, test them, and build something people can react to. That makes direction and feedback especially important. A misunderstanding can become working software very quickly.

The first job is to turn what we learn in conversations, Slack and briefs into a piece of work with enough context to execute. Our format is simple: Problem, Outcome, Constraints and Done when.

For example, a request to “improve search” leaves a lot open. An illustrative ticket might say that someone cannot find a record using the reference they already have, specify which references search should accept, preserve existing permission rules, and describe the checks that demonstrate success. Those details give both the implementer and reviewer something concrete to work against.

Give agents context that lasts

A ticket explains the change. The repository explains the system the change belongs to.

An agent also needs to understand how to work in that system: where the relevant code lives, how to run the system, which conventions matter and how to test the system end to end as a real user would. Some instructions are specific to a project. Others apply across our work, such as how to prepare a change for review.

We maintain common engineering guidance in Dagny Skills alongside repository-specific context. Keeping shared practices in one place gives us a way to improve them deliberately. When an instruction is unclear, we can fix the instruction and work through how that change should reach the projects that use the instruction.

There is a practical balance here. Too little context leaves the agent guessing. Too much duplicated or outdated context creates contradictions. We want the simplest useful instructions, close to the work, with a clear reason for each rule.

Make the work reviewable

Cloud agents can take scoped work into branches and pull requests. That lets implementation happen in parallel when the changes are independent. When one change depends on another, the order still matters.

A pull request gives us a bounded change to inspect. We can compare the pull request with the ticket, read the code, examine test results and ask whether the pull request introduces a side effect elsewhere. The useful handoff includes what changed, how the pull request was checked and anything still unresolved.

Automated review helps with this. In one review exchange, a bot refused to proceed while code review agent findings remained unresolved and asked for human involvement. That is a useful example of the boundary we want: findings must lead to a decision or a fix before work moves forward.

People still supply judgment about the product and the implementation. We share candid feedback and critique the work because a plausible solution can still be awkward, unnecessarily complicated or aimed at the wrong problem.

Check the running software

Reading a diff and passing tests answer important questions. Seeing the application run answers others.

One UI verification workflow we have worked through uses a disposable local stack. The sequence is explicit: launch the application and the application’s dependencies, diagnose whether the environment is healthy, drive the relevant user journey, collect evidence, then clean up. We describe those steps as Launch, Validate, Drive, Evidence and Cleanup.

Separating those steps helps distinguish an environment that failed to start from a feature that failed during use. Separation also makes the check easier to repeat. A screenshot or a recorded result should show what was actually exercised and give the reviewer something they can inspect.

Database changes add another dependency. If application code expects a new table or function, that database change has to be in place when the code needs the database change. Release planning needs to include migration checks, ordering and verification after deployment. The change is only useful once the running system can support the change.

Build coordination around the work

As more work happens in parallel, coordination becomes a product problem too. Someone needs to know which ticket a pull request addresses, what the pull request depends on, what evidence is available and where a decision is waiting, and how to coordinate a release.

The Mill is our software factory for bringing that work together. We are building The Mill toward a clearer view of batches of work, agent activity, review evidence and the steps needed to release a change.

The Mill brings related pull requests into merge order and makes human approval part of coordinating their release. The Mill also broadens agent visibility by reading status and progress of the cloud agent in real time.

The same product discipline applies here: build around the decisions engineers need to make, keep the workflow understandable and leave room for the workflow to grow.

Carry the lesson into the next change

The factory improves through the team’s attention. A review can expose a missing constraint. A confusing check can reveal a gap in setup instructions. Using a feature can show that we solved the wrong part of the problem.

When a lesson is worth keeping, the lesson has somewhere to go: the ticket template, repository documentation, a shared skill or a test. The important step is deciding what should change and making that change specific enough to help next time.

When agents can produce thousands of pull requests, the quality of the system around them matters more. We still need to understand the problem, give useful feedback, and know whether the software works for the person using the software. The Mill brings those responsibilities into a repeatable process, and we keep improving that process alongside the products we build. Our goal is to make every iteration more useful, more reliable, and easier to build on. That’s the work behind Dagny’s Rails.