DROPBOX 2026-09-29 Tier 2

Evolving our calendar assistant Reclaim to be AI-native without starting over¶

Summary¶

Reclaim — the Dropbox-owned AI calendar assistant — added a natural-language ("describe your scheduling goal in your own words") interface without rewriting the scheduling system it already had. The engineering thesis is evolution over rewrite: rather than building a separate AI-only path, Reclaim introduced a third actor (the agent) alongside the two it already supported (the user making explicit edits, and the automated background scheduler) and made all three funnel through the same operation abstraction and the same validation/commit path. Three pieces carry the design: (1) an in-house agent platform — agent loop, tools, and context-gathering built directly against model-provider APIs rather than on a broad agent framework — that also speaks MCP as both a client and a server; (2) Schedule Actions, a single internal operation type ("create/update event, change RSVP, find availability") that every actor invokes, so a scheduling rule is changed in one place instead of three; and (3) Preview Mode, a temporary what-if copy of the calendar — computed by a scheduler reworked into a pure function and cached in Redis — that lets users review an agent's proposed changes (and their ripple effects on shared events) before anything commits or notifies other attendees. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)

Key takeaways¶

Evolve, don't rewrite: add the agent as a third actor on the existing scheduling core. Before the redesign Reclaim had two actors — the user making explicit changes (move an event, change a setting) and the automated scheduler that finds time for tasks/habits/meetings in the background. The agent became a third way to drive the same system, not a parallel product. "Creating a separate AI-only path would have duplicated functionality and made Reclaim's behavior harder to keep consistent across interfaces." (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
LLM interpretive variability is the core new risk, and it's why all three actors must share logic. An open-ended request like "make time for this tomorrow" can be interpreted by the model as find an open block, create a new event, or move something already scheduled — each affecting the calendar (and possibly other people's calendars) differently. Because the agent arrives at decisions non-deterministically, routing it through the same validated operations as the deterministic actors is what keeps behavior consistent. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Agent platform = model interprets, agent orchestrates the loop. The model interprets the user and figures out intent; the agent manages the larger process — supplying Reclaim's instructions, the relevant calendar context, and tools (which let it ask Reclaim to look up information or request an action). A tool result is fed back to the model to inform the next step; this repeated exchange is the agent loop. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Context and tools are scoped per request, not handed over wholesale. Reclaim gives the agent only the calendar information and tools relevant to each request "rather than access to everything at once," to keep the agent focused and limited to appropriate actions — a context-budget and least-privilege discipline. Complex requests can be split off to a specialized subagent, with internal checklists and review steps keeping the overall request on track (patterns/specialized-agent-decomposition). (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Build-your-own agent loop over a framework — a deliberate build-vs-buy call. Reclaim built the agent loop, tools, and context system itself and connects directly to model providers. The framework it first explored "lagged behind the provider APIs we wanted to use and included more structure than Reclaim needed." Owning these parts lets them design around scheduling needs, adopt new provider capabilities faster, and swap providers without rebuilding the platform — at the cost of more code to maintain (partly offset by using agents to help maintain it). (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
MCP is used bidirectionally. Inside Reclaim's agent loop, an MCP client lets the agent use compatible tools from other services. Separately, Reclaim's MCP server exposes selected Reclaim tools to supported external AI clients (Claude, ChatGPT) — those clients run their own models and agent loops but can call the same Reclaim tools used internally (patterns/mcp-as-centralized-integration-proxy). (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Schedule Actions = one operation type, one validation/commit path, three callers. Each scheduling capability (create/update an event, change an RSVP, find availability) is represented as a Schedule Action. Whether the caller is a user, the automated scheduler, or an agent, the same Schedule Action type — and the same validation and commit process — is used. This matters because a single change can ripple (moving a meeting alters availability and may force Reclaim to adjust flexible events elsewhere); separate implementations per actor would mean reproducing and re-aligning those rules forever. With a shared action, "engineers can change how an operation works in one place rather than updating three separate versions" (concepts/separation-of-concerns). (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Preview Mode: review the ripple before it commits. Consistent handling isn't enough — users need to see an operation's wider effects before it goes live. Preview Mode gives a temporary version of the calendar where users review AI suggestions / chat-requested changes, see how an event or settings change affects the rest of the schedule, and confirm effects on shared events before updates are sent to other attendees — a human-in-the-loop review gate on agent output. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
Preview is fast because the scheduler was reworked into a pure function. To keep Preview Mode responsive, the automated scheduler was made a pure function: it can compute a proposed schedule without saving anything to the real calendar, and Reclaim re-runs that calculation each time the user adjusts the preview. Because busy calendars and multi-attendee meetings need a lot of data, Reclaim keeps a readily accessible copy in Redis and updates attendee availability within the preview whenever an event moves, so the next calculation reflects the proposed (not the live) schedule. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)
The generalizable lesson: AI inside an active workflow needs context, a controlled way to act, and a review step. Reclaim's framing of what AI needs to be useful inside a live product: surrounding information to understand a request, a controlled way to act on it (shared Schedule Actions), and a review step before the result moves forward (Preview Mode). The payoff is the freedom to add new AI capabilities on the same scheduling foundation instead of fragmenting the product into a separate experience each time models improve. (Source: sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f)

Systems / concepts / patterns extracted¶

Reclaim (new) — Dropbox-owned AI calendar assistant; the subject system. Agent platform + Schedule Actions + Preview Mode.
MCP — used bidirectionally: MCP client inside the agent loop (consume external tools) + MCP server exposing Reclaim tools to Claude / ChatGPT.
Redis — fast-retrieval store holding the working copy of calendar/availability data that powers Preview Mode's repeated what-if calculations.
concepts/separation-of-concerns — Schedule Actions as a single shared operation type + validation/commit path across three actors (change logic once, not three times).
concepts/human-in-the-loop — Preview Mode as a review-before-commit gate on agent-proposed calendar changes, including effects on other attendees.
agent loop — model interprets → agent supplies context + tools → tool result fed back → iterate.
patterns/specialized-agent-decomposition — per-request context/tool scoping and delegation of complex parts to a specialized subagent.
patterns/mcp-as-centralized-integration-proxy — Reclaim's MCP server as the single tool surface reused by both the in-house agent and external AI clients.
patterns/deterministic-tool-vs-llm-judgment — the model handles interpretation/judgment; deterministic scheduling work lives behind tools / Schedule Actions.

Recorded as prose (taxonomy gate — not minted as pages)¶

"Schedule Action" (unified action abstraction across actors) — the strongest reusable idea here, but single-source and article-specific in naming; it maps INTO concepts/separation-of-concerns (shared operation type + single validation/commit path). Left as a tag + prose for Lint promotion at ≥2 sources.
"Preview Mode" / pure-function what-if scheduler — single-source product mechanic; maps INTO concepts/human-in-the-loop (review-before-commit) and the pure-function-for-repeatable-recompute idea. Recorded as prose + tags.
Build-your-own agent loop vs framework — a build-vs-buy stance echoed across the corpus (Fly.io "you should write an agent"), already captured under concepts/agentic-development-loop; tagged, not minted.

Operational numbers / concrete details¶

No latency, throughput, or scale numbers are disclosed (qualitative post).
Concrete architecture facts: agent connects directly to model providers (no broad framework); MCP client + MCP server both present; Schedule Action is the single operation type shared by user / scheduler / agent with one validation + commit path; scheduler reworked into a pure function; Redis holds the fast-access preview copy; attendee availability is updated within the preview as events move.
External MCP clients named: Claude, ChatGPT.

Caveats¶

Marketing tail present ("come build the future with us") but <20% of the body; the architecture (agent platform, Schedule Actions, Preview Mode) is the substance → in scope.
No metrics, no error rates, no adoption figures. The "6× / p95" style numbers common in infra posts are absent — treat all mechanism claims as design-described, not benchmarked.
The subagent "collaboration protocol" and how the agent's proposed Schedule Actions are validated against conflicts are described only at a high level.