AI can help people turn an idea into a first draft, but getting to something usable depends on more than a prompt. It needs the files and context behind the request, software to carry out the work, and a way for people to review and refine the result. With the new Dropbox experience, we’re bringing those pieces together where people already keep their work, so they can ask questions about their content and request tasks such as organizing folders, renaming files, and preparing materials to share. Letting an agent change those files meant giving it a controlled place to work, enforcing permissions, and recording its changes so people could review and undo them.

The agent behind those tasks started as two experiments, each approaching the same problem from a different angle. Daniel Reiter Horn and Rich Chan, engineers at Dropbox, were using coding agents for tasks beyond writing software, including designing 3D-printed models and filing expense reports. Both encountered the same challenge: giving an agent access to their Dropbox files while retaining control over what it changed and a way to recover things when something went wrong.

Melding those experiments meant connecting the agent to both the files in Dropbox and the safeguards already built around them. Access to the filesystem let the agent work directly with files, while version history provided a record of changes that could support rollback. An isolated workspace gave it somewhere to run installed software, with permission checks outside that workspace controlling what it could access and change. The overall system brought those pieces together for customers, letting them follow the work, approve access, and review the results.

The early projects of both engineers exposed different parts of the challenge, starting with the software an agent needed in order to get the work done. For Daniel, the need for the right software became clear when he wanted to build a futuristic cityscape model that his son could turn into a diorama. The family laptop had no 3D modeling software, so he put together a sandbox, an isolated computing environment, with a coding agent and specialized software. He connected it to Dropbox using rclone, a tool that let the agent work with his online files as if they were stored inside the sandbox. 

Through an experimental command-line interface, Daniel could describe changes, preview the model on dropbox.com, and refine the design until it was ready to print overnight. The prototype ran outside the Dropbox web experience and didn’t yet have agent permission controls or conversation-specific undo, but it showed that an agent could produce something useful directly in Dropbox without relying on software installed on someone’s laptop.

Rich, meanwhile, had been approaching the same problem through the desktop app. Each week, he used a coding agent to turn receipt images into expense reports, but every run meant copying the receipts out of Dropbox to a location the agent could access. He spent a week building a graphical interface directly into the Dropbox desktop app so he could run an agent with access to his Dropbox files. The prototype combined usability, safety, and permission controls, giving Rich confidence to use it on his own data. He could then process his receipts and handle routine tasks directly from the app, without copying files elsewhere.

The interface also connected to the Dropbox folder pickers, live previews, and revision history, letting Rich open the files being changed and trace a revision back to its conversation. Those connections made it possible to follow the agent’s work through the files themselves, providing a foundation for reviewing and undoing changes later.

The experiments complemented each other. Daniel’s sandbox gave the agent a place to run installed software, while Rich’s graphical interface and permission controls gave people a way to work with the agent and see which files it could access. They realized that connecting Rich’s app to Daniel’s sandbox running on the Dropbox servers could bring both approaches into one product: a workspace equipped with existing software for tasks such as video editing, audio transcription, diagramming, and spreadsheet editing. These are all bound to Dropbox permissions, sharing, version history, and rollback capabilities.

To show what a coding agent is doing, the app needs a consistent way to receive and display its updates. Commands, tool calls, file changes, and plan updates arrive as structured events, one after the next. The interface turns those updates into cards showing commands and file changes, status indicators, and expandable activity grouped under the relevant plan step. Rich’s chat interface in the Dropbox app is built around the Codex App Server API, which lets the app and agent exchange messages and activity updates throughout a conversation. These updates travel as structured JSON-RPC messages, one per line, in a format called JSONL.

The protocol organizes that activity into three parts: threads, which hold conversations that can be started or resumed; turns, which group the agent’s work in response to a submitted user message; and items, which represent messages, commands, file changes, or proposed plans within a turn. Together, these give the interface a way to connect each update to the request and conversation it belongs to.

For example, when someone asks Dropbox to organize a folder of photos, the app starts a turn by sending the request through the trusted host layer to the agent in the sandbox. The agent then sends items and progress updates back to the interface. If the request is broad, the system first asks the agent to propose a plan and blocks it from requesting permission to change files until that plan is accepted. For the photo-organization prompt in a large folder, the plan contains a choice: “Do you want to organize the photos by the locations they were taken in, the date on which they were taken, or the content of the photograph?” The proposed plan appears as a card with options for the person to choose from. The agent will also request file access for the folders associated with the plan explicitly before proceeding; it does not itself grant that access.

As the agent carries out the plan, its updates appear as a checklist showing which steps are underway or complete. People can follow what’s happening, interrupt, or steer the conversation along the way, without needing to understand the code and software running behind the scenes. When the agent needs access to change files, it calls a folder-access tool, and the app displays an Allow or Deny card. If the user approves, the trusted host layer grants access to that location inside the sandbox and lets the work proceed. The agent can then organize the photos in its Dropbox-connected workspace, report its progress, and complete the turn.

Daniel and Rich also wanted to explore other agent harnesses—software that connects a language model to an operating system environment and manages its work—without rebuilding the interface. An adapter, a piece of software that translates between protocols, converts messages from Pi, another coding agent harness, into the Codex protocol the Dropbox interface already understands. The adapter lets Pi’s inputs, responses, and plans use the same presentation. Keeping that common protocol means the team can change the harness running the agent while preserving the interface people use to work with it. And because permissions are enforced in the trusted host layer outside the agent sandbox, new harnesses inherit the same permission controls without needing to be rebuilt.

The interface gave people a way to direct the agent’s work, but the agent also needed a place to carry it out. The workspace builds on Daniel’s prototype with Ubuntu, a Linux operating system, and its command-line interface that lets an agent run and combine existing software using text commands. The agent uses that interface to run document conversion software, image processing and other tasks, avoiding the need for engineers to build a separate integration for each workflow. Running the environment in Dropbox data centers makes it possible to provide the software and control its access to files and services, regardless of what’s installed on someone’s laptop.

Dropbox already had a system for running an operating system sandbox in our data centers. Riviera, our content-processing platform, can create Microsoft Office previews by opening each document in a fresh virtual machine (VM), an isolated computing environment, and converting it into a PDF people can view in their browser. To start those VMs quickly, Riviera uses software called QEMU to restore a previously prepared machine from a snapshot of its memory. The same method gives each agent conversation a fresh workspace that comes online in tens of milliseconds, before connecting to the person’s Dropbox files.

Each conversation gets its own workspace with the agent, the software it needs, and rclone to connect it to Dropbox files. Service credentials, the keys used to access other services, stay outside that workspace. A proxy, which forwards requests on the workspace’s behalf, sends outgoing requests to host_tools, a process outside the VM. Before passing a request along, host_tools checks that the destination and operation are allowed and, for file changes, that the person has granted permission. Only then does host_tools add the credentials needed to carry out the request.

The workspace has no general internet access, so this is its only route to outside services. These checks apply whether the agent calls a tool or runs a software program, including when rclone reads or changes a file. Model requests also pass through the Dropbox model-access service and security checks. Keeping access checks outside the VM means the agent can’t grant itself broader access to files or services.

Starting the VM was quick; connecting it to the person’s Dropbox files took most of the preparation time. In testing, 75% of workspaces connected to Dropbox and were ready to send the agent’s first request to the AI model within 300 milliseconds of the initial request to start the virtual machine. To shorten the wait, the system starts preparing the workspace once someone has typed more than a few words, before they submit the message. That way, the system can get ready while they’re still describing what they want done.

Starting from a saved snapshot made the workspace quick to launch, but updating tools such as rclone or the proxy initially meant rebuilding that snapshot. To avoid repeating that work, those tools were moved onto a separate virtual disk, a software-based drive that the workspace reads during startup. The workspace copies the newest tools into the workspace while keeping the rest of its prepared setup. The software can then be updated without rebuilding the snapshot each time, making it easier to improve the system while keeping startup fast.

Enforcing access also meant deciding how often to ask for approval. Reorganizing a photo collection might involve hundreds of changes, and reviewing each one would make the task cumbersome. Reviewing a multi-step plan gives people a way to assess the overall approach, while folder permissions define where changes are allowed. A simpler task, such as creating a video clip while leaving the original untouched, can follow a shorter path, asking for destination-folder access when needed.

Approving a plan doesn’t mean the result will be exactly what someone wanted. When Daniel was building the cityscape, some skybridges and overhangs wouldn’t print properly, so he needed to undo them and try another design. He used Dropbox Rewind to restore earlier versions, but he had to be careful not to undo unrelated changes made during the same period. That showed Daniel and Rich why the system needed a more precise way to undo an agent’s work, especially in shared folders where other people or agents might also be making changes.

To make that possible, Dropbox records which conversation produced each version of a file the agent changes. When someone chooses to undo the work, that record identifies the changes belonging to the conversation, leaving unrelated files alone. For example, if the agent adds chamfers, or beveled edges, to both the buildings and skybridges when only one was intended, someone can select that turn and restore the cityscape files to their state before the change. However, if a person or another agent has since edited an affected file, Dropbox saves the restored version as a separate, renamed copy so their work is preserved.

Attributing the conversation also helps people understand why a file changed. From the file’s activity and version history, they can open the conversation at the point where the agent made the change and see the request behind it. They can then decide whether to keep the result or undo it, with a clear connection between what they asked for and what happened to their files.

The cityscape and receipt experiments showed Daniel and Rich what an agent could accomplish with direct access to Dropbox files. Bringing that capability to customers meant making it practical beyond their personal setups. The new Dropbox experience brings the software and controls into the product, so people can focus on what they want done instead of setting up software or copying files for an agent to reach.

This work reinforced a few lessons. People’s tasks vary widely, so the agent needed an isolated workspace where it could run and combine programs. Giving it that flexibility meant keeping credentials and permission controls outside its reach. And because an agent can make mistakes, its changes needed to be traceable to a conversation and reversible through undo.

As the new Dropbox experience rolls out, customers can ask questions about their files and ask Dropbox to carry out tasks on them, then review and refine the results. Daniel’s cityscape began with an idea and took shape through a series of changes he could see and evaluate. That freedom to try an idea, see what works, and change direction is now part of working in Dropbox.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

For three years, we’ve been working toward a new Dropbox experience that helps people do more with their files, from finding a project decision to getting a folder ready to share. Today, we’re beginning to roll that experience out to customers. But getting here meant changing how we build software. We had complex integrations to tackle and a deadline to meet, and AI-assisted development helped us take on work that would've previously been difficult to complete in time for launch.

The new Dropbox experience puts that investment into practice by helping customers understand what’s in their files and get work done with them. Ask Dropbox what changed in a project folder, and it answers with sources you can open and check. Ask it to organize a folder, rename files based on their contents, or combine documents into a PDF, and it shows a plan you can review and edit before approving. Dropbox only reads and acts on content you already have permission to access, and supported file changes can be undone. And the results stay in Dropbox, where teams can review, share, and keep working with them.

Delivering that experience meant building new capabilities on web and bringing them into desktop, with shared code that let us develop features for both applications. Engineers took broader ownership of product decisions and brought quality checks into development from the start. As the work progressed, we moved from using AI to help with individual coding steps to delegating defined tasks—including implementation and testing—for engineers to review. Together, those changes helped us deliver a product years in the making within an ambitious launch timeline.

We began with a broad product direction and a lot of details to work out. We needed to turn that direction into specific experiences people could use, including a fuller desktop app. Desktop had primarily focused on keeping files in sync, while web already supported richer ways to browse and work with content. We wanted to build on that foundation and bring both existing features and new capabilities developed on web into desktop without rebuilding everything separately for each platform.

The difficulty was that web and desktop had grown around different needs. They used different tools to build and release software and handled tasks such as signing in, navigating between pages, and retrieving data differently. A web feature could depend on services that desktop didn’t provide in the same way. Before we could reuse it, engineers needed to identify those dependencies and work out how to support them—a substantial integration effort to complete before our November launch deadline.

During our Hackathon in May, engineers built a working prototype that explored two possible approaches to tackling this problem, and AI helped them trace dependencies, identify platform-specific assumptions, and test the integration. One approach displayed the existing All Files page inside a desktop-specific window using Electron, the framework behind desktop’s interface. An embedded web view—a browser surface inside the app—let us bring the existing web browsing experience into desktop quickly. The second approach imported selected web components directly into desktop’s user interface. These individual building blocks required more integration work but gave us greater control over how they fit into the desktop app.

The working prototype gave Product and Design something concrete to try before we committed to a larger architectural change. Engineers turned directional designs into usable flows, surfaced missing states, and proposed options as platform constraints became clear. Product and Design worked through those choices as engineers built the features, allowing us to refine the experience as we learned. We found that both approaches had a place: complete web pages where we wanted close parity, and individual components where we needed more control. AI reduced the effort of testing those options, helping turn a long-standing product direction into an early version of the desktop experience we developed for launch.

Alongside the desktop work, engineers used coding agents to implement defined interface changes across Home, Library, and file previews. These included the Jump Back In list view and grid-to-list toggle, giving people another way to browse and return to their work. Agents also handled smaller updates to menus, upload banners, and shared styling. Handing off those tasks gave engineers more time to focus on how the product should behave and how the experiences should connect. That combination helped us move the broader desktop experience and its individual interface improvements toward launch.

The prototype showed that we could bring more of the web experience into desktop. Next, we needed a way to keep improving both applications without rebuilding the same features twice. We wanted Dropbox to feel familiar whether someone used it on web or desktop. That meant reusing the code that makes a feature look and work the same in both places, while letting each app handle things like signing in and moving between screens in its own way.

We share React components—the pieces of code that build what people see and interact with—along with the code they need to work with data. Web and desktop each build and test those components as part of their own app. When a shared feature needs information, it asks for it in the same way on either platform. Web handles that request through the browser, while desktop uses its own networking system. That lets us reuse the feature without making both apps work exactly the same way behind the scenes.

Engineers had to work out which code could be reused and which parts needed to work differently in each app. AI helped them follow the connections between those pieces, pull out reusable components, and write adapters—the code that connects a shared feature to each app’s services—along with tests. Engineers reviewed the resulting code to check that it worked as intended. AI helped us complete that integration before launch, putting an approach we had discussed for years into practice. Now, improvements to shared features have a path to both web and desktop.

The new capabilities also needed to work for people using a keyboard, a screen reader, or an enlarged display. As we prepared for launch, engineers used AI-assisted development to deliver 22 accessibility features across Home, All Files, file previews, and Photos. These included announcements that help screen-reader users follow changes in the Up Next carousel on web and desktop, and improvements to navigating the All Files table. The team also fixed how keyboard focus moves between controls and adjusted layouts to keep pages usable at 200%–400% zoom.

To carry out this work, the web team gave coding agents clearly defined tasks and a consistent process to follow. Each task started with a written plan agreed on by the engineer and agent. The agent made the changes, ran the relevant builds and tests locally, and recorded the results for an engineer to review before accepting the code. Instructions stored with the code explained the rules agents needed to follow, giving engineers a repeatable way to delegate work while remaining responsible for the result. A working group and champions across teams helped establish those shared instructions, task formats, and review expectations, so the approach could be used consistently across the project.

Retiring an older file list had been deferred for two quarters because updating the automated tests required substantial engineering time. AI-assisted development gave the team a practical way to tackle that cleanup alongside its launch work. Engineers divided the cleanup into 53 tasks. Coding agents then updated or removed the affected tests using the same testing and review process, and the team finished all of those tasks in one week.

The team also used coding agents to add automated tests for five core parts of the web app, including the file browser people use to navigate their content. By checking for problems when the code changes, these tests help engineers catch issues before they reach customers. 

Beyond writing tests, AI agents tried out the experience during development, which helped engineers catch problems while they were still working on the relevant code. In one case, an agent found that a deleted item in Chat history could remain visible until the page was refreshed; engineers fixed the underlying synchronization issue and added tests to prevent it from returning. This let human reviewers spend more time assessing whether the experience made sense to customers, while automated checks helped catch functional problems.

And importantly, customer feedback helped us decide what to improve and when to expand access. All eight of our initial design partners chose to keep the new experience enabled. As we introduced the experience to larger groups, we watched how people used familiar features such as upload, preview, search, and sharing, and tracked whether AI actions succeeded and whether customers switched the experience off. Those signals helped us prioritize issues, while the coding-agent workflow gave engineers a consistent way to implement and check fixes. AI helped us work through the changes; customer feedback and engineering review guided what was ready to reach more people.

The new Dropbox experience reflects years of work toward helping customers understand their content and complete more of the tasks around it. AI-assisted development helped us bring that direction to launch by making it easier to test a fuller desktop experience, connect features across web and desktop, and address accessibility and testing work while building new capabilities. Engineers guided that work, deciding how the applications should fit together and checking the changes against the behaviors customers depend on.

The value of that work extends beyond this release. Shared components let improvements reach both applications. And the process engineers used to delegate and review accessibility fixes and testing work gives them a way to tackle further improvements, with customer feedback helping determine where to focus.

Together, these practices give us more room to improve Dropbox as we learn how people use it. They also broaden the work engineers can take on: understanding customer needs, trying out interactions, weighing product decisions, and following changes through release. Technical expertise remains essential, and AI gives engineers more opportunities to apply it across those responsibilities. Their judgment and customers’ needs continue to guide what we build and why.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

Calendars hold more than just blocks of time. They reflect how people plan their days, coordinate with others, and make room for what matters to them. Reclaim, the Dropbox-owned calendar assistant, helps manage that complexity by using AI to find and adjust time for tasks, habits, and meetings. That approach works well when inputs and expected outcomes are clear. But people also use Reclaim for scheduling that’s less straightforward.

As AI assistants and natural-language interfaces became more capable, they opened up a new way for people to use Reclaim. We imagined situations where users could describe a scheduling goal in their own words, even when it didn’t map neatly to an existing setting or command. Words alone wouldn’t be enough to determine what should happen on a real calendar, though. Reclaim still needs the context that gives requests meaning, including what’s already scheduled, when a user is available, and which preferences and commitments impact changes.

Connecting natural-language requests with the surrounding calendar context could help people spend less time figuring out which settings or actions to use. But building the experience required more than adding an AI interface to the existing product. We needed to rethink how Reclaim turned conversational requests into calendar changes while preserving the scheduling system already in place.

For our engineers, the rebuild started with the way Reclaim already managed calendars. Calendar changes carry real weight because time is precious and scheduled events often involve other people. Any new AI capability needed to feel like a natural extension of Reclaim, and it needed to work with the scheduling logic already in place.

Before the redesign, Reclaim handled calendar changes in two primary ways. Users could make specific changes themselves, like moving an event or updating a setting. And Reclaim’s automated scheduler also worked in the background. It considered each person’s preferences and availability when finding time for tasks, focus work, and recurring routines like lunch, then adjusted those calendar blocks as schedules changed.

The emergence of AI agents introduced a potential third way for users to use Reclaim. Instead of choosing a specific setting or command, a user might prefer to describe what they want to do in their own words. An agent could then interpret that request, look at the relevant parts of their calendar, and work out how Reclaim could help. 

But we needed to address several challenges before introducing agents to the experience. Large language models can interpret the same request in different ways because they generate answers based on patterns in their training data. For example, an open-ended request like “make time for this tomorrow” could lead an agent to find an open block, create a new event, or move something already on the calendar. Each option would affect the user’s schedule differently, and some could affect other people’s calendars, too.

That variability made AI agents different from the two paths Reclaim already supported. Although they arrive at decisions differently, all three actors needed to rely on the same scheduling logic. Creating a separate AI-only path would have duplicated functionality and made Reclaim’s behavior harder to keep consistent across interfaces. We needed a system that could connect a model to both the right calendar information and Reclaim capabilities while also controlling how it used them. The result was an agent platform designed to work within Reclaim’s existing architecture.

Our agent platform gives a model relevant calendar details and access to Reclaim’s features while controlling what the model can see and do. The model interprets what the user says and figures out what they want. The agent, meanwhile, manages the larger process by providing Reclaim’s instructions, relevant calendar context, and tools (which let it ask Reclaim to look up information or request a specific action). When a tool returns information, the agent can send it back to the model to inform the next step. This repeated exchange is called the agent loop.

As part of this process, Reclaim gives the agent the calendar information and tools relevant to each request, rather than access to everything at once. This helps the agent focus on the immediate task and limits it to the appropriate actions. For a more complex request, the agent can give one specific part to a specialized subagent. Internal checklists and review steps help keep the overall request on track.

Ultimately, we opted to build the agent loop, tools, and the system for gathering context ourselves, and we connect directly to model providers instead of relying on a broad agent framework. That’s because a framework we initially explored lagged behind the provider APIs we wanted to use and included more structure than Reclaim needed. Owning these parts lets us design them around Reclaim’s scheduling needs, adopt new provider capabilities more quickly, and work with different model providers without rebuilding the rest of the platform. That leaves us with more code to maintain, though using agents to help with that code offsets some of the additional work.

The same tool system supports Model Context Protocol (MCP) in two ways. Inside Reclaim’s agent loop, an MCP client lets the agent use compatible tools from other services. Separately, Reclaim’s MCP server makes selected Reclaim tools available through supported AI clients, including Claude and ChatGPT. Those clients use their own models and agent loops, but can call the same tools used within Reclaim.

Our agent platform helped Reclaim work through open-ended requests, but we still needed safeguards around any changes it proposed. Users needed a way to review those changes before they reached their actual calendars.

Behind the scenes, Reclaim represents each scheduling capability as a Schedule Action, our internal term for a standard operation like creating or updating an event, changing an RSVP, or finding availability. Whether a request comes from a user, the automated scheduler, or an agent, the same Schedule Action type is used, including the same validation and commit process.

That shared path matters because a calendar change can affect more than one event. Moving a meeting might change someone’s availability or cause Reclaim to adjust flexible events elsewhere on a user’s calendar. If each actor used a separate implementation, engineers would have to reproduce those rules and keep every version aligned as Reclaim evolved, which would have become tedious over time. Because all three actors use the same Schedule Action, engineers can change how an operation works in one place rather than updating three separate versions. This helps Reclaim behave consistently across its interfaces.

But even when Reclaim handles a change consistently, users still need to see whether its wider effects match what they want to do. That’s why we developed Preview Mode, which gives users a temporary version of their calendar where they can review AI suggestions and changes requested through chat before applying them to their actual calendar. Essentially, they’re able to see how an event or settings change would affect the rest of their schedule before it goes live. They can then confirm that the change behaves as expected and review any effects on shared events before calendar updates are sent to other attendees.

To keep Preview Mode fast, we reworked the automated scheduler as a pure function, meaning, in part, that it can calculate a proposed schedule without saving anything to the user’s actual calendar. Reclaim can repeat that calculation whenever the user adjusts the preview. Because busy calendars and meetings with several attendees require a lot of data, Reclaim keeps a readily accessible copy in Redis, a data store designed for fast retrieval. It also updates attendee availability within the preview whenever an event moves, so the next calculation reflects the schedule being proposed.

Reclaim now has a consistent path from a natural-language request to a reviewed calendar change. The agent platform connects models with relevant calendar information and Reclaim features, Schedule Actions route proposed updates through the product’s scheduling logic, and Preview Mode makes their effects visible before anything reaches the calendar or other attendees. Together, these pieces extend Reclaim with AI while preserving the scheduling experience people already rely on.

This work also reinforced what AI needs in order to be useful inside an active workflow. A model needs the surrounding information to understand a request, a controlled way to act on it, and a review step before the result moves forward. In Reclaim, a scheduling goal can move from conversation to a proposed schedule and then to an approved calendar update without requiring the user to translate it into a specific setting or command.

The long-term value of this rebuild is the freedom to evolve without fragmenting the product. As AI changes how people ask for help, Reclaim can introduce new capabilities through the same scheduling foundation rather than adding a separate experience each time. For Reclaim, this offers a practical framework for expanding AI-assisted workflows as models improve and people find new ways to manage their time.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

As AI becomes a starting point for more kinds of work, its usefulness depends on access to an organization’s trusted knowledge and context, including the files, research, feedback, decisions, and project history that give the work meaning. Dropbox helps people bring that context into the supported AI tools they choose while preserving the permissions and controls they expect, so they can spend less time finding, uploading, and re-explaining what already exists. When AI helps them create something new, Dropbox gives that work a trusted, durable home where it can be saved, shared, reviewed, approved, and built on over time.

That focus on connected workflows also shapes how we use AI within Dropbox. Access to increasingly capable models can help teams produce more. But turning that output into sustained gains in productivity, quality, and customer impact requires examining workflows from end to end. That includes addressing new bottlenecks as output grows, adapting the platform that supports development, aligning organization-wide incentives, and measuring whether greater speed and volume lead to better outcomes.

AI also increases the importance of human judgment. People still need to choose the right problems, give agents the context they need, evaluate the validity of their output, and remain in control of important decisions and actions. Problem solving, communication, and leadership become critical to turning AI-enabled output into real value.

Dropbox Chief Technology Officer Ali Dasdan and Senior Director of Engineering Productivity Uma Namasivayam discuss lessons from deploying AI at company scale, how we assess productivity and ROI, how our progress compares with industry peers, and what organizations need to consider as they move from AI adoption to broader transformation.

What have you learned in the last year about driving productivity with AI, not just for engineers but across the wider Dropbox organization?
Ali: You have to start with the outcome you’re trying to achieve. Giving people AI tools is only the first step. As people use them, your assumptions get tested and new bottlenecks emerge. Maybe you’re coding faster, but now you have too many code reviews. Or you’re generating significantly more code, which puts additional stress on the tools and infrastructure that support development. If you want AI to have a meaningful impact, you have to look at the workflow end to end and keep adapting it until you’re producing the outcome you actually want. There’s no silver bullet.

Uma: You have to approach it with a product mindset. Leadership saying, “You need to start using AI tools,” is good, but that alone won’t drive adoption. You also need ground-up awareness through initiatives like boot camps and show-and-tells that involve people more deeply. And you have to align incentives so managers understand what ROI they’re getting from it.

How should companies think about measuring AI productivity and ROI?
Ali: If I write 10 lines of code and push them to production, it’s almost impossible to prove those 10 lines were responsible for a certain amount of customer satisfaction or revenue improvement. I might produce a million lines a day, but if it’s the wrong product and customers have no interest in it, then it’s not going to work. 

The real ROI metrics are outcomes like revenue, cost, customer satisfaction, and retention. Then we look at proxy metrics that connect our output to those outcomes. Are we moving faster, producing more code, running more experiments, and pushing more features? Is the site faster and more reliable? There’s no single metric. The framework we use focuses on speed, effectiveness, quality, and impact, with multiple metrics under each. The industry hasn’t found the full solution yet.

How does Dropbox’s AI-driven engineering productivity compare with companies operating at a similar level of technical scale and complexity?
Ali: If we define peers as top technology companies we hire from and compete with for talent, we’re seeing very similar problems and metrics. We’re around 70% AI-generated code, and Uber recently shared a number around 70%. They see a need for internal agentic coding solutions, and so do we. They have their own tools, and we have Nova, our internal service for running coding agents. Larger companies have allocated more resources to these problems, while we’re super lean. Despite that, I feel like we’re comparable with that peer group across multiple metrics, including how quickly we adopted AI and reached our targets. Compared with the broader industry, it appears we’re ahead.

Uma: The industry looks at pull request throughput, or the rate at which teams complete code changes, as one proxy metric for productivity. It’s not ‌perfect, but our throughput ranks in the top 5% in a custom benchmark of companies with similarly large, complex codebases and engineering systems. We also look at whether moving faster affects quality. Our change failure percentage, which measures how often a deployment leads to degraded performance or failure, is in line with industry peers at the 75th percentile. Our token usage is also among the lowest in that peer group, which could indicate that our teams or systems are operating efficiently. Together, these measures give us a fuller picture of how we’re doing against similar companies.

As AI usage grows, how do you decide where additional investment is worthwhile?
Ali: AI requires money, and when we talk about AI funding, we’re talking about a large portfolio. There are products used by individual functions, capabilities in tools like Zoom and Slack, company-wide deployments like ChatGPT Enterprise, automation tools, and coding models. We’re seeing benefits. People are fixing tech debt, long-running migration projects are getting finished, and we’re delivering most of the roadmap with fewer resources. But organizations still have to decide which ideas to pursue and when to invest more, often before they can draw a direct line to ROI. That requires domain expertise, the right incentives, and a lot of judgment. We’re still working through it along with the rest of the industry.

How should companies determine whether their AI spend is creating real value?
Ali: At Dropbox, we’re starting to think less about raw token consumption and more about the engineering value those tokens create. With Nova, for example, we can connect agent usage to actual engineering workflows, validation, and outcomes. That gives us a way to evaluate AI spend based on the engineering work those tokens help produce, rather than simply how many tokens we’re consuming.

As AI lowers the cost and effort required to produce software, which human skills become more valuable?
Ali: If you look fundamentally at what engineers or computer scientists do, it’s that we know how to solve a problem. That’ll never disappear. AI may help me solve bigger problems or solve them faster, but I still need to provide better context, ask the right questions, judge the validity of the answers, know how to iterate, and give a good spec and problem definition. I also need to understand how a solution fits into the broader system and adapt as the tools change. Problem solving, communication, systems thinking, and judgment become even more important because agents depend on people to guide and evaluate their work.

Uma: I would give you three things. One is problem solving, which Ali explained really well. The second is judgment. The next phase of AI could make the cost of engineering almost zero, which makes choosing the right problems and evaluating what AI produces extremely important. The third is leadership. Leaders need to understand people, navigate ambiguity as work changes, bring teams together, communicate clearly, build trust, and make sure incentives are aligned. Those skills won’t go away at all. Their value will only grow.

As AI models and agents become more widely available, what’ll distinguish the organizations that use them effectively, and what role can Dropbox play?
Ali: Models and agents can be incredibly capable, but they don’t automatically know which information an organization trusts, what decisions have already been made, who has access, or what needs to happen next. Without that context, even a strong model can produce generic or incomplete results. Dropbox can connect supported AI experiences to customer-owned content and context, then give the work AI produces a place to be saved, shared, reviewed, approved, and continued. People still make consequential decisions, while the work keeps moving without losing the sources, history, and collaborators behind it.

A year from now, what do you hope AI-enabled work looks like at Dropbox?
Uma: This year, we’ve focused heavily on engineering, and we’re now starting to understand the workflows across product, design, and other non-engineering teams. A year from now, the goal is for people across those teams to be able to come up with ideas, test them with customers, and potentially ship some of those features. If our customer experience team sees an issue, for example, they could use agents to develop a solution and see whether it works for the customer. That’s the vision we’re pursuing internally. If we can prove it works, we could potentially enable external customers to build on Dropbox platforms and use AI with the building blocks we have.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

We're excited to announce that our modernized Dropbox API documentation is now live at https://docs.dropboxapi.com.

We've rebuilt our API reference to make integrating with Dropbox faster and more intuitive.

What’s new

Interactive API testing 

Test endpoints directly in the documentation. No more switching between docs and separate testing tools. You can set parameters, issue API calls, and see real responses from the Dropbox API right in your browser.

AI-powered assistance 

Get instant help with the embedded AI assistant. Ask questions about endpoints, troubleshoot issues, or get code examples without leaving the page.

Connect your AI tools

Connect compatible AI tools directly to our documentation through MCP (Model Context Protocol) using the MCP server. This gives your AI assistant access to up-to-date Dropbox API documentation right where you work, so it can answer questions, help you explore the API, and assist with integrations using information directly from our docs.

To access the MCP server, use the "Connect to Claude Code" or "Connect to Cursor" actions in the API Reference pages, or connect to the MCP server at: https://docs.dropboxapi.com/_mcp/server

Modern, unified, searchable experience

Explore the Dropbox API through a clean, responsive interface that brings endpoints, types, schemas, and related documentation together in one place. Improved navigation and search make it easier to find the right endpoint or parameter, jump between related resources, and discover the information you need without digging through multiple pages.

Complete API details 

Access comprehensive information including detailed error responses, type definitions, and full request/response schemas.

 

We want your feedback

This is a major update to how we serve our developer community, and we want to make sure it meets your needs.

Tell us what you think:

• What's working well?
• What could be better?
• What features would you like to see next?
  

Please share your feedback in the Dropbox Developer Forum. Your insights will help us build better tools for the entire developer community.

Get started

Visit https://docs.dropboxapi.com to explore the new documentation, try out the new features, and then let us know what you think.

Thanks for building with Dropbox!
The Dropbox API Platform Team

As AI and automation become a bigger part of digital experiences, it’s increasingly important that people stay in control of the choices they make. They should be able to benefit from new technology without losing the preferences they’ve already expressed.

Cookie banners are one of the most familiar places where people express those preferences online. They’re also one of the most visible parts of a company’s privacy program. And for companies that operate a large, dynamic collection of websites, keeping them working as intended can be challenging. A banner might work correctly when a page launches, but changes made later can affect how someone’s cookie preferences are saved or applied. When someone accepts, declines, or customizes cookies, the website needs to remember that choice and behave accordingly. New integrations, experiments, or even changes to a page’s settings can unintentionally affect that behavior.

Manually checking that cookie banners continue to work as expected across all of our websites requires hours of quality assurance. To make those checks more manageable, we built a cookie auditor that acts like a privacy-conscious user. It visits Dropbox web pages and checks that they only load cookies consistent with that user’s privacy preferences. This gives us a scalable way to put our privacy commitments into practice as our web presence continues to evolve.

Most of us are familiar with cookies, but we don’t always think about what they mean for the choices we make online. Cookies are small pieces of data sent to a browser when someone visits a website. Some are strictly necessary, meaning they serve an essential purpose like keeping a user logged in or remembering language settings. Others are non-essential and support things like analytics, marketing, performance, or advertising. Strictly necessary cookies load automatically, but privacy laws in some places require companies to get consent before loading non-essential ones.

On the surface, cookie compliance can seem pretty straightforward. Websites show a banner, provide buttons to accept or decline, record the choice, and load cookies accordingly. But at scale, things can get a bit more complicated. Dropbox operates over 200 web surfaces across different products and teams, and the cookies on each page can vary depending on that surface’s purpose. URLs also change all the time as pages are launched, retired, redirected, localized, or included in experiments.

Plus, cookie banners aren’t the only way people can communicate their privacy preferences. Global Privacy Control (GPC), for example, is a technical standard that lets people set a privacy preference in their browser that can be communicated automatically to the websites they visit. Our system needed to recognize GPC signals and respect those preferences, too.

It’s also important to look beyond cookie banners themselves. Even when a banner appears to work correctly, we still need to verify that someone’s choice is actually being applied. That means checking which cookies load before and after someone makes a selection, and that their preference continues to apply after the page reloads. That’s where our cookie auditor comes in.

Before we began building a cookie auditor, our Privacy and Engineering teams first needed to agree on what the system should consider correct behavior. That meant deciding which websites should be audited, what kind of banner behavior would constitute a violation, and which third-party cookies and other artifacts should be tracked separately. We also defined when a missing banner should be considered a problem and when it was expected, such as on a web page that was no longer in use.

Privacy programs often depend on legal concepts that require human interpretation, such as opt-in or opt-out, strictly necessary, and affirmative consent. But a machine needs much more concrete instructions about what should happen when someone makes a particular choice and what to flag when something doesn’t behave as expected. Turning those concepts into outcomes the cookie auditor could actually test was an important part of the work.

We also kept these classifications outside the auditor’s source code. That meant the Privacy team could update the list of approved cookies and known exceptions without waiting for engineers to change the code and release a new version. Importantly, it also made the system easier to adapt as Dropbox services and regulatory guidance evolve, helping our privacy protections keep pace with both.

Because we built our cookie banner in-house rather than using an off-the-shelf product, we could integrate the auditor directly with our existing consent infrastructure. That gave us more control over how the auditor and consent system worked together and made it easier to adjust what we tested as our websites, services, and privacy requirements evolved. Instead of treating compliance as a fixed set of rules, we built a system that could change along with those requirements.

Defining the criteria that’d govern our cookie auditor was only one part of the challenge. We also needed a way to test those criteria against what someone really experiences when they visit a Dropbox website. To do that, we designed the auditor to behave much like a real visitor would. It uses Playwright, a browser automation library, to open a Dropbox web page in a fresh, isolated browser session and observe what happens from the moment the page loads.

For every page we check, the cookie auditor runs three separate tests to account for different privacy experiences. One simulates a standard US visitor, another simulates a visitor in the EU, and the third uses a GPC signal. Each test starts from scratch, with no existing cookies or saved preferences, so the auditor sees the same experience as a new visitor. Before interacting with anything on the page, the auditor records which cookies have already loaded and checks whether they match what we expect to see for that test. 

Next, the auditor finds the page’s consent controls and declines non-essential cookies. That’s more complicated than simply looking for a button that says “Decline.” Depending on the page, consent controls might appear in a banner, a floating control, a preferences window, or a footer link. They can also appear in any of our 22 supported languages. Rather than relying on specific words on the screen, the auditor identifies and interacts with the underlying consent controls. It then reloads the page and checks what happens next.

Reloading the page is an important part of the test. Once the page reloads, the auditor checks that the user’s preference still applies and that the cookies present match what we expect for that test. If anything unexpected appears, it’s recorded for further review. This focus on what actually happens, rather than what should happen based on a configuration, became one of the project’s most important design decisions. 

At this point, we had a reliable way to test whether a Dropbox web page was respecting someone’s privacy choices. But the auditor could only test the pages we knew about. As new pages were created and existing ones changed, we also needed a reliable way to identify which pages should be included in our audits.

Although the auditor worked well on our defined list of URLs, we soon realized that keeping that list up to date would be an ongoing challenge. New marketing pages, blog posts, and help center articles are published every week. Our Privacy team didn’t necessarily have clarity on every new web surface being created across the company, and asking teams to manually send us every new URL would create exactly the kind of bottleneck the project was meant to reduce.

Our solution was a companion URL detector, which is effectively an auditor for our auditor. The cookie auditor checks whether a user’s decision is respected, and the URL detector makes sure we’re checking all the places where the consent experience should appear.

We started by using traffic data to identify Dropbox web properties. Because that data includes a new record every time someone visits a page, our initial search had to comb through billions of records. But billions of visits didn’t mean billions of different pages. The same URL path might appear thousands or even millions of times, so we first filtered out repeated records to narrow the results down to a more manageable list of unique paths.

From there, we applied a second, more detailed round of filtering. Doing all of that work while searching through billions of traffic records would have required significantly more time and computing resources, but working from the smaller list made it much more efficient. At this stage, we could exclude pages that didn’t need to be tested, group together pages that used the same consent logic, and select representative URLs from large groups of similar pages. This gave the cookie auditor a manageable set of pages that still represented the different consent experiences someone might encounter across Dropbox.

Automation can narrow the search space, gather evidence, and identify potential issues, while Privacy and Engineering teams provide the insight needed to understand unusual pages and exceptions. This division of labor helps us keep pace with Dropbox’s changing web footprint without creating another time-consuming manual process for our teams. It also reflects a principle behind how we approach automation and AI at Dropbox: Use these tools to surface relevant information so that people have the context they need to make informed decisions and take action, while spending less time searching for and sorting through it.

Privacy programs rely on policies, controls, and review processes, but people ultimately experience them through the products they use. When someone makes a choice about their data, they expect the product to respect it. That means making the choice clear, making declining as easy as accepting, remembering the preference, and applying it consistently as someone moves across a website.

That’s why we think about privacy much like reliability or security. It requires ongoing attention as products and systems change. Building the auditor showed us just how many pieces needed to work together to make that possible. We needed to know which pages to test, distinguish real issues from false positives, translate legal requirements into behavior that the auditor could check, and test the experience from a user’s perspective rather than relying on how a system was configured.

Over time, that changed how we thought about the auditor itself. It gave us a way to turn our privacy commitments into something we could regularly test against the actual experience people have on our websites. For us, building that trust into a changing product means making clear commitments to users and designing systems that continuously verify we’re upholding them.

Today, the auditor gives our Privacy and Engineering teams a weekly report on consent behavior across Dropbox websites. It separates likely violations from known false positives, making it easier for teams to understand what needs their attention. Historical results also help us track trends and spot when something that was working correctly begins to change. Our next step is to make that process even more efficient by connecting findings to the teams responsible for those pages and getting potential issues to the right people more quickly.

For teams considering a similar project, the browser automation itself may be the simplest part. Much of the work happens around ‌the browser automation, including defining what correct behavior looks like, maintaining a reliable inventory of what needs to be tested, separating real issues from noise, and creating a review process that brings the right teams together. Investing in those pieces has given us greater confidence that our cookie program continues to work as intended, even as the websites and systems around it change.

Acknowledgments: Special thanks to folks on the Privacy Engineering and Legal teams for guidance throughout the project.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

As demand for AI continues to grow, so does the infrastructure needed to support it. Much of the industry's attention has focused on building more: more data centers, more servers, and more power. But building new infrastructure is only part of the challenge. Engineering teams are also working within constraints on energy, cooling, hardware availability, and physical space, making it increasingly important to get more from the infrastructure that's already in place.

For over a decade, Dropbox’s Infrastructure and Datacenter Engineering teams have continually improved how we plan, operate, and optimize infrastructure. That work spans far more than storage systems. Engineers across Dropbox work together on capacity planning, fleet optimization, hardware lifecycle management, power delivery, cooling, rack design, and facility planning. Rather than treating these as independent problems, we optimize them as parts of a single system, where decisions in one layer influence what's possible in another.

The result is an engineering discipline that extends beyond any single system or optimization. A change in one part of the infrastructure can create opportunities or constraints elsewhere. Increasing storage density, for example, can reduce the amount of hardware needed, while more powerful servers can introduce new energy and cooling requirements. Understanding those tradeoffs allows us to make infrastructure decisions with the entire system in mind.

As infrastructure demand grows, that system-level approach helps us prioritize efficiency and create room for growth before expanding our data center footprint.

Many of the decisions that shape infrastructure efficiency happen months or sometimes years before new capacity goes into production. Whether someone is uploading a file to Dropbox or asking Dash a question, they expect the product to respond without delay. Delivering that experience requires engineers to forecast how customer demand and workloads will change, determine when additional resources will be needed, and understand whether our existing environments can support them.

Dropbox has operated large-scale infrastructure for over a decade. Our hybrid model combines Magic Pocket, the core Dropbox storage system, with colocated data centers, where we manage our own servers and networking equipment in facilities operated by specialized providers. This gives our engineers visibility across software, hardware, and the physical data center environment.

As customer demand grows and workloads change, particularly with the growth of AI-powered products and features, engineers have to plan not only for how much additional capacity is needed, but where and how it can be deployed. New hardware has to fit within a facility's infrastructure constraints while accounting for hardware availability and future product needs. A server that provides more compute or storage, for example, may also require more energy or cooling, changing how much hardware a rack or facility can support.

The goal is to understand those tradeoffs early, add capacity deliberately, and preserve enough headroom for growth, maintenance, failures, and changing workloads. Once additional compute and storage capacity is deployed, the focus shifts to making the most of the systems already in production.

Planning helps ensure infrastructure is ready for anticipated demand, but workloads rarely behave exactly as they did when that infrastructure was first deployed. Customer behavior changes, products evolve, and new capabilities introduce different demands on the underlying systems. AI is a prime example because AI-powered features can change both the scale and shape of infrastructure demand, placing new demands on compute, storage, memory, and networking.

That makes efficiency an ongoing engineering problem. Rather than treating deployed infrastructure as fixed, Dropbox continually adapts how the active fleet operates as those demands change. Sometimes that means reducing how much hardware is in use when demand is lower. Sometimes it means shifting work to parts of the fleet with resources available. And in other instances, advances in hardware allow the same physical infrastructure to support substantially more storage. 

These approaches work at different layers of the system, but they share the same objective: getting more useful capacity from the infrastructure already in place before adding more of it.

Letting capacity rest when it isn't needed
Infrastructure has to be provisioned for periods of higher demand, with additional headroom built in for reliability and maintenance. That means not all available capacity is needed at all times. When hardware is sitting idle or excess capacity is available, keeping every component fully powered consumes energy without providing additional value. Deep Sleep is one way Dropbox reduces that overhead.

Deep Sleep is a Dropbox infrastructure initiative that reduces power consumption when hardware isn't actively needed. Depending on the hardware, that can mean spinning down hard drives into standby mode or powering down idle servers altogether. A server becomes eligible for Deep Sleep through automated fleet management algorithms. Dropbox is able to balance energy efficiency with performance and reliability because servers can return to service within minutes. For workloads that require lower latency, we can also selectively spin down idle hard drives rather than powering down the entire server.

The challenge is determining where those power-saving measures can be applied safely. Engineers have to preserve enough available capacity to meet operational and reliability requirements while identifying hardware that doesn't need to remain fully powered. That allows Dropbox to reduce the energy consumed by underused infrastructure without compromising the capacity our products depend on.

Reducing the power consumed by idle hardware is one way to make the existing fleet more efficient. Another is making better use of the infrastructure that's already online.

Balancing work across the fleet
Having enough capacity to meet overall demand is only part of operating infrastructure efficiently. That capacity also needs to be available where the work is happening. One part of the fleet may be approaching its limits while another has room to take on more work. Without a way to address that imbalance, Dropbox could end up adding more infrastructure instead of making better use of what’s already available across the fleet. 

To avoid that, Dropbox continually monitors how workloads are using resources across our infrastructure. The team identifies imbalances by monitoring spare capacity and workload distribution across the fleet, looking for areas where available headroom is falling or work is concentrating unevenly. When demand is uneven, teams can rebalance workloads across systems or bring additional capacity online where it's needed. Some adjustments happen automatically, while larger changes are reviewed and validated by engineers. This allows us to take advantage of available resources elsewhere rather than treating a localized constraint as a need for more infrastructure overall.

That balancing has to continue as the fleet changes. Customer behavior shifts, products introduce new workload patterns, and the infrastructure itself evolves. Continually adapting where work runs helps Dropbox get more from the capacity that's already online.

Balancing workloads helps make better use of the capacity we already have, but efficiency can also come from increasing how much that infrastructure can support in the first place.

Increasing storage density
Another way to get more from existing infrastructure is to increase how much each piece of hardware can support. Advances in storage technology have allowed Dropbox to store significantly more customer data on each drive. One example is shingled magnetic recording, which packs data more densely onto a hard drive without increasing its physical size. 

Those gains compound across the infrastructure. When each drive holds more data, fewer drives are needed to provide the same amount of storage. That can mean fewer servers and racks, less cabling, and lower power and cooling requirements. In turn, increasing the capacity of a single component can reduce the resources required across an entire deployment.

That system-level impact is also why total power consumption doesn't tell the full story of efficiency. As Dropbox grows and stores more customer data, overall energy use may increase even as the infrastructure becomes more efficient. A more useful measure is watts per petabyte, or the amount of power required to support a petabyte of storage. Since 2020, watts per petabyte across our storage infrastructure have improved by more than 50%. Today, it takes less than half as much power to support the same amount of storage as it did in 2020.

Together, all of the approaches described above help Dropbox get more from existing infrastructure by reducing unnecessary power consumption, making better use of available capacity and increasing how much each piece of hardware can support. How long that hardware can reliably remain in service matters, too.

Replacing equipment too early can leave useful capacity on the table, while keeping it too long can introduce reliability and performance risks. Hardware doesn’t become unreliable simply because it reaches a particular age, nor does keeping equipment longer always make sense. To make those decisions, Dropbox monitors how hardware performs in production. Metrics such as annual failure rate help engineers understand how different components and generations of equipment behave over time.

As demand for infrastructure continues to grow, those lifecycle decisions become increasingly important. Getting more from existing infrastructure isn't only about how efficiently hardware operates while it's in service. It's also about understanding how long that hardware can continue operating reliably before additional investment is needed. That data informs whether hardware can remain in service, should be repaired, or needs to be replaced. 

Understanding hardware performance holistically allows us to extend the useful life of equipment when it continues to perform reliably instead of relying solely on a fixed replacement schedule. When performance declines or newer hardware provides meaningful improvements in capacity, reliability, or efficiency, we can plan a transition. Reliability comes first. Extending a hardware lifecycle is valuable only when equipment continues to meet our operational standards.

We repair hardware whenever practical to extend its useful life. When equipment can no longer remain in service at Dropbox, we work with trusted partners to resell or responsibly recycle it. Together, these decisions help maximize the value of equipment throughout its lifecycle rather than treating deployment and replacement as the only meaningful milestones. But eventually, new hardware does need to come online. And as servers become more powerful and storage becomes denser, deploying them can introduce a new set of constraints in the physical infrastructure that supports them.

Engineering beyond the hardware
Deploying new hardware isn't as simple as swapping one server for another. Before new hardware can go into production, the physical environment has to be able to support it. Our team plans for the power, airflow, rack layout, cabling, and other physical requirements each deployment needs, working closely with our colocation providers along the way.

Those decisions are closely connected. A server that stores more data or delivers more compute may also draw more power or generate more heat. That can change how racks are designed, how equipment is cooled, and even how much hardware a particular area of a data center can support. As infrastructure becomes more powerful and denser, getting more from the hardware depends on making sure the environment around it can evolve, too.

One recent example illustrates how those tradeoffs play out in practice. As Dropbox deployed its seventh-generation servers, the increased power requirements exceeded the capacity of the existing rack power design. Rather than rebuilding the underlying facility infrastructure, the Hardware Engineering and Datacenter Engineering teams redesigned the rack power architecture, doubling the number of power distribution units per rack while continuing to use the existing busways. The result supported the new hardware without requiring major changes to the data center itself.

It's a reminder that infrastructure improvements don't stop with the hardware itself. As demand grows and hardware evolves to meet it, each new generation has to fit within the constraints of the environment around it. 

The work reflects more than a decade of engineering investment across Dropbox's infrastructure. Capacity planning, fleet optimization, storage systems, hardware lifecycle management, and data center engineering each address different challenges, but together they help us make better use of the infrastructure that supports our products.

None of this work is one and done. As customer demands change, hardware evolves, and new technologies introduce opportunities and new constraints, we improve our infrastructure, each update building on the ones that came before it.

Those lessons have become even more relevant as demand for digital infrastructure continues to grow. AI is accelerating the need for storage and compute across the industry, but the underlying engineering challenge hasn't changed. Infrastructure still has to scale while remaining reliable, efficient, and resilient. As these technologies evolve, we'll continue building systems that support the products our customers rely on today while giving us the flexibility to support what's next.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.jobs to see our open roles.

This blog post may contain forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. Words such as "believe," "may," "will," "anticipate," "expect," "plan," and similar expressions are intended to identify forward-looking statements. We have based these forward-looking statements largely on our current expectations and projections about future events and trends, and these forward-looking statements are made only as of the date of this blog post. We assume no obligation and do not currently intend to update any such forward-looking statements after the date of this post.

Every day, Dropbox products transform enormous amounts of content behind the scenes. Open a PowerPoint deck on your phone in Dropbox, and it’s rendered into a crisp preview you can quickly browse. Finalize an agreement in Sign, and it's flattened into a PDF. Upload a video to Replay—our video review and approval tool—and it's transcoded into a lightweight version that streams instantly. These experiences span different products, but they're all powered by the same underlying system.

That system is Riviera, our content processing platform that’s been iteratively improving content transformation in our products for roughly a decade. Whenever a file needs to be prepared for another application, Riviera does that heavy lifting in the background while operating at a massive scale. (For example, Riviera transforms vast amounts of massive media into streamable content, each day producing output equivalent to 8 years of video). Initially, Riviera started as an internal service for generating file previews, but over time, it evolved into a shared platform used across Dropbox by product teams like Search, Replay, Sign, and Dash. We are now making these capabilities available to our developer ecosystem and design partners through API and Model Context Protocol tools.

As Dropbox built AI-powered products like Dash, the need for reliable, reusable content transformation only grew. Before an AI model can answer questions about a document or summarize a report, that content has to be extracted, converted, and prepared in a consistent way—a challenge many developers now face as they build AI applications of their own. Whether you're building a content management system, automating document workflows, indexing files for search, or preparing documents for AI applications, you can now use our API to build on the same infrastructure that powers Dropbox products.

In this story, we’ll cover how Riviera grew from a preview service into a shared platform, the architectural decisions that made that possible, and why we've opened those capabilities to engineers outside of our organization.

Because Dropbox users store all kinds of files, they need to be able to open any of them on any device quickly and see something useful. These are what we refer to as previews, a visual representation of your files across Dropbox surfaces. Meeting that expectation is harder than it sounds. Dropbox supports more than 300 file formats, each of which can produce multiple outputs: thumbnails, full previews, extracted text, streaming manifests, metadata, and more. To do this, we needed to consider how to build a system to serve these previews.

Building a separate service for every file format and every output would quickly become unmanageable. Doing so would mean many capabilities would end up duplicating small pieces of other capabilities. Imagine both PowerPoint and Word processing needing PDF logic, if they lived as separate services we then have to maintain similar PDF logic in two places. This would make maintenance more difficult and spread redundant dependencies around the environment where Dropbox runs (the collection of software and hardware that make up our architecture). Configurations would drift, package versions would skew, and the operational burden would grow.

This meant we needed a managed platform, a place where we could construct these services to be shared across many different features. We needed one place where the dependencies and tools could live, with a team that could build deep expertise in these capabilities. We also needed a design that could scale against all of our stored file types and make the platform itself manageable.

In attempting to solve for this problem, the breakthrough came when we stopped thinking about every preview as a separate feature. Instead, we broke each task into a series of smaller transformations that could be reused. Rendering a PowerPoint preview, for example, doesn't require a custom PowerPoint renderer from start to finish. Riviera first converts the presentation into a PDF, then turns each PDF page into an image that can be displayed anywhere. 

Those same PDF-to-image steps can also be reused for PDFs themselves and for other workflows that need page images. By building reusable transformations instead of one-off pipelines, we could support new file types and new products without starting from scratch each time.

That idea shaped Riviera’s architecture. We built a central point for collecting requests, composing the work to be done, and dispatching that work to backend workers. This central piece validates requests and caches responses which protects the backend workers from duplicate or invalid work. Each backend worker belongs to a specific type of transformation, which allows us to have one point of maintenance and scaling per capability. Today, Riviera has more than 100 such capabilities performing hundreds of thousands of transformations every second.

Separating coordination from execution made the platform easy to extend. Supporting a new file format or a new type of transformation usually meant adding another plugin rather than changing Riviera's core infrastructure. As Riviera grew, the core system stayed stable while its capabilities continued to expand.

While Riviera wasn't originally intended to be a shared platform—it started as an internal tool run by a dedicated Previews team—it didn't take long for other teams to recognize they had similar content transformation problems. For instance, the thumbnails created for previews turned out to be equally useful for machine learning teams normalizing images for feature extraction. If both consumers could use the same 160×160 thumbnail, Riviera only had to generate it once.

The Search team soon adopted Riviera to prepare documents for indexing. As Dropbox expanded with products like Sign, DocSend, and Replay, those teams also found they could reuse existing transformations instead of building new infrastructure. As adoption grew internally across our organization, we opened the plugin model to product teams themselves. Engineers could contribute new transformations while the Riviera team maintained the platform's core architecture. Plugins became Riviera's shared library of transformations.

Dropbox Replay, our video review product, became one of the best examples of this model in practice. To build a video review product, you have to complete the complex task of transcoding and manipulating video data. Riviera was able to fill that need, allowing the product to grow rapidly and iterate on its capabilities instead of building from the ground up. 

A pattern emerged. Product teams identified a transformation they needed. Riviera exposed an existing capability or added a new plugin. Features that might once have taken months shipped in weeks, and every addition made the platform more capable for the next team that adopted it.

When Dash brought AI to Dropbox, it created a new kind of demand for Riviera. Before an AI model can answer a question about a document or summarize a report, the document has to be transformed into something the model can understand. Doing that well means extracting text, recognizing scanned pages, pulling out metadata, and converting hundreds of different file formats into a consistent representation. 

Those aren't AI problems. They're content transformation problems, and they're exactly what Riviera was built to solve. Just as Replay found value in Riviera’s media capabilities, the Dash team was able to accelerate their content processing pipelines by using existing Riviera features.

Because Riviera already supported hundreds of file types and transformations, the Dash team didn't have to build a new document processing system from scratch. As Dash ingests content from Dropbox, Google Drive, Slack, and other connected sources, Riviera prepares those files for indexing and AI. Later, when someone asks a question about a document, those transformed contents are then used as relevant context for the models to generate a response.

That investment paid off well beyond Dash. Improvements to text extraction made both AI responses and search results more accurate. Faster caching reduced the work required to generate previews, answer questions, and process documents. Support for a new file type only had to be added once before it became available everywhere Riviera was used.

That's the advantage of shared infrastructure. Instead of every product solving the same content transformation problems independently, Dropbox solves them once in Riviera, and every product built on top of it benefits.

Riviera started with a single goal: make it possible to preview any file stored in Dropbox. Solving that problem meant building reusable content transformations instead of product-specific pipelines. As more teams across Dropbox adopted the platform, Riviera expanded far beyond previews to support hundreds of file formats and increasingly diverse workloads, powering features across Search, Replay, Sign, Dash, and more.

That growth shaped both the platform and the philosophy behind it. Unlike a feature, which delivers value once, a platform becomes more valuable every time another team builds on it. Each new product introduced new file types, workloads, and requirements. Every improvement made Riviera more capable, and every team building on top of it benefited from those investments.

The platform was also designed to scale without becoming more difficult to maintain. Its plugin architecture allows engineers to add support for new file formats and transformations without changing the core system, while clear boundaries around what belongs in Riviera have kept it focused on transforming content reliably at scale.

Today, we’re extending that reuse beyond Dropbox by making a growing set of Riviera capabilities available through our public API and MCP tools. The platform that began as an internal preview service is now infrastructure that developers can build on, too. And while the technology has changed dramatically over the past decade, the idea behind Riviera hasn't. Build reusable systems around common problems, and they'll continue creating value long after the original use case is gone. To learn more about the available capabilities, visit our developer portal here.

Acknowledgments: Special thanks to Team Riviera, as well as everyone who contributed along the way and helped bring Riviera to where it is today.

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit jobs.dropbox.com to see our open roles.

The AI features in Dropbox bring together company knowledge from documents, messages, meetings, and other sources. Users can then ask questions in one place and get answers from the Dash chat agent. Agent quality—how well our chat agent helps users accomplish their goals—is evaluated using a suite of large language model-as-judge evaluations. These evaluations provide a way to measure how well an agent is performing and identify opportunities to improve. Rather than judging only a final response, they inspect the full trajectory an agent takes to satisfy a user’s goal: how it interprets intent, gathers context, uses tools, handles ambiguity, grounds its answer, and completes the task.

We built agent evaluations as the foundation for improving the chat agent. These evaluations are the powerhouses behind the judges that measure the chat outcomes, given the context available to the agent, including relevance, reasoning quality, evidence use, robustness, task completion, and alignment with user asks. Once we had that foundation, we used DSPy to turn evaluation into improvement. DSPy is an open-source framework for optimizing AI systems using evaluation feedback. 

We applied DSPy and its optimization algorithms in two stages. First, we used it to improve the judges themselves, calibrating them against a small set of human-labeled examples so their scores better matched human judgment. Then, we used those improved judges to optimize the chat agent’s system prompt. This created a feedback loop: human labels improved the judges, the judges produced scalable evaluation signals, and those signals improved the agent. As a result, users saw significantly fewer incomplete answers and we were able to reduce our token usage too, without compromising answer quality.

In this story, we’ll explain how we set up the evaluation layer, calibrated judges against human labels, applied DSPy—along with its optimization algorithms such as GEPA and MIPROv2 to improve judge performance—and then used those judges to optimize the chat agent itself.

Agent evaluation is significantly more complex than traditional search relevance evaluation because the object being judged is no longer a single, isolated output. Instead, it is the result of a multi-step process. The agent must interpret user intent, gather context, and decide when and how to use tools. It also needs to synthesize information across sources before determining whether to answer directly, search for more information, summarize its findings, or ask for clarification.

This makes evaluation much broader. A good agent response might depend on multiple knowledge sources, including documents, prior messages, meeting notes, or tool calls such as search and read documents. The quality of the final answer depends not only on what information was found, but also on how the agent approached the task. 

Agent interactions can also unfold across multiple turns. The system may need to clarify an ambiguous request, incorporate user feedback, revise its answer, or continue searching as the task evolves. As a result, evaluation cannot focus only on the final response. It must also assess the decisions that led there.

Because an agent is made up of multiple interacting components, each part of that process needs its own evaluation. We have to assess not just answer quality, but also intent understanding, tool use, context selection, synthesis, grounding, turn-by-turn adaptation, and overall task completion. Evaluating these dimensions separately helps us identify where failures occur and improve the underlying components more effectively. 

This raised an important challenge: before we could use evaluations to improve the chat experience, we first needed to ensure the judges themselves were reliable.

To evaluate chat responses, we needed an LLM judge that could assess an answer in the context of the user’s intent. But before we could trust those judges, we needed to know whether their evaluations aligned with human judgment. That meant starting with a small set of human-labeled examples and an evaluation rubric that engineers could apply consistently.

We sampled a set of internal chats, including the final responses and trace logs showing how the agent arrived at them, then asked human evaluators to review each example across five dimensions: user intent following, semantic relevance (how well the answer addressed the user's request), tool calling, instruction following, and context selection. Together, these dimensions capture what makes a chat agent valuable. They measure whether the agent understands the user's goal, gathers the right context, uses its tools effectively, follows instructions, and ultimately produces a grounded, useful response.

To keep assessments consistent, evaluators followed a structured review process. They first determined whether the agent understood the user’s intent and selected the right context. They then reviewed the searches, retrievals, and other tool actions used to gather that information before checking whether the claims in the final response were supported by the selected evidence. Finally, they scored the response for relevance, grounding, completeness, and instruction following.

Several metrics were scored on a 1–5 scale. Evaluators also recorded reasoning notes explaining their scores and assigned failure codes for issues such as stale evidence, missing context, unsupported claims, incomplete coverage, or failure to personalize. The reasoning notes captured why a response succeeded or failed, while the failure codes provided a structured way to categorize recurring problems.

This richer supervision proved especially valuable. A score provides a useful summary, but the reasoning notes and failure codes reveal what went wrong and where. They can show whether the agent misunderstood the user’s intent, selected the wrong context, made a poor tool decision, missed an instruction, or produced an answer that was only partially relevant. That gave us signal not just on response quality, but on the underlying causes of failure.

These annotations were useful to optimize the judge’s prompts to minimize disagreements between the LLM judge and the human labelers, but they were also useful beyond judge training. Annotations also helped with debugging, error analysis, roadmap planning, and prioritizing improvements to the agent system. Most importantly, they gave us a reliable benchmark against which we could measure and improve the judges themselves.

With the rubrics and labeled data in place, we could begin improving the judges themselves. Our goal was to make the judges agree more closely with human evaluators while preserving the structured evaluation process. Doing so required more than a generic scoring prompt. The judge needed to follow a specific workflow (retrospectively, or reviewing traces after the chats ended): infer the user's intent, inspect the conversation, review the trace and supporting evidence, reason about context selection and tool use, and then assign a score along with failure codes and reasoning notes.

To improve judge performance, we used DSPy and optimization algorithms such as GEPA and MIPROv2. Think of DSPy as the toolkit, and GEPA and MIPROv2 as specific algorithms within that toolkit. These algorithms automatically proposed prompt changes and tested them against our human-labeled examples to identify improvements. 

We supported several optimization strategies. In some cases, we allowed DSPy to rewrite a judge's instructions from the ground up. In others, we adapted an existing judge to a different underlying model while preserving the same evaluation behavior. We also supported targeted optimization, where the goal was to correct specific failure modes, such as over-scoring outdated information or underweighting missing context, without changing the overall rubric or evaluation process.

Regardless of the optimization strategy, we relied on both scores and textual feedback from human evaluators. The scores told us when a judge disagreed with humans, while the feedback helped explain why. For example, if a judge consistently gave high scores to answers that relied on outdated information, we could update its instructions to better recognize and penalize that failure mode. Once we had judges that reliably reflected human judgment, we could use them as the foundation for improving the agent itself.

Our chat agent’s prompt optimization used to be a largely manual process. Engineers reviewed failures, proposed prompt edits, tested them, and iterated. While this helped in individual cases, it was difficult to scale and hard to know whether a change would reliably improve production quality. We replaced that workflow with an automated, evaluation-driven loop built on labeled examples, production-aligned scorers, and offline counterfactual replay. For each GEPA round, a candidate prompt is replayed on representative historical Dropbox internal chats, and the resulting agent outputs are scored by the evaluation pipeline. Those scores, along with structured judge reasoning, become the feedback signal GEPA uses to propose the next prompt update.

This grounds prompt optimization in realistic agent behavior rather than abstract examples or ad hoc judgments. The same replay infrastructure used to diagnose production failures is now part of the optimization loop itself, so each candidate is evaluated against representative interactions before being considered for launch. Optimization focused on concrete failure modes, including wrong context selection, incomplete answers, missed ambiguity, incorrect search-tool use, and loss of multi-turn context. 

The result was a tighter feedback loop. We replayed representative examples, scored them with production-aligned evaluators, used those scores to guide the next GEPA proposal, and repeated the process until the data supported a launch candidate.

To measure the impact of this prompt optimization work, we focused on failure modes tied to semantic relevance and answer quality. (As mentioned earlier, semantic relevance measures whether the agent understood the user's request and addressed the right parts of it.) Answer quality measures whether the response was complete, useful, grounded, and well-formed. In practice, this meant tracking issues like incomplete answers and missed key aspects of a user's request.

For each new prompt, we compared its performance against the existing production prompt using the same set of examples. This gave us a cleaner apples-to-apples comparison and made it easier to determine whether a prompt change actually improved performance. We also tested whether the gains were statistically meaningful. 

We used statistical tests to check whether the observed improvements were likely to reflect a real change, rather than random variation in the evaluation results. The optimization loop increased experimentation velocity. In the first two weeks, we generated six prompt candidates automatically, compared with five manual prompt changes in the prior month, nearly doubling the pace of exploration.

The launch results were measurable: a 26% reduction in incomplete answers and a 13% reduction in missed key aspects, with improvements appearing within the first 24 hours. The optimized agent also became more efficient. Total token usage dropped by 5.4%, while average completion length decreased by 9.8%. Importantly, these efficiency gains did not come at the expense of answer quality.

Together, these results show how agent evaluations and DSPy can create a practical feedback loop for improving agent behavior: identifying failure modes, generating candidate prompts, validating quality gains, and reducing serving costs.

One of the biggest lessons from this work is that automated prompt optimization needs strong guardrails. We intentionally constrained most agent prompt edits to small, targeted instruction updates and added automated review checks for prompt structure, completeness, caching behavior, and size limits. These safeguards helped ensure that candidate prompts remained maintainable and production-safe as the optimization process became more automated.

More broadly, this experiment showed that prompt optimization brings traditional machine learning discipline to prompt engineering. By combining human-labeled evals, representative replay data, and GEPA-based optimization in DSPy, we treated prompts as measurable, optimizable artifacts rather than static instructions. This framework gave us a systematic way to search over the instructions, constraints, examples, and policies that shape model behavior, helping us move beyond intuition and manual iteration to identify failure modes, compare improvements, and validate impact before launch.

Longer term, agent optimization may look less like manual prompt iteration and more like a continuous machine learning workflow: replay representative data, run optimization jobs, compare candidates against evaluation datasets, review evidence, and ship validated improvements. As with traditional ML systems, weak evaluation signals can lead to brittle improvements, while strong evaluations, representative data, and expert review help changes generalize and keep regressions under control.

The broader takeaway is that agent optimization works best when automation is paired with rigorous evaluation. Reliable judges, representative replay data, and clear success metrics create the feedback loop needed to improve agent behavior while keeping quality measurable and regressions under control.

Acknowledgments: Jongmin Baek, Josh Wilson, Akshay Bapat, Gonzalo Garcia, April Liu, Eric Wang, Hans Sayyadi, Prasang Upadhyaya, and Emeka Okafor Jr. We’re also grateful to the DSPy community for their engagement and support. Our DSPy collaborators offered guidance, discussions, and responsiveness as we applied DSPy to real production systems at Dropbox.

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit jobs.dropbox.com to see our open roles.

Every security team knows the drill: a new feature goes through design review, a threat model is produced, mitigations are agreed upon, and then development begins. In many cases, by the time implementation reaches code review, the process where engineers review code changes before they go live, the original security requirements are no longer visible in the workflow. A threat model, which outlines potential security risks and the protections a feature should include, often lives in a separate document or system from the code itself.

This separation creates a challenge. Implementation often happens weeks or months after the original security review, making it difficult for reviewers to verify that the agreed-upon security requirements were actually implemented. At Dropbox, we wanted to understand how often this gap appears in practice. 

That led us to build a system that combines three technologies: Model Context Protocol, foundational large language models (which we’ll refer to as foundational models), and Dash, the AI capabilities within Dropbox that make it easier to find and understand your team’s content. Together, these technologies automatically retrieve relevant threat models during code review and evaluate whether code changes align with the requirements defined in them. Because Dash already indexes and connects content stored in Dropbox and across our connected applications, the system can draw on years of security reviews and engineering documentation without requiring teams to manually link those sources together.

In this post, we’ll walk through the architecture behind that system, what we learned from analyzing months of threat models, and how we think the same pattern can apply to other forms of design and compliance review.

Organizations make important decisions about a product long before it ships—such as decisions about threat protection. That said, security reviews only create value if the requirements they produce remain visible throughout the development process. Our engineers wanted to make sure those requirements are upheld as development continues and also identify any gaps.

During a security review, engineers identify potential risks, discuss how a feature could be exploited, and agree on the protections that it should include. Those decisions are recorded in a threat model. But once development begins, those decisions often become separated from the code itself. The threat model lives in a wiki or documentation system, while the code is implemented through pull requests (PRs), the units of work engineers submit for review before changes are merged into a product. Unless someone explicitly links them together, reviewers may never see the security requirements that were agreed upon earlier.

At Dropbox, we maintain threat model documents spanning years of product development. Each one represents hours of security engineering work, but that work only provides ongoing value if reviewers can access it when implementation happens. To understand how often that connection persists, we examined the relationship between threat models and the PRs that implement the features they describe. Through that investigation, we learned that only 12% of implementing PRs link back to their original design review and threat model.

The gap is compounded by how much time often passes between review and implementation. When we measured the interval between design review filing and PR creation across 79 verified pairs, we found that more than half (54%) of implementing PRs weren’t opened until over a month after the review was filed. The median delay was about five weeks, with a long tail stretching beyond 11 months. Only 29% of implementing PRs were opened within the first two weeks of security review.

In other words, there can be a long delay between when security requirements are defined and when the corresponding code is reviewed. By the time reviewers look at the implementation, the decisions made during the security review may be buried in documentation they never open.

Why existing tools don’t solve this
Once we understood the scope of the gap, the next question was whether existing security tools could close it. For example, while static analysis tools inspect code for known patterns and potential issues, they can only tell you that a security control is present. What they can’t tell you is whether it was implemented according to the requirements agreed upon during design review. They analyze the code itself, not the context or intent behind it.

Organizations often try to address this challenge by asking engineers to link code changes to design reviews or by deploying bots that remind developers to follow review procedures. But these approaches depend on engineers remembering extra steps, and compliance tends to decline over time. What was missing was a way to connect code changes with the security guidance that already exists. We realized the problem wasn’t a lack of security knowledge. Most organizations have invested significant effort in documenting risks and mitigations through threat models. The challenge is making that knowledge available when code is being reviewed.

Our data suggested another opportunity as well. About 15% of design reviews were filed retroactively, meaning the code was built first and the security review came later, often before a broader launch. These cases suggest that some security-sensitive work isn’t always identified as requiring review when it’s implemented. A system that can surface relevant security context during development and not after could help in both directions: connecting code to existing reviews and providing an early signal when additional review may be warranted.

We needed a way to connect code under review with the security guidance that already existed elsewhere in the organization. Dash provided a natural starting point. Because it indexes content across connected applications, our collection of threat models was already searchable alongside other engineering documentation. Rather than relying on reviewers to find the right security documentation, we built a system that automatically retrieves relevant threat models when code is submitted for review.

Model Context Protocol (MCP) is what lets the agent access the information it needs. Dash has an MCP server that makes the content it indexes available to other AI tools. In our case, the security review agent uses Dash’s MCP server to search and read the same connected content that powers Dash search, including threat models and related documents. That gives the agent the context it needs without requiring a custom integration for every source system.

When a code change is opened for review, the agent retrieves relevant threat models and other supporting context through MCP. The foundational model can then examine both the documented requirements and the proposed code change together. For example, it can recognize that a threat model requires authentication on an endpoint and determine whether the code being introduced actually enforces that requirement.

That ability to reason across multiple sources of information is what distinguishes this approach from traditional static analysis. The system isn’t just inspecting code. It’s comparing implementation against previously documented security decisions.

Meeting developers where they work
Just as important as the retrieval architecture was where we surfaced the results. Rather than creating a separate security workflow, we integrated the system directly into code review. Engineers review code before it’s merged, so we focused on bringing additional security context into a process that already exists.

This distinction matters because security teams have spent years building tools that generate alerts, comments, and notifications. Developers, in turn, have spent years learning which ones they can safely ignore. The difference between a useful security signal and noise is relevance. A finding tied directly to the code being reviewed is far more likely to be useful than a generic warning that appears on every change.

At the same time, retrieving a threat model is only the first step. Simply placing a security document next to a code review still leaves a human responsible for reading both and determining whether they align. The foundational model performs that comparison automatically, identifying potential gaps between documented requirements and implementation. Human reviewers remain responsible for the final judgment, but the model eliminates much of the manual cross-referencing that would otherwise be required.

To validate the approach, we analyzed all 150 of our security design reviews from the previous year and a half and mapped each to its implementing code changes. To do this, we used Dash’s semantic search capabilities, which retrieve related content based on meaning rather than exact keywords or explicit references. The connections exist, but they’re often invisible:

• Using Dash’s semantic search—the same retrieval capability that powers its user-facing search—we successfully linked 80% of design reviews to their implementing code changes
• Only 12% of those code changes explicitly reference the design review
• 69% of connections were recoverable only through semantic search, meaning most of the relationship between design reviews and implementation would be invisible through manual references alone

We also evaluated the impact of surfacing threat model context during code review. In our testing, context retrieval consistently surfaced security findings that were invisible without the threat model, including missing controls, contradictions with approved designs, and regressions against known risks. The code was functionally correct in every case. The gaps were only visible when reviewers could compare the implementation against the original requirements.

More importantly, when we examined security incidents, we found cases where the root cause was a security requirement that had been documented during design review but wasn’t enforced in the implementing code. The connection existed; it just wasn't visible at the right moment. These weren’t rare edge cases. They were straightforward requirements that became disconnected from implementation as development progressed.

This is the difference between reviewing code and reviewing implementation against design. The former catches bugs. The latter catches security gaps. And it’s only possible when a model can reason about the relationship between two documents—the threat model and the pull request—rather than analyzing either one in isolation.

As we integrate this into our development workflows, we’re designing around a few core principles. Findings must be validated against the actual code before they reach a developer, because false positives destroy trust faster than true positives build it. Every finding should be traceable back to a specific requirement and source document so reviewers can verify the reasoning for themselves. Most findings should be advisory rather than blocking, with escalation reserved for confirmed gaps between approved designs and implementation. And because requirements evolve over time, the system must account for stale context rather than blindly applying outdated guidance.

The architecture isn’t specific to security, either. It’s a general solution for any team that produces design documents and needs to verify they’re reflected in implementation. For example, privacy teams can surface data classification requirements when code touches user data flows. A privacy review that specifies a field must not be logged can be checked against future code changes that handle that field. Platform teams can surface API contracts and compatibility requirements when interfaces change. And compliance teams can surface regulatory requirements when code handles data in regulated jurisdictions.

The common pattern is straightforward: organizations already have documented requirements, but those requirements are often disconnected from the workflows where implementation decisions are made. By combining searchable organizational knowledge, MCP-based retrieval, and foundational models capable of reasoning across multiple sources of context, it’s possible to automatically compare implementation against intent.

The scanning tools and threat models already existed. What we were missing, however, was a way to connect them at the right moment. MCP makes that connection technically feasible. Dash makes it practical. And foundational models make it useful, turning "here’s a relevant document" into "here’s a specific gap between what was required and what was implemented." While security is our first use case, the same pattern can help any team ensure that the decisions made during planning and review are reflected in the systems they ultimately build.

Acknowledgments: Wei Dai, Jan Nunez, Nicholas Plewtong, Jonathan Hawes, Po-Ning Tseng, Adrian Wood, Steven Kisely, Adam Pindelski, Qingbo Jiang, and the Dash team.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit jobs.dropbox.com to see our open roles.