Technology

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.

Bringing more of Dropbox into desktop

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.

Building capabilities that can work across platforms

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.

Making the new experience usable by more people

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.

A foundation for what comes next

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.

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.

Connecting an agent to the work already in Dropbox

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.

Making the agent’s work visible and controllable

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.

Building a workspace ready to act on Dropbox files

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.

Making changes easier to review and roll back

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.

From individual experiments to the new Dropbox experience

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.