Building the future of collaborative AI development with Akshay Agrawal of Marimo
Summary
Marimo’s core bet is that notebooks can span the entire data workflow instead of remaining disposable scratchpads. The open-source Python environment combines interactive exploration with pure-Python files that run as scripts or deploy as web apps—Agrawal’s attempt to “blend the best parts of interactive computing” with software-engineering rigor. That expanded workflow surface, from first query through data app, is also the company’s monetization thesis.
Reproducibility is enforced through architecture, not user discipline. Marimo statically builds a dependency DAG across cells and reruns every affected cell, including cells appearing earlier on the page, so “the code on the page matches the outputs you see.” The need is concrete: a JetBrains study examined 10 million Jupyter notebooks from GitHub and found that over one-third did not reproduce their serialized results when rerun top to bottom.
The unexpectedly powerful adoption wedge is Git compatibility. Marimo stores notebooks as pure Python and guarantees that small code changes produce small diffs, rather than burying code and outputs in a large JSON blob. Agrawal expected reactive execution or interactive dataframes to attract users, yet repeatedly heard that “it’s the Git friendliness”—including from software engineers who had previously avoided notebooks.
Marimo collapses the notebook-to-app handoff that Streamlit leaves intact. Streamlit typically arrives after exploration, often as a direct port of a Jupyter notebook, whereas every Marimo notebook can become an app without translation and reruns only cells dependent on an interaction. Anthony Goldbloom told Biewald that deployment fell from roughly six hours to five minutes because the notebook no longer had to be rewritten.
A two-person team has built a surprisingly broad platform, but the roadmap widens the execution burden. Following two years of funding and feedback from SLAC National Accelerator Laboratory, Agrawal and co-founder Miles announced a seed round and plan to hire. Priorities include deeper SQL and database connectivity, remote execution for expensive cells, a browser-only community cloud powered by Pyodide and WebAssembly, static interactive documentation, and more Cursor-like AI assistance.
Product discipline matters because relaxing Marimo’s constraints would break its downstream value. Users asked for a toggle that would temporarily disable the DAG and restore Jupyter-style freedom, but the founders refused: notebooks created in that mode might cease to be reproducible, executable scripts, or deployable apps. “We cannot let you turn off the DAG” is both a UX tradeoff and a statement of the moat Marimo is trying to build.
Deep dive
1. Marimo makes notebook state explicit and reproducible
Agrawal defines a notebook as an interactive computing environment: blocks of Python expose plots, tensors, training runs, and database results alongside Markdown. That ability to “see your data while you work on it” makes notebooks central across science, model training, Google Colab, Databricks, and AWS SageMaker.
The failure mode is hidden execution history. A JetBrains study downloaded 10 million Jupyter notebooks from GitHub and found that over one-third produced results different from their stored outputs when rerun top to bottom; a separate 2019 paper found similar results. Agrawal encountered the same problem during his Stanford PhD: “I can’t reproduce your science.”
Marimo’s guarantee is simple: “The code on the page matches the outputs you see.” It statically parses variable definitions and references, constructs a DAG, and updates every dependent cell regardless of its visual position—more like a spreadsheet than a dressed-up Python REPL.
Biewald’s immediate pushback: what about circular dependencies? Agrawal says they are prohibited and detected, with Marimo identifying the affected cells and suggesting fixes. Marimo also has built-in package management, which Agrawal says can make notebook files a self-contained, reproducible unit.
2. Pluto and Streamlit supplied the two halves of the product
Agrawal’s origin story was a broad tooling survey after work at Google Brain on TensorFlow and a PhD in machine learning and optimization, much of it involving open-source tooling. He concluded that he preferred building “developer tools that let other people solve problems instead of solving the problems myself.”
Pluto.jl provided reactive execution, seamless UI controls, and built-in package management; its adoption convinced Agrawal that Python needed an equivalent. Streamlit supplied the second insight: notebook-like artifacts could become web apps. Marimo merges those ideas so exploration, reusable tooling, and deployment remain in one file.
Although Biewald raised reports that Netflix ran production work on notebooks, Agrawal said he used “probably zero notebooks” during his internship because he worked on the algorithms-engineering side, and that Netflix did not inform his thinking much. He instead observed that “people love notebooks but they also kind of hate them,” particularly because of hidden state and JSON storage.
3. Git friendliness became the surprise distribution engine
Early adoption came largely from Hacker News; Agrawal says Marimo’s Show HN post became the second-top Python Show HN post when ranked that way. More recent distribution adds a Hugging Face integration for deploying notebooks to Spaces and a WebAssembly playground where users can create and share unlimited notebooks by link.
Agrawal expected reproducibility, reactive execution, or richer data interaction to be the hook. Instead, users repeatedly cited pure-Python storage and readable diffs. Even after a presentation emphasizing SQL and analytics features, a business-analytics professor’s conclusion was: “I’m going to use this because it’s Git friendly.”
Marimo does not store outputs in the notebook by default, though users can snapshot them into adjacent files. That preserves a browsable result while keeping code changes legible and allowing those HTML files to be excluded from version control.
The use cases now stretch beyond data scientists. Users explore data, train models, build recurring analytics “mini apps,” and even build dashboards for an EKS cluster. Biewald was surprised because the first interaction still resembles a conventional notebook; Agrawal thinks Git and pure Python make the format credible to engineers who previously avoided notebooks.
4. One artifact now covers apps, SQL, AI assistance, and remote compute
Streamlit reruns an entire script when a slider changes; Marimo executes only dependent cells in its DAG. That preserves fast experimentation while letting a command-line invocation hide code and expose the same notebook as an app. In Goldbloom’s reported workflow, eliminating the notebook-to-Streamlit port cut deployment from six hours to five minutes.
Automatic execution can be concerning for GPU training or an OpenAI endpoint, Agrawal says, because users worry about accidentally triggering those computations. Marimo therefore offers a lazy runtime: downstream cells are marked stale with a visual cue but wait for an explicit command to update. The reactive model remains intact without unexpectedly triggering expensive computation.
Built-in AI support includes GitHub Copilot, Codeium, and bring-your-own-key generation informed by notebook context plus dataframe or attached DuckDB schemas. Refactoring currently works at the cell level; Agrawal says broader conversational, Cursor-like editing belongs on the roadmap.
Marimo also constructs one dataflow graph across Python and embedded SQL, allowing SQL to query dataframes and return dataframes through DuckDB. Planned extensions include easier Postgres and database connections, richer column previews, and hybrid execution that ships only expensive cells to remote servers.
5. The business depends on preserving the DAG’s constraints
Agrawal’s monetization argument starts with workflow position. Streamlit entered near the end, when a small fraction of projects became apps; Marimo begins with the first query or model-training step and can continue through deployment. Since notebooks already mediate compute in commercial platforms, he believes Marimo exposes “a much larger” monetizable surface.
The company began with enough funding from SLAC National Accelerator Laboratory for Agrawal and Miles to work for two years. A scientist familiar with Jupyter’s problems responded to the prototype pitch with, “We’ll pay you to do it,” and supplied early feedback before open sourcing. The two-person company announced a seed round during the week of the interview.
The hardest product choice was preserving reproducibility despite user resistance. Marimo forbids cycles and duplicate global variable definitions across cells; requests for a Jupyter-style “dangerous mode” were rejected because notebooks authored there might fail as apps or scripts. “We cannot let you turn off the DAG.”
Agrawal’s escape hatches retain the contract: wrap exploratory code in functions to create local namespaces, or prefix a variable with an underscore to make it cell-local and reusable elsewhere. The friction is intentional—the same restrictions that complicate scratch work enable every downstream promise.