When an AI product shows up inside a tool like Microsoft Office, an inbox, or a browser, the path of least resistance is a narrow one: ship a panel that can summarize whatever is open, and hand everything harder back to a website. We set a higher bar for ourselves. The Brightwave you get inside a Microsoft Office taskpane is the same Brightwave you get on the web: the full agent platform, not a reduced version. The same research engine that can fan a single question out across hundreds of agents and reason over tens of thousands of documents. The same sandboxed code execution, the same document processing across formats, the same per-claim citations that resolve to an exact sentence or cell, the same generated work product: models, tables, memos, decks. The surface changes. What sits behind it, and the scale of compute it can pull on, does not.
The interesting part is the second-order consequence. Those thirteen surfaces are delivered through just six host adapters: a mobile app, a desktop app, the Office add-in, the Chrome extension, the Outlook add-in, and the Google Workspace add-on.¹ Every one of them reaches the same engine. The leverage in that ratio of six adapters to thirteen surfaces is the whole story: a thin adapter at the edge, the entire platform behind it. We got there quickly and with a small team, but the speed is a symptom, not the point. What a correctly placed architectural boundary actually buys you is that new surfaces are adapters, not second products.
The constraint that shapes the product
Brightwave is built for people whose output has to survive scrutiny: investment analysts, diligence teams, anyone who signs their name to the work. For them, the work doesn't live on one website. It's spread across a spreadsheet, a stack of filings, the browser tab open right now, the deck due tomorrow, an email thread.
If a surface only becomes fully capable once the user navigates to its website, it taxes them every time the work gets non-trivial: stop, switch context, re-attach the document they were already looking at, start over. We didn't want a surface that turns out to be a shortcut to leaving it.
We wanted a specific property. An analyst sitting in a workbook should be able to hand Brightwave the selected range and receive the same depth of work they'd get from the web app, without leaving the workbook. Stating that goal is easy. Meeting it is an architecture problem, and a hard one to solve after the fact.
Figure 1. Two ways to put an agent in another app. Left, the path of least resistance: each surface ships a thin feature and the full product lives elsewhere, so a user’s context doesn’t follow. Right, the path we took: each surface is a thin adapter that opens a chat in a Brightwave project, so every surface reaches the full engine.
Two architectures, and the one we chose
There are essentially two ways to build this, and the decision tends to get made early, often implicitly.
The per-surface approach. Treat each surface as its own small product: pick a handful of features that fit the host, reimplement them against that host's APIs, and ship. It has real appeal: it starts quickly, and each surface can be tuned tightly to its host. The cost is structural and arrives later: every surface is a separate codebase to build, maintain, and keep aligned, and full alignment is hard to hold because the core product keeps advancing.
The host-adapter approach. Treat each surface as a thin entry point into one platform. The client's responsibilities are narrow: translate its host environment into concepts the platform already understands, and render what comes back. The agent logic, retrieval, code execution, citation resolution, and artifact generation are never reimplemented per surface, because none of them live in the surface.
We took the second path, and it's the harder one to adopt retroactively, not for lack of skill but because of how products grow. A product that began as a web app tends to absorb the web app into its own architecture without anyone deciding to. Authentication assumes a single browser session. Tool calls assume they execute server-side from one place. Workflow state assumes one route tree and one viewport. Document context assumes ingestion happens through one upload path.
Once those assumptions set, each new surface becomes a partial rewrite, and shipping a subset becomes the practical default. We wanted full capability on every surface, so we drew the boundary deliberately and early, before the cost of a misplaced one could compound.
What "the full platform" concretely means
When we say the Office add-in or the Chrome extension reaches the entire platform, this is the specific capability set that travels with it:
- The agentic research engine. Long-running, multi-step work rather than a single model call. The engine that fans a question out across hundreds of agents and reasons over tens of thousands of source documents on the web is the engine answering from a taskpane. The surface is small; the compute behind it is not.
- Sandboxed code execution. When a question is best answered by running code (parsing a messy export, recomputing a figure, building a model), it runs in an isolated sandbox regardless of which surface initiated it.
- Document processing across formats. Real PDFs, spreadsheets, decks, scans, and exports are ingested and understood the same way no matter where they entered the system.
- Citations that resolve. Every claim links to its exact source location: a character range in text, a bounding box on a PDF page, a cell range in a workbook. The resolution machinery belongs to the platform, so it behaves identically on every surface.
- Generated work product. Models, tables, memos, and slides return as editable artifacts rather than chat text, wherever the work began.
No surface receives a diminished version of any of these. A surface may insert results differently (Excel can write values into a workbook, the browser cannot), but the work that produced the result is identical. The edges differ by design. The engine does not.
The boundary that makes it hold
The client understands the host. The platform understands the work.
That one sentence is the design rule the whole system rests on.
Each surface earns its place by capturing context the web app cannot naturally see, then handing that context to the platform in a form the platform already speaks. In Office, that's the selected range, the open document, the slide being edited. In the browser, it's the active tab: selected text, the readable content of the page, a screenshot, the URL. On mobile, it's capture, notifications, and starting work away from a desk. On desktop, it's a persistent native workspace with real OS integration rather than another browser tab.
The shape of that hand-off is deliberately simple, and it's identical everywhere: each surface signs the user in, links the work to a Brightwave project, and opens a conversation inside it. Whatever the host captured enters as context on a turn in that chat. From the platform's side, a message from a Microsoft Office taskpane and a message from the web app are the same kind of object, a turn in a project's conversation, which is exactly why every surface reaches the whole platform. None of them talk to a cut-down API; each one opens a chat in a project, like any other client, and the full engine is on the other end of it.
The platform also knows what it's talking to. Each surface identifies its host (which client, which environment, even the machine type), so the system can act accordingly instead of guessing. A turn from the desktop app can reach local files and a sandboxed shell on that machine; a turn from the Office add-in can write results back into the open workbook; a turn from the browser can read the active tab. The surface tells the platform what it is and what it can do, and the platform routes the right capabilities to match. Same conversation, same engine, environment-aware at the edge.
Capture and insertion are genuinely host-specific, and they're the messy part. Office, Chrome, Electron, Apps Script, and mobile each carry their own permission models, packaging requirements, review processes, and runtime constraints. So that is precisely, and only, what the client-side code owns: capture, insertion, local permissions, packaging, the host bridge. Everything past the boundary is the platform's responsibility.
This is why adding a surface doesn't dilute the others, and why the surfaces don't drift apart over time. There is no per-surface copy of the agent logic to fall behind. An improvement to the research engine reaches every surface the same day.
Figure 2. One platform behind every surface. Six host adapters carry thirteen surfaces (nine generally available, four completed and submitted to their stores for publishing). Every adapter opens a chat in a Brightwave project and crosses the host boundary identifying its host and machine; the platform does the work, the same engine at the same scale, for all thirteen.
What one engine buys
The payoff of a shared engine shows up downstream, and it compounds. Because each surface is an adapter rather than a product, an improvement to the core lands everywhere at once: a stronger model, a better retrieval pass, a new tool, a safety fix. It reaches the web app, Microsoft Office, and the inbox on the same day, because there is only one engine to improve. The work that is genuinely hard to build (the agentic loop, the sandbox, citation resolution, evaluation and observability) is built once and inherited by all thirteen surfaces.
Parity stops being something we maintain and becomes a property of the structure. We don't run a treadmill keeping thirteen clients caught up to the web app; they share one platform, so they move together by construction. Adding the next surface doesn't dilute the others or fork the roadmap. It widens where the same product can show up.
That is also why the surface count can keep growing without the core growing to match. A new host means a new adapter (capture, insertion, auth, packaging), while the engine behind it is already built. The marginal cost of the next surface is small precisely because the expensive part is shared, and never rebuilt.
What we'd underline
The boundary determines everything. Where the line falls between "the host" and "the work" decides whether new surfaces are adapters or rewrites. Misplace it and no amount of effort buys parity.
Parity is a property of the architecture, not a project. When every surface reaches one platform, they can't diverge. When each is its own product, keeping them aligned is continuous work.
The interesting engineering is at the edge. Host context capture and result insertion are where the real, surface-specific work lives. Done well, that is all that lives there.
Distribution is engineering. Signing, manifests, store review, OAuth scopes, native packaging: none of it is exotic, all of it is real, and a serious multi-surface product needs release paths as deliberately as it needs runtime code.
The version of Brightwave inside a spreadsheet should not be a lesser Brightwave. It should be the same platform, having shown up where the work already is. That the same engine now runs behind thirteen surfaces, each one getting better the moment the core does, is the clearest measure of whether the architecture was right.
Brightwave runs wherever you work. Download it for Microsoft Office, Chrome, desktop, and mobile → and bring the same engine with you.
¹ At the time of writing, all thirteen surfaces are built. Nine are generally available: Android and iOS (mobile), macOS, Windows, and Linux (desktop), Chrome (browser extension), and Excel, Word, and PowerPoint (Office add-in). Four are complete and submitted to their app stores for publishing: the Outlook add-in and the Google Workspace add-on for Docs, Sheets, and Slides. The web app is the original surface and is not counted among the thirteen.
