Google’s November 10 Workbench release notes introduce Antigravity CLI in preview for notebook work. The catch arrives in the usage documentation: its edits go straight to the notebook file on disk, beyond the editor’s Undo history. For a research team, that makes the handoff between file, editor, and execution state part of accepting an agent’s work.
This article was generated with AI assistance from the linked public sources. Keith has not personally reviewed this automated edition; the workflow examples below are proposed engineering exercises.
The useful question comes before the next impressive chart: which saved experiment actually produced it?
Three versions of the same experiment
Google’s Antigravity CLI guide explicitly warns that editor Undo, Control+Z, and Command+Z cannot reverse the agent’s direct file changes. It also tells users to save unsaved notebook changes before asking the agent to edit a notebook already open in JupyterLab. The guide offers a natural-language request to undo the last change.
That is useful recovery help. For a reproducible experiment, I would also want a saved baseline and an inspectable difference. A request to reverse a change does not, by itself, establish which version later generated an output.
A notebook has several relevant states. There is the document saved on disk. There may be an open editor containing newer, unsaved text. There is also a running kernel containing objects created by earlier executions.
Jupyter’s documentation describes the separation: executing a code cell sends its code to the associated kernel, while notebook documents store inputs and outputs. An active kernel can even survive closing the browser window. Editing the saved source and executing that source are different events.
An agent can make the right textual change while the next calculation still uses an old object in memory.
A deliberately boring failure
Here is a synthetic exercise a team could run before using an agent on important notebooks. It is an illustration, not a reported Antigravity defect or a test of Google’s product.
Put a multiplier in an early cell: scale = 1. In a later cell, multiply the fixed number 20 by that variable. Execute both cells. The result is 20.
Now change the early cell to scale = 10, save the notebook, and execute only the later cell. With the earlier assignment still active in the kernel, the result remains 20. A clean execution of both cells would produce 200.
Both outputs can look perfectly reasonable in isolation. The misleading part is their relationship to the source somebody is reading.
An assistant writing a changed notebook file creates another place where that relationship needs attention. The failure does not require a wrong formula, invented data, or a malicious instruction. It can start with a correct edit and an incomplete rerun.
Why this matters for a research platform
The public Traid case study describes a forecasting research platform with persistence, replay, and evaluation around its model workflow. Its stated status remains a research platform with paper qualification ongoing.
That makes it a useful context for this question: a result needs enough surrounding record to be evaluated later. A stored number without a reliable connection to the code and inputs that produced it is hard to investigate.
The case study does not establish that Traid uses Workbench, Jupyter, or Antigravity. A notebook companion to that kind of research platform is the proposed design here.
For that companion, I would separate exploratory runs from results accepted into an evaluation record. Exploration should stay quick. Accepted results should name a saved notebook revision, an input snapshot, the relevant environment, and an execution record.
Those references do not establish that a model is useful. They establish what ran, which is necessary when somebody else tries to reproduce or challenge the result.
Make the handoff explicit
Before an agent edits, save the document and preserve a recoverable baseline. Give it a narrow task, such as changing one transformation while leaving the input snapshot fixed. Afterward, inspect the saved difference and reconcile the open editor with the file that will be executed.
Then execute the accepted source from a fresh kernel in the intended environment. Save the resulting notebook and attach the run’s identifiers to any exported table or report.
For an expensive experiment, a complete rerun after every conversational edit may waste hours. Keep cheap synthetic examples for development and reserve the clean execution for the point where a result becomes a shared claim. If randomness is involved, record its configuration and define an appropriate tolerance; fresh execution does not guarantee bit-for-bit equality.
There is a practical consequence for consulting and internal analytics teams. A colleague receiving a chart should be able to find the experiment behind it without inheriting the author’s live session or guessing which cells were rerun.
Google’s preview makes notebook editing more accessible to an agent. The acceptance step still belongs in the workflow: preserve the source, execute the saved revision, and keep the evidence beside the result.
Top comments (0)