{"slug": "how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox", "title": "How two engineer side projects became the agent taking action inside Dropbox", "summary": "Dropbox engineers Daniel Reiter Horn and Rich Chan turned two separate side projects into the agent now powering task execution in the new Dropbox experience, which lets users ask questions about their content and request actions such as organizing folders, renaming files, and preparing materials to share. Horn's prototype connected a sandboxed coding agent to Dropbox via rclone so it could build and preview a 3D-printed cityscape model, while Chan spent a week building a graphical interface into the Dropbox desktop app that combined usability, safety, and permission controls and let him process receipt images into expense reports without copying files out of Dropbox. The merged system gives the agent filesystem access, version history for rollback, an isolated workspace for installed software, and permission checks outside that workspace, with changes recorded so users can review and undo them.", "body_md": "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](https://blog.dropbox.com/topics/company/fall-launch-2026-put-ai-to-work-in-dropbox), 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.\n\nThe 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.\n\nMelding 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](https://blog.dropbox.com/topics/company/dropboxs-next-chapter), letting them follow the work, approve access, and review the results.\n\n## Connecting an agent to the work already in Dropbox\n\nThe 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.\n\nThrough an experimental command-line interface, Daniel could describe changes, preview the model on [dropbox.com](https://www.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.\n\nRich, 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.\n\nThe 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.\n\nThe 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.\n\n## Making the agent’s work visible and controllable\n\nTo 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](https://openai.com/index/unlocking-the-codex-harness/), 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.\n\nThe 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.\n\nFor 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.\n\nAs 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.\n\nDaniel 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.\n\n## Building a workspace ready to act on Dropbox files\n\nThe 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.\n\nDropbox already had a system for running an operating system sandbox in our data centers. [Riviera](https://dropbox.tech/infrastructure/how-our-universal-content-processing-platform-riviera-evolved-for-ai-and-beyond), 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.\n\nEach 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.\n\nThe 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.\n\nStarting 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.\n\nStarting 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.\n\n## Making changes easier to review and roll back\n\nEnforcing 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.\n\nApproving 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](https://www.dropbox.com/resources/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.\n\nTo 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.\n\nAttributing 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.\n\n## From individual experiments to the new Dropbox experience\n\nThe 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](https://blog.dropbox.com/topics/company/fall-launch-2026-put-ai-to-work-in-dropbox) 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.\n\nThis 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.\n\nAs the [new Dropbox experience](https://blog.dropbox.com/topics/company/dropboxs-next-chapter) 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.\n\n~ ~ ~\n\n*If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit* *dropbox.jobs* *to see our open roles.*", "url": "https://wpnews.pro/news/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox", "canonical_source": "https://dropbox.tech/machine-learning/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox", "published_at": "2026-11-05 22:53:30+00:00", "updated_at": "2026-11-05 23:20:40.311265+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "artificial-intelligence"], "entities": ["Dropbox", "Daniel Reiter Horn", "Rich Chan", "rclone"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox", "markdown": "https://wpnews.pro/news/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox.md", "text": "https://wpnews.pro/news/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox.txt", "jsonld": "https://wpnews.pro/news/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox.jsonld"}}