All posts
EngineeringFebruary 13, 20261 min read

Tensor: from idea to extension in six weeks

A short postmortem of how we built the first Tensor alpha, what broke, and what we cut.

By Yiming Beckmann

Tensor, our browser agent, went from whiteboard to private alpha in six weeks. Here is what we kept, what we cut, and what broke.

The stack

We built it as a Chrome extension (MV3) with a local companion daemon. The extension observes the DOM and forwards sanitized events; the daemon runs the 4B base model and coordinates actions. The extension renders a persistent side panel with receipts and a text/voice input.

We spent roughly one week on the extension scaffolding, two on the DOM observer and action layer, two on the model ↔ extension protocol, and one on the side panel.

What we cut

Three things we shipped in the first design doc and cut before alpha:

- A "canvas mode" that overlaid Tensor on the page directly. It broke site styling constantly and confused users about whose UI they were looking at.

- A history timeline. Users asked for it, but when we shipped it, nobody opened it. Receipts in-session plus the Orb for long-term recall covered 100% of actual use.

- A form-discovery pass that tried to detect filled-out forms elsewhere and copy values. It leaked identifiers across sites. Cut.

What broke

The DOM observer was the hardest part. Modern web apps virtualize everything, and "the DOM as of now" is a lie about 40% of the time. We built a shadow reconciler that watches MutationObserver plus IntersectionObserver plus network activity, and only declares a state "settled" when all three quiet down. Latency went from ~200ms (wrong) to ~600ms (right). Users never noticed the extra 400ms.

What we learned

The extension platform is both stronger and weaker than we expected. MV3 gave us a cleaner security model than we feared. But the DOM as an API is more of a fiction than we had respected.

If you are building a browser agent, budget more time for observation than action.