A platform for agents that work inside Dropbox’s real engineering environment

Coding agents are becoming a core part of software development, but at Dropbox scale, their value extends beyond generating code faster. Agents also need to operate inside a large monorepo, validate changes against the full build and test environment, and pull context from across the engineering lifecycle. Much of the work engineers do—migrations, CI triage, failure investigation, repetitive operational tasks—is well suited to AI assistance, even if it doesn’t look like traditional interactive coding.

To prepare for that future, Dropbox built Nova, an internal service for running coding agents in the cloud. Nova lets engineers run multiple coding sessions in parallel and enables internal systems to invoke agents as part of automated workflows. Rather than building one-off integrations for each use case, the platform applies agents consistently across different engineering workflows, making it easier to experiment with where AI can have the most impact.

Why a shared platform instead of single-purpose tools

The software development lifecycle is full of tasks that require engineering judgment but are also repetitive and time-consuming: debugging failures, updating dependencies, expanding test coverage, and fixing flaky tests. These tasks disrupt deeper work, but they don’t all demand the same interaction model. Some fit interactive chat, while others can run autonomously in async workflows and only surface when the agent finds something useful. Supporting both consistently requires more than a single-purpose tool.

Dropbox’s development environment also creates requirements that off-the-shelf agents aren’t designed to meet. The large monorepo depends on Bazel for builds and tests, with caching and remote execution and on-premise infrastructure to keep things fast. Third-party coding tools handle local iteration well but don’t naturally fit a workflow tied to Dropbox-specific repository structure, infrastructure, and validation paths. The goal was to have agents operate within those existing systems—not introduce a separate, AI-specific workflow.

That pushed the team toward a platform approach: a shared system supporting interactive development, background jobs, and internal services, with consistent execution, validation, and context handling across all of them. The result is Nova.

Built on a validate-and-retry loop

Nova started with a focused problem: helping engineers respond to continuous integration failures with suggested fixes. That starting point shaped the platform’s design. Each Nova session runs in an isolated environment with a snapshot of the codebase at a specific commit. The caller provides the task and may include validation commands to run after the agent finishes. If validation fails—a test doesn’t pass or a build breaks—Nova can feed the results back to the agent and ask it to address the failure. The agent stays grounded in the real build and test environment rather than stopping after producing a plausible patch. The pattern is simple: propose a change, validate it, and continue only if the results hold.

The platform has since expanded to support multiple coding agents behind the same interface. Engineers can use a web interface for interactive sessions, a command-line interface, and an API to launch jobs in parallel from local agents, scripts, and internal services. To support longer-running workflows, helpers make it easier to add AI-powered steps without rebuilding surrounding infrastructure. Nova also includes tooling for prompt evaluation, observability, and feedback collection, so engineers can gauge how well agents perform.

As use cases expanded beyond file editing, agents often needed to gather evidence, read logs, inspect failures, and carry context across multiple steps. Nova added support for skills, plugins, and MCP integrations, including access to observability systems.

Expanding beyond interactive sessions shaped code publication decisions as well. Nova keeps publication outside the agent and limits each session to a single branch. This gives a predictable view of which branches are active and what’s being published. Allowing agents to create and manage multiple branches within a session would require deciding which branch future work should build from—a complexity the team avoided. Keeping the workflow deterministic also makes it easier to automate per-branch tasks like running tests or rebasing onto the main branch.

{
  "repo_commit": "<commit-sha>",
  "task": "Investigate this CI failure and propose a fix",
  "validation_commands": [
    "bazel test //path/to:test_target",
    "bazel test //path/to/related:all"
  ],
  "continue_on_validation_failure": true,
  "max_iterations": 5,
  "push_branch": "ai/nova/ci-fix"
}

From CI fixes to flaky test remediation

Nova now spans a range of workflows, from quick developer sessions to long-running remediation and migration efforts. The use cases show how agents fit into both interactive development and durable operational work.

Developer-driven sessions

Engineers use Nova’s web UI for quick fixes and prototypes without interrupting their local development loop. For code changes, Bazel selectivity tools combine with Nova’s validation commands to ensure changes are checked against the right compile and test targets. Engineers can also start from a Slack thread and carry that context into a Nova session, preserving discussion that would otherwise need manual transcription.

Flaky test remediation

One of the most effective operational workflows has been flaky test cleanup. Dropbox built Deflaker, a durable workflow integrated with Athena, its flaky test detection system. Deflaker finds examples of a test both passing and failing, sends the logs to Nova, and asks the agent to identify a likely root cause and propose a fix. The proposed change is validated by running the test 100 or more times in CI, depending on failure rate. If the test flakes again, the new logs are carried forward with notes from the prior attempt, and the loop repeats until a fix lands or attempts hit a cap of five.

Athena detects a flaky test. Passing and failing logs are sent to Nova. Nova proposes a fix. CI runs more than 100 validation attempts. Success lands the fix, while failure starts another attempt with new logs and notes from the prior session.

Migrations and dependency upgrades

Migrations and dependency upgrades were a natural fit for the platform. Previously, Dropbox used a bespoke Goose-based AI migrator integrated with an internal migration tracking tool. It generated parallel AI coding jobs using prompt templates and verification commands, publishing results to GitHub branches. The system handled thousands of migration entries, including conversions from Enzyme tests to React Testing Library and updates to mypy type configuration.

But the migrator had limits: no interactivity for reviewing or continuing agent output, which left teams without a practical way to recover from failures. The team also found that highly repeatable migration work was often better handled directly by migration owners, who could launch and manage dozens of agents with a single runbook rather than coordinating delegated work across teams.

Moving migration workflows onto Nova brought interactive coding sessions, shared guardrails, reusable workflow tooling, and a consistent operating model. The longer-term goal is for migration owners to write a prompt once, run it concurrently across many codebase areas, and review results as part of a coordinated rollout. Nova also integrates with RenovateBot so agents can make a first pass at repairing breakages from dependency upgrades.

Experiments beyond code authoring

Nova is also used to respond to production crash alerts by recreating crash states with tests, generating candidate fixes, and routing results to service teams. Some of the most promising experiments extend beyond code authoring itself. One explores whether agents can assess when a code change needs review from secondary teams by checking pull requests against team review policies. Another tests whether scheduled workflows can reduce recurring on-call toil, like alert flapping or follow-ups buried in Slack. A third runs multiple agents reviewing the same change from different perspectives, then aggregates results to deduplicate and filter low-value comments.

Platform matters as much as the model

The biggest takeaway from building Nova is that coding agents deliver value through the infrastructure around them, not just through code generation. Running agents as a service creates a reusable foundation for many engineering workflows. Context, validation, and guardrails reinforce each other: service-specific AGENTS.md files supply localized context, while validation commands, isolated execution, hermetic tests, Bazel caching, and retry loops let agents work against the same systems engineers already depend on. Individually each layer improves reliability; together they make background workflows significantly more trustworthy.

Keep deterministic systems in control

Not every operation belongs inside the agent loop. As Nova expanded across the software development lifecycle, the team had to judge where agentic behavior helps and where deterministic systems should stay in charge. Letting an agent run its own tests and iterate could leave sessions waiting on CI for hours, or worse, validate changes against the wrong tests. The more reliable pattern was for surrounding workflows to trigger CI deterministically, then bring the agent back only when there was a failure to inspect or fix.

Better models alone are not the answer

As coding agents improve, they will likely absorb more of the repetitive work across the development lifecycle. But progress depends on better integration with the systems that shape engineering work, not just better models. Nova provides a shared execution layer for AI-assisted workflows through isolated environments, repository-aware context, validation loops, workflow integration, and reviewable outputs. With context sources expanding through Dash and MCP-based integrations, agents should become more useful, more reliable, and better aligned with how Dropbox engineers actually work.

Acknowledgments: Samm Desmond, Daniel Avramson, Adam Ziel, and Chris Hodges