dropboxJul 20, 2026

How our universal content processing platform Riviera evolved for AI and beyond (opens in new tab)

Riviera evolved from Dropbox’s preview-generation service into a shared content-processing platform used by products including Search, Replay, Sign, and Dash. Its core insight was to compose reusable transformations rather than build separate pipelines for every file type and output. As AI increased demand for consistent document extraction and preparation, Dropbox expanded Riviera’s capabilities and began offering them through APIs and Model Context Protocol tools. ## The Preview Problem - Dropbox supports more than 300 file formats, each requiring outputs such as: - Thumbnails - Full previews - Extracted text - Streaming manifests - Metadata - Building a separate service for every format and output would duplicate logic, dependencies, and operational work. - Configurations and package versions could drift across services, making the system harder to maintain and scale. ## Reusable Transformations as the Foundation - Riviera treats previews as sequences of smaller, reusable transformations. - For example, a PowerPoint preview can be produced by: - Converting the presentation to PDF - Rendering each PDF page as an image - The same PDF-to-image transformation can support PDFs and other workflows requiring page images. - This approach enables new formats and products to reuse existing capabilities instead of starting from scratch. ## Separating Coordination from Execution - Riviera uses a central coordinator to: - Collect and validate requests - Compose transformation workflows - Cache responses - Dispatch jobs to backend workers - Each worker handles a specific transformation, creating a clear unit for maintenance and scaling. - The platform now includes more than 100 capabilities and performs hundreds of thousands of transformations per second. - New formats and transformations can generally be added as plugins without changing the core system. ## From Internal Service to Shared Platform - Other Dropbox teams quickly adopted Riviera when they discovered overlapping content-processing needs. - Machine learning teams reused preview thumbnails for image normalization, avoiding duplicate generation. - Search used Riviera to prepare documents for indexing, while Sign, DocSend, and Replay reused existing transformations. - Dropbox eventually opened the plugin model to product teams, allowing them to add capabilities while the Riviera team maintained the platform’s core architecture. - Replay particularly benefited from Riviera’s complex video transcoding and manipulation capabilities, accelerating product development from months to weeks. ## Supporting AI Workloads - Dash introduced greater demand for reliable document preparation before AI processing. - AI systems require content to be transformed into consistent, machine-readable representations, including: - Extracted text - Data from scanned pages - File metadata - Normalized versions of hundreds of file types - These are fundamentally content-transformation challenges rather than AI-model challenges. - Because Riviera already supported many formats and transformations, Dash could build on existing infrastructure instead of creating a separate document-processing system. ## Broader Availability - Dropbox is making Riviera’s capabilities available to external developers and design partners. - Access is provided through APIs and Model Context Protocol tools. - The platform is intended for applications such as content management, document automation, search indexing, and AI document processing. Riviera’s evolution demonstrates the value of a shared transformation platform: reusable workers reduce duplication, centralized coordination improves reliability, and each new capability benefits multiple products. For teams building content-heavy or AI-powered applications, using standardized transformation infrastructure can be more efficient than maintaining format-specific pipelines independently.

plugin-architectureaimodel-context-protocoldistributed-systems+3

cloudflareApr 20, 2026

Orchestrating AI Code Review at scale (opens in new tab)

Cloudflare built a CI-native AI code review system to reduce review bottlenecks without overwhelming engineers with noisy or generic model feedback. Instead of using one large prompt, it orchestrates up to seven specialized agents for areas such as security, performance, compliance, and documentation, then uses a coordinator to deduplicate and assess findings. The system now reviews tens of thousands of merge requests, approving clean changes and blocking serious bugs or vulnerabilities. ## Why Naive AI Review Wasn’t Enough - Traditional code review can leave merge requests waiting for hours and creates repeated context switching. - Commercial AI review tools provided useful functionality but lacked the flexibility and customization required across Cloudflare’s organization. - A basic “send the Git diff to an LLM” approach produced: - Vague recommendations - Hallucinated syntax errors - Repetitive advice such as adding error handling where it already existed - Complex codebases required specialized analysis rather than generic summarization. ## Specialized Agents and Coordination - The system launches up to seven focused reviewers covering: - Security - Performance - Code quality - Documentation - Release management - Internal Engineering Codex compliance - A coordinator agent: - Deduplicates overlapping findings - Evaluates the actual severity of issues - Produces one structured review comment - The system can actively block merges when it detects serious defects or security vulnerabilities. ## Plugin-Based Architecture - The platform uses composable plugins so it can support different: - Version-control systems - AI providers - Internal standards - Repository-specific requirements - Each plugin implements a `ReviewPlugin` interface with three lifecycle phases: - `bootstrap`: Runs concurrently and is non-fatal. - `configure`: Runs sequentially and is fatal if essential configuration fails. - `postConfigure`: Handles asynchronous work after configuration assembly. - Through `ConfigureContext`, plugins can: - Register agents and AI providers - Set environment variables - Inject prompt sections - Configure agent permissions - Plugins contribute through the context API rather than accessing the final configuration directly. - The core assembler combines these contributions into `opencode.json`. - This separation prevents unrelated components from becoming tightly coupled; for example, GitLab logic does not need to understand Cloudflare AI Gateway settings. ## Plugin Responsibilities - `@opencode-reviewer/gitlab` - Provides GitLab merge request data and a comment server. - `@opencode-reviewer/cloudflare` - Configures AI Gateway model tiers and fallback chains. - `@opencode-reviewer/codex` - Checks compliance with internal engineering RFCs. - `@opencode-reviewer/braintrust` - Adds distributed tracing and observability. - `@opencode-reviewer/agents-md` - Verifies that repository `AGENTS.md` instructions are current. - `@opencode-reviewer/reviewer-config` - Retrieves remote model overrides for individual reviewers. - `@opencode-reviewer/telemetry` - Tracks reviews asynchronously. ## Why OpenCode - Cloudflare already used OpenCode extensively and understood its behavior. - Its open-source implementation allows engineers to: - Investigate problems directly - Contribute fixes upstream - Extend the system through its SDK - Cloudflare engineers had contributed more than 45 upstream pull requests at the time of writing. - Its server-first design was especially important: - Review sessions can be created programmatically. - Prompts can be sent through an SDK. - Multiple concurrent sessions can be managed without scraping or wrapping a CLI interface. ## Coordinator Process - The coordinator runs OpenCode as a child process using `Bun.spawn`. - Its prompt is passed through `stdin` rather than a command-line argument. - This avoids Linux’s `ARG_MAX` limit, which previously caused `E2BIG` failures for unusually large merge requests containing extensive descriptions or logs. - OpenCode runs with `--format json`, emitting JSONL events through standard output. - This event-based interface allows the orchestration layer to collect and process results from concurrent reviewer sessions. A practical takeaway is to treat AI review as an orchestrated CI system rather than a single LLM prompt. Specialized agents, strict plugin boundaries, structured outputs, and observability are essential for making automated review reliable enough to influence merge decisions at organizational scale.

plugin-architecturedatabase-designllmgitlab+4

figmaJul 31, 2019

Automate work. Bring in data. Extend what’s possible with Figma Plugins. | Figma Blog (opens in new tab)

Figma introduced plugins to make the platform more extensible, reliable, and accessible to both designers and developers. The goal was to let anyone with basic HTML and JavaScript skills build tools that automate repetitive work, bring real-world content into designs, and address needs such as accessibility. After six weeks of beta testing, more than 40 community plugins were publicly available, with private distribution also supported for organization customers. ## Why Figma Built a Plugin Platform - Designers already depended on plugins, but many were unreliable or insecure because they used unsupported APIs. - Designers without coding skills had to wait for someone else—or for engineering resources—to build the tools they needed. - Figma designed its plugin architecture to be: - Secure - Stable - Performant - Familiar to web developers - The company’s guiding idea was that anyone who could build a basic webpage should be able to create a Figma plugin. - Building a plugin system for a web-based design tool required significant architectural investment, intended to encourage more creators and experimentation. ## Plugin Availability and Distribution - Plugins became available to the entire Figma community after the beta. - Users could browse plugins within Figma and install them with one click. - Plugins could be launched from a design file’s right-click menu. - Figma Organization customers could: - Build private plugins - Distribute them across their company - Curate approved plugins - Install plugins on behalf of users ## Utility Plugins for Repetitive Tasks - **Similayer**, created by David Williames, selects layers with similar properties so designers can edit them in batches. - **Super Tidy**, created by Ismael González-Nicolás, renames frames and reorganizes them in the layers list. - These tools reduce manual “pixel-pushing” and help designers keep files organized. ## Generative Plugins for Content and Visuals - **Unsplash** lets designers insert Unsplash images directly into Figma files. - **Content Reel**, created by Microsoft, populates designs with searchable text, avatars, and icons. - These plugins help designers work with more realistic and contextual content instead of placeholders. ## Accessibility Plugins - **Contrast Checker**, from Stark, checks whether colors, visuals, and typography have sufficient contrast and readability. - **Color Blind**, created by Sam Mason de Caires, previews designs through eight types of color vision deficiency. - Together, these plugins help designers identify accessibility problems that may otherwise be difficult to notice. Figma’s plugin launch positioned extensibility as a core part of the product: designers could automate workflows, use realistic content, improve accessibility, and create custom tools instead of waiting for platform features or engineering support.

plugin-architecturedesign-systemsaccessibilityjavascript+3