---
type: "post"
id: "how-two-engineer-side-projects-became-the-agent-3ab119"
slug: "how-two-engineer-side-projects-became-the-agent-3ab119"
title: "How two engineer side projects became the agent taking action inside Dropbox"
description: "Dropbox describes how two engineers’ side projects became the agent in its new customer experience: one supplied an isolated workspace for tools, the other an in-app interface with permissions and revision history."
retrieval_nugget: "Dropbox describes how two engineers’ side projects became the agent in its new customer experience: one supplied an isolated workspace for tools, the other an in-app interface with permissions and revision history. The account matters because it shows how file-changing agents can be built around explicit access, visible activity and rollback rather than prompts alone."
published_at: "2026-11-05"
updated_at: "2026-11-05"
record_date: "2026-11-05"
date_kind: "published_at"
topics: ["codex"]
entities: ["Dropbox","Codex App Server API","Pi","Daniel Reiter Horn","Rich Chan","rclone"]
related_patterns: ["agent-security-moves-to-runtime-boundaries","harness-architecture-outlives-model-choice"]
novelty_label: "new_fact"
what_changed: "Dropbox describes combining two engineer experiments into an in-product agent, with permission controls, an isolated workspace, change review and rollback for files."
prior_refs: ["https://newruntime.com/posts/what-dropbox-has-learned-from-deploying-ai-at-a9a18f/"]
source_url: "https://dropbox.tech/machine-learning/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox"
source_urls: ["https://dropbox.tech/machine-learning/how-two-engineer-side-projects-became-the-agent-taking-action-inside-dropbox"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:how-two-engineer-side-projects-became-the-agent-3ab119"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/how-two-engineer-side-projects-became-the-agent-3ab119/","markdown":"https://newruntime.com/posts/how-two-engineer-side-projects-became-the-agent-3ab119.md","json":"https://newruntime.com/posts/how-two-engineer-side-projects-became-the-agent-3ab119.json"}
markdown_url: "https://newruntime.com/posts/how-two-engineer-side-projects-became-the-agent-3ab119.md"
---

# How two engineer side projects became the agent taking action inside Dropbox

## Retrieval answer

Dropbox describes how two engineers’ side projects became the agent in its new customer experience: one supplied an isolated workspace for tools, the other an in-app interface with permissions and revision history. The account matters because it shows how file-changing agents can be built around explicit access, visible activity and rollback rather than prompts alone.

## Summary
Dropbox describes how two engineers’ side projects became the agent in its new customer experience: one supplied an isolated workspace for tools, the other an in-app interface with permissions and revision history. The account matters because it shows how file-changing agents can be built around explicit access, visible activity and rollback rather than prompts alone.

## What happened
In a November 5, 2026 post, Dropbox engineers Daniel Reiter Horn and Rich Chan explain that their separate experiments addressed a shared problem: letting an agent work with Dropbox files while keeping people in control of changes. The company says its new Dropbox experience lets people ask questions about their content and request tasks such as organizing folders, renaming files and preparing materials to share. The source does not give a product version, price or rollout schedule.

Horn’s prototype began with a practical need: creating a 3D-printed cityscape model for his son. The family laptop did not have 3D modeling software, so he built a sandbox—an isolated computing environment—with a coding agent and specialized software. He connected it to Dropbox using rclone, allowing the agent to work with online files as though they were in the sandbox. Through an experimental command-line interface, he could describe changes, preview the model on dropbox.com and refine it for printing. Dropbox says that early prototype ran outside the web experience and lacked agent permission controls and conversation-specific undo.

Chan approached the problem through Dropbox’s desktop app. He used a coding agent to turn receipt images into expense reports, but had to copy receipts to a location the agent could access. He built a graphical interface inside the app so the agent could work with files there. It connected to folder pickers, live previews and revision history, letting Chan open changed files and trace a revision to its conversation. Dropbox says the prototype combined usability and permission controls; it does not quantify time saved or report a broader evaluation.

The combined system brings the interface together with a server-side sandbox equipped with software for tasks such as video editing, audio transcription, diagramming and spreadsheet editing. Dropbox says the workspace is bound to its existing permissions, sharing, version history and rollback capabilities. A trusted host layer mediates file access. For a broad request such as organizing photos, the agent first proposes a plan; it cannot request permission to change files until the plan is accepted. It then requests access to relevant folders through a tool, and the app displays an Allow or Deny card. Approval grants access to that location inside the sandbox; the agent does not grant itself access.

The interface presents commands, tool calls, file changes and plan updates as structured events, with status indicators and expandable activity grouped by plan step. Dropbox says its chat interface uses the Codex App Server API, with JSON-RPC messages in JSONL. The protocol organizes work into threads, turns and items. The post also describes an adapter that translates messages from the Pi harness into the Codex protocol, intended to let Dropbox explore other harnesses without rebuilding the interface. The supplied account excerpt ends before describing further implementation or availability details.

## What the archive adds
[What Dropbox has learned from deploying AI at company scale](https://newruntime.com/posts/what-dropbox-has-learned-from-deploying-ai-at-a9a18f/) argued that workflow capacity, not model access alone, limits company-scale adoption. This is a new fact on that known story: the latest account shows one way Dropbox is addressing workflow through permissions, review and rollback. [Agent work is moving into harnesses, factories, and accepted artifacts](https://newruntime.com/posts/agent-work-is-moving-into-harnesses-factories-and-accepted-artifacts/) is related context, though its basis is shared terms rather than the same story.

## Trend signal
This supports [agent security moves to runtime boundaries](https://newruntime.com/patterns/agent-security-moves-to-runtime-boundaries/): Dropbox describes permission checks in a trusted host layer outside an isolated workspace, rather than relying on an instruction to the agent. It also speaks to [harness architecture outlives model choice](https://newruntime.com/patterns/harness-architecture-outlives-model-choice/), since an adapter is meant to connect different harnesses to the same interface. The source describes a design, not independent validation of its security properties.

## Why now
Dropbox frames the work as part of its new customer experience, in which people can ask questions about their content and request actions on files. The account explains how the company brought the two prototypes together for that experience, but it does not establish a launch date or explain broader market timing.

## Connections to other events
An earlier Telegram post described Dropbox’s view that faster AI coding can move bottlenecks into the surrounding workflow. The present account extends that idea from organizational adoption to a specific product design: access approval, progress visibility and revision history surround an agent doing work on company files. The connection is the workflow constraint, not evidence that the two efforts share an implementation.

## Why it matters
File operations make agent autonomy tangible: a system can rename, reorganize or transform work that users depend on. Dropbox’s design suggests that product teams need to treat permissions, observability and recovery as parts of the task interface. A proposed plan can make an ambiguous request inspectable before action; folder-scoped approval limits where the agent may act; and event cards, previews and revision history give users ways to follow and reverse changes. These controls do not prove that errors or unsafe behavior are eliminated, but they offer a more operationally useful design target than a vague promise that an agent will be careful. Teams building agents for shared workspaces can evaluate whether every consequential operation has an explicit authorization point and an understandable recovery path.

## Limits and uncertainty
This is a vendor engineering account, not an independent security audit or user study. It does not report measured task success, error rates, latency, operating costs, adoption, or comparisons with other systems. The article describes permission checks, a sandbox and rollback, but the supplied material does not specify their threat model, isolation guarantees, permission granularity beyond folder access, or behavior under compromised tools. It also does not establish which harnesses customers can use, which tasks or software are available in the shipped experience, or when and to whom it is accessible.

## Skill to build now
For one agent workflow that changes shared files, map the authorization and recovery path before expanding autonomy: define what folders it may request, where approval appears, what activity a reviewer sees, and how a specific change is undone. Test the flow with a broad request that first needs clarification, then check that the agent cannot proceed to file access before a person accepts the plan.

## Reader takeaway
Dropbox’s account is a useful implementation example, not proof that the approach is secure or generally available. Its central lesson is to design file-changing agents as controlled workflows: isolate execution, require explicit access, expose progress and preserve a path to review and undo changes.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Codex](https://newruntime.com/topics/codex.md): Explore the codex topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)