work

Livedocs (YC W22) 2021 – 2026 · San Francisco, USA

Livedocs was a collaborative notebook for working with data and code. I was one of the founding members and the CTO. Over four years, we rebuilt the product twice. It started as a no-code data tool, became a reactive notebook, and then an agentic workspace.

Rather than list every single thing I worked on, here are a few of the more interesting problems and choices.

Fixing notebooks

An off-the-shelf IPython notebook is mostly a JSON object containing Markdown and Python blocks. It tells you nothing about the relationship between the cells, leading to a whole host of issues with running cells in the wrong order, stale data, etc. I wrote about this problem in Notebooks Are Lying to You.

We fixed it by representing the notebook as a DAG. For Python cells, we walked the AST to work out which names each cell produced and which ones it consumed. That gave us the edges in the graph. We could now tell what was stale, what had to run next, and which downstream cells needed to be rerun after a change.

SQL cells, charts, tables, and dynamic inputs all compiled down to Python, so they could use the same execution model instead of each having their own system. The DAG and runtime were written in Rust because this logic ran constantly and sat in the hot path between the browser and the Python kernel. The notebook was multiplayer too, and it had a music player for some reason?

Running code from strangers

Everything executed in a notebook had to be treated as untrusted. It could be written by a random human or, increasingly, by our own agent. The runtime also had access to customer data and credentials, so isolation had to be the default.

We tried several ways of doing this, including running Python in the browser, Cloud Functions, and Firecracker microVMs. We eventually built our own orchestrator on top of Kubernetes. Each notebook received an isolated container with its own Python kernel, filesystem, network rules, and resource limits.

Kubernetes pods were too slow to create when someone opened a notebook, so the orchestrator kept a pool of ready-to-go runtimes. It could allocate one to a new notebook in under a second. I wrote about the different versions of this system in Running Code from Strangers.

Building an agent for data work

Text-to-SQL ended up not being the bottleneck because models became great at generating accurate code. The real problem was presenting the right context. In real data work, the useful context could be in a random Excel file, a production ClickHouse instance, a notebook from six months ago, or the output of a cell that ran ten seconds ago. Dumping all of it into the prompt led to context rot, it made the model worse, and the context became stale as the notebook changed.

We started with a simple chat interface in the sidebar. As models became more capable, we stopped trying to put everything in the prompt and gave the model tools to inspect the notebook, query data sources, read files, use the terminal, and decide what it needed.

We split context into caches inspired by how CPUs have a hierarchy of multiple cache levels. The active conversation and notebook state stayed close to the agent. Older outputs, files, and conversations were stored separately and retrieved when needed. We also had compaction at various points, with a memory layer so important stuff could be remembered across workflows that repeated over time.

Subagents came from the same problem. An exploratory query or schema search did not need to dump its entire trace into the main agent's context. Each subagent got its own kernel, DAG, context window, and token budget. It could run experiments in isolation and return only the result the parent needed. This kept the main thread from filling up with intermediate work and also let independent tasks run in parallel.

Underneath, the Python agent service talked to the main Rust runtime over bidirectional gRPC. Model output, tool calls, and subagent progress were streamed through the same event system and back to the browser.

Dune Labs 2018 – 2021 · All over the place

Dune Labs was an engineering consultancy I started in high school. I found clients and took products from idea to launch for companies in finance, insurance, and startups. It made $40K+ in revenue, and I hired a few early-career engineers to work with me.

IdeaBoard 2016 – 2017 · Fujairah, UAE