The AI-Native Notebook That Thinks Like a Spreadsheet

Ben Lorica

Akshay Agrawal on Reactive Architecture, AI Integration, and Production Workflows.

Subscribe: Apple • Spotify • Overcast • Pocket Casts • AntennaPod • Podcast Addict • Amazon •  RSS.

This episode explores Marimo, a compelling notebook platform that solves critical problems plaguing traditional Jupyter notebooks through reactive architecture and AI-native design. Unlike Jupyter’s problematic hidden state and JSON storage format, Marimo notebooks behave like spreadsheets where cells automatically re-run when dependencies change, while storing everything as clean Python files that integrate seamlessly with Git and production workflows. The discussion with CEO Akshay Agrawal covers how Marimo’s AI integration provides runtime context to LLMs for superior code generation, its adoption across industries from cybersecurity to DevOps, and the technical innovations that make notebooks viable for production environments.

Subscribe to the Gradient Flow Newsletter

Interview highlights – key sections from the video version:

Jump to transcript

Related content:

Support our work by subscribing to our newsletter📩

Transcript

Below is a heavily edited excerpt, in Question & Answer format.

Core Problems and Motivation

What specific pain points with traditional notebooks led to the creation of Marimo?

There were four primary issues with traditional Jupyter notebooks that needed solving. First, the reproducibility problem – Jupyter suffers from “hidden state” where variables on the page can get out of sync with the outputs you see. This makes it difficult to ensure your notebook produces consistent results, which is critical for research and data engineering work.

Second, maintainability is poor because Jupyter notebooks are stored as JSON files rather than Python files. This creates several problems: they produce massive, unreadable diffs in Git when you make small code changes; you can’t import functions from notebooks into other Python code; and you can’t run them as standalone scripts with command-line arguments.

Third, interactivity is limited. While notebooks contain code, visualizations, and UI elements, sharing them typically results in static documents. There was a need to share notebooks as fully interactive web applications.

Fourth, advanced interactions were difficult to implement. For example, selecting points in a scatter plot with your mouse and having that selection propagate back to Python variables for further analysis was extremely challenging in Jupyter’s architecture.

For teams accustomed to IDEs like VS Code, why should they still consider using notebooks?

If you’re building a standard web application, you probably don’t need notebooks. However, for any work involving data – whether it’s building data pipelines, training models, data exploration, or finding outliers – notebooks provide unique value.

The key difference is that data work is fundamentally iterative and conversational. You need to load data into RAM, manipulate it, and immediately see how your changes affect its shape through plots, tables, or other visualizations. It’s like having a live conversation with your algorithms and data. This workflow is difficult to replicate in traditional IDEs. Even for advanced AI engineering tasks like creating evaluation suites for LLMs, notebooks are recommended as a starting point for examining outputs and data in real-time.

Reactive Architecture and Technical Design

What does “reactive” mean in Marimo’s context, and why is it powerful?

Marimo’s reactivity works like a spreadsheet. When you run a cell that declares or modifies variables, all other cells that depend on those variables automatically re-run to reflect the changes. This core feature eliminates Jupyter’s hidden state problem by ensuring your code and outputs are always synchronized.

In traditional Jupyter notebooks with the IPython kernel, you must manually remember which cells to re-run after making changes. This often leads to forgotten cells and notebooks in undefined states. Marimo’s reactive execution removes this cognitive burden and source of errors.

For computationally expensive workflows, Marimo supports “lazy” reactivity. In this mode, instead of automatically re-running expensive cells, Marimo marks dependent cells as stale. You still get state consistency guarantees without incurring immediate computational costs.

Why is storing notebooks as pure Python files revolutionary for notebook workflows?

This fundamental design decision provides several major benefits:

  1. Git-friendly versioning: Small code changes result in small, readable diffs. Unlike JSON notebooks where minor changes can create massive diffs due to serialized outputs in base64, Marimo notebooks behave like any other Python file in version control.
  2. Code reusability: You can import functions directly from Marimo notebooks into other Python scripts or notebooks using standard Python import syntax (e.g., from my_notebook import my_processing_function). This promotes modular, reusable code.
  3. Script execution: Marimo notebooks can run directly from the command line (python my_notebook.py) and accept command-line arguments. This elevates notebooks from mere scratchpads to real software artifacts that can be integrated into production workflows and CI/CD pipelines.
  4. Seamless IDE integration: Because they’re plain Python files, you can edit Marimo notebooks in any text editor or IDE, enabling workflows where you use your preferred development environment alongside the notebook interface.

How does Marimo extend reactivity beyond just notebook cells?

Marimo watches for changes not only in notebook cells but also in external Python modules you import. If you’re editing helper files in VS Code or another IDE, Marimo detects these changes and marks dependent notebook cells as stale or reruns them automatically. This creates a seamless development experience where your notebook stays synchronized with your broader codebase.

AI-Native Features and Integration

What makes Marimo “AI-native” compared to traditional notebooks?

Marimo integrates with popular LLM providers (OpenAI, Anthropic) as well as local models through Ollama for code generation in Python and SQL. However, the key differentiator is access to runtime context.

In traditional IDEs, AI assistants only see static code. In Marimo, LLMs can access live variables in RAM. For example, when writing complex Pandas or SQL queries, you can tag relevant DataFrame variables (e.g., using @df). Marimo inspects these live objects, extracts their schemas, column names, data types, and even sample data, then passes this rich runtime information to the LLM. This results in highly accurate, context-aware code generation that reflects your actual data structures rather than generic suggestions.

How does Marimo facilitate “vibe coding” and agentic AI workflows?

Because Marimo notebooks are plain Python files with idiomatic Python code, they work seamlessly with external AI agents. A common workflow involves using Claude or similar agents to write entire Marimo notebooks. With Marimo running in “watch mode,” changes made by the AI agent to the underlying .py file appear in real-time in your browser – cells are added, removed, or updated automatically.

The agent can even execute the notebook as a script to check for errors and self-correct, creating a powerful iterative development loop. This capability has made Marimo popular for rapid prototyping and exploratory development with AI assistance.

What about multimodal workflows and handling diverse data types?

Marimo is largely agnostic to data types and provides hooks for building multimodal applications. For instance, you can create workflows that watch for changes to image files and automatically trigger processing pipelines.

One demonstration shows a dynamic image input element (similar to MS Paint) where users can draw. As they draw, the image data streams to models like Gemini, which generates live JSON representations of the drawn content. You can integrate any model – Whisper for audio, vision models for images – and because Marimo supports custom JavaScript visualizations via the anywidget standard, you can build rich interfaces for any data type.

Performance and Scalability

How does Marimo handle large-scale data or compute-intensive tasks?

Marimo provides several mechanisms for working with large datasets and expensive computations:

  1. Lazy evaluation: As mentioned, you can set the runtime to lazy mode to avoid automatically re-running expensive computations while maintaining state consistency.
  2. Intelligent caching: Marimo is building Nix-inspired caching systems that give users granular control over when and how cells are re-executed.
  3. Native performance: While Marimo itself is Python, most high-performance data libraries (NumPy, PyTorch, Polars, Ray) have C++ or Rust backends. As long as you use their vectorized APIs rather than tight Python loops, performance matches any native framework.
  4. Distributed computing support: Marimo works seamlessly with distributed computing frameworks like Ray, allowing you to scale your workflows across clusters.

Can Marimo run entirely in the browser?

Yes, Marimo supports WebAssembly-based execution, making it suitable for embedding in courses, documentation, and demos. This capability is already being used in Hugging Face courses and Cloudflare’s public notebooks, enabling interactive learning experiences without server infrastructure.

Adoption and Use Cases

Who is using Marimo today, and what surprising use cases have emerged?

Adoption spans industries and company sizes, including Cloudflare, BlackRock, and Shopify. Beyond expected machine learning and data science use cases, two surprising areas of adoption stand out:

  1. Cybersecurity: Security teams use Marimo for incident response and threat hunting. The ability to iteratively query data, visualize results, and create interactive investigative tools makes it ideal for forensic analysis.
  2. DevOps and SRE: Engineers build interactive runbooks and infrastructure management tools. One user created a dashboard to manage EKS clusters, visualizing running instances and taking actions directly from the notebook’s UI.

These use cases leverage Marimo’s built-in interactive UI elements (sliders, dropdowns, tables) tied to the reactive graph. UI interactions trigger only necessary downstream cells, creating performant tools that would be cumbersome to build in traditional notebooks.

Are Marimo notebooks used in production environments?

Yes, enterprises use them to power internal dashboards, schedule batch jobs, and build production pipelines. Because Marimo notebooks are DAGs (Directed Acyclic Graphs) under the hood, they support production features like retries, caching, checkpointing, and integration with orchestrators. This positions them as viable alternatives to traditional pipeline tools for certain use cases.

Integration and Ecosystem

How does Marimo integrate with existing data and AI tools?

Out of the box, Marimo supports:

  • Popular data libraries (Pandas, Polars, matplotlib, seaborn, Ray)
  • SQL engines (DuckDB, PostgreSQL, and other databases)
  • Vector databases (Chroma, LanceDB)
  • Secrets management for secure data warehouse connections
  • Machine learning frameworks (PyTorch, TensorFlow, scikit-learn)

Marimo appears in the official documentation of tools like Mother Duck, Polars, and UV. The team is actively working on deeper VS Code integration to provide a more native experience for developers who prefer to work primarily in their IDE.

Business Model and Future Direction

What distinguishes the free open-source version from the paid enterprise offering?

The Marimo notebook will always be free and open-source under the Apache 2.0 license. The paid enterprise version addresses deployment at scale with features like:

  • Multi-user support with role-based access control
  • Audit logs and compliance features
  • Seamless integration with enterprise data lakes and compute engines
  • Authentication and security features
  • Centralized management and governance

These are enterprise-specific requirements that don’t make sense to implement in the open-source project but are critical for large organizations.

What’s on the roadmap for Marimo?

Near-term priorities include:

  1. Enhanced AI capabilities: Moving beyond one-shot code generation to full agentic coding with multi-step execution plans directly in the editor.
  2. Advanced caching: Expanding the Nix-inspired caching system for more granular control over cell execution and better performance optimization.
  3. Data pipeline features: Productizing the inherent DAG structure of Marimo notebooks for building robust data pipelines with features like intermediate output snapshotting, failure handling, and retry logic.
  4. Moab platform: Recently launched moab.marimo.io as a Google Colab competitor for sharing machine learning and AI demos in the cloud.
  5. Deeper IDE integration: Particularly with VS Code, to provide a more seamless experience for developers who prefer traditional development environments.

Will Marimo support languages beyond Python and SQL?

No plans exist to support additional languages. While there’s some R usage in bio/pharma sectors, Marimo is focused entirely on Python and SQL as the lingua franca for data and AI work. The deep integration with Python’s runtime and ecosystem makes supporting other languages impractical, and the team prefers to provide the best possible experience for Python users rather than diluting efforts across multiple languages.