Observable puts AI-assisted analysis inside an inspectable notebook

Observable is a platform for creating interactive documents that combine data, code, charts and explanations. Its agent can help build and revise those documents while inspecting the same runtime values available to the author. The company launched a substantial notebook rewrite in September 2026. That current product is best understood as a flexible medium for analytical work, with some team and editor capabilities still developing.

01 / ProductA computational document that can explain itself

The current product page¹ presents notebooks as lightweight documents for analysis, visualization, explanations and custom applications. A notebook contains cells of prose or code, and the output can appear near the logic that creates it. That makes it possible to show both a chart and the calculation behind it in the same artifact.

The Notebooks 2.0 upgrade guide⁵ describes a move toward standard JavaScript and TypeScript, rather than relying only on the earlier Observable JavaScript syntax. The newer standard library also changes module imports and some Markdown and HTML behavior. Existing notebooks may need targeted review when adopting the new runtime and library.

Observable Chat offers a conversational starting point. The chat guide⁴ explains that messages and code responses are notebook cells underneath. A user can fork a chat into a notebook, then edit and condense the work into a clearer document. That transition is useful because an exploratory conversation rarely has the best structure for the final reader.

02 / AudienceWho benefits from this approach

Observable is particularly relevant to analysts, visualization developers, researchers and technically comfortable communicators. It suits questions where a fixed image is too restrictive: a reader may need to change a threshold, select a region or inspect the records behind a point. The author can design that interaction directly with web code and visualization libraries.

It also suits collaboration between a domain expert and someone who can inspect the implementation. The expert can describe the analytical question while the notebook exposes the calculations and assumptions. AI assistance lowers the effort of drafting code, but a person still needs to judge whether the calculation answers the intended question.

The Hex blueprint is a useful comparison for collaborative analysis and data applications. The ThoughtSpot blueprint is more relevant when the main need is broad access to governed business analytics. Observable’s flexibility is most valuable when a bespoke interaction or explanation improves understanding enough to justify maintaining it.

03 / WorkflowA proposed workflow for explaining delivery reliability

Imagine an operations team investigating why delivery reliability differs across regions. This is a proposed workflow, not an analysis performed for this article. Define the outcome first: arrival before the promised deadline, with canceled and rescheduled deliveries handled explicitly. Preserve both the original promise and any later revision so the analysis does not quietly reward changed commitments.

Load a reviewed dataset through a file attachment or a supported connection. Begin with a small table showing row count, date coverage, missing timestamps and duplicate delivery identifiers. Put those checks near the top of the notebook. A chart of regional performance should not appear before the reader understands which deliveries are included.

Ask the agent to draft a calculation that groups deliveries by region and reporting period. Inspect the code and intermediate values. Confirm how it handles time zones, missing arrival times and repeated delivery attempts. Keep the definition in a Markdown cell beside the code so a future editor can see why the calculation differs from a simple count of completed records.

Create an interactive view with a date range and minimum sample-size control. Let readers select a region and inspect the underlying late deliveries. The chat guide describes the agent’s ability to see dynamic values exposed by inputs or chart selections when the user sends the next message. That can support a focused follow-up about the selected records rather than a vague request to explain the whole chart.

Separate descriptive findings from explanations that need additional evidence. A region with a higher late-delivery share may have a different route mix or a small sample. Add a comparison by distance band or delivery type if those fields are reliable. Show counts alongside percentages so a dramatic-looking rate based on three deliveries is not mistaken for a stable pattern.

Fork the exploratory chat into a notebook and edit the final reading order. Remove abandoned calculations, label the source date and keep the relevant checks. The notebook guide³ documents exporting cell output as PNG or SVG, which is useful for a slide or report. Preserve the interactive notebook as the fuller explanation when the audience needs to inspect assumptions.

04 / PricingPricing and availability need to be read together

The page describes agent allowances qualitatively as fewer or more daily tokens rather than promising an unlimited service. Pro also lists 50 compute minutes monthly and an attachment allowance. A plan choice should follow the intended mix of authoring, agent use and hosted computation, with the current limits checked in the account.

Do not treat every feature pictured on the homepage as fully available in the new editor. The notebook guide identifies capabilities being rebuilt, and the current pricing page explicitly labels Team as forthcoming. For an organizational rollout, verify the exact workspace, access and history features needed by the team before migrating a collection of internal notebooks.

For the delivery explanation, the main early cost is authoring and review rather than a large seat deployment. One complete notebook can establish whether interactive exploration improves the conversation. If many people only need a static chart, exporting that chart may be the appropriate distribution method while the maintained notebook remains with its authors.

05 / DistinctionsWhat stands out in the analytical experience

Observable keeps executable logic close to its explanation. That is useful when a reader asks why a chart excludes a certain record or how a threshold changes the result. The answer can be demonstrated with a visible calculation and an input, rather than supplied as an unsupported paragraph in a slide deck.

The agent’s runtime access is also distinctive. It can inspect values and selections in the notebook, which gives it more concrete context than a screenshot alone. The author should use that access to ask bounded questions about specific calculations. A request to inspect an unexpected group count is easier to verify than a request for a broad explanation of business performance.

The move toward standard web languages improves the relationship between notebook work and ordinary software tools. The upgrade guide describes standard module imports and explicit display behavior. It also identifies compatibility differences, so portability should be approached as a maintained code transition rather than an assumption that every old cell can be copied unchanged.

06 / QuestionsQuestions to resolve before publishing an explanation

Who can see the notebook and its data? The notebook guide distinguishes private, unlisted and public access. Unlisted means anyone with the URL can view it; it is not an access-controlled internal document. Review attached data, source queries and visible intermediate results before choosing an audience.

What depends on an active browser session? The chat guide says client-side agent code runs while the tab is active. That is different from an unattended scheduled data pipeline. If the notebook needs fresh operational data every morning, define a separate supported refresh arrangement rather than relying on an exploratory browser session remaining open.

How will changes be reviewed during the product transition? The current guides describe a recent rewrite with evolving editor capabilities. Preserve the accepted notebook and data revision using the available export or versioning route, and verify the specific history controls before depending on them. An attractive interactive result still needs a clear record of what data and logic produced it.

07 / DecisionChoose Observable when interaction improves understanding

Observable is a strong choice for a question that deserves an inspectable, explorable explanation. Begin with one decision or disagreement, then build the smallest notebook that makes its evidence clear. Use the agent to accelerate code drafting and investigation while keeping calculations and assumptions visible.

For delivery reliability, the useful result is a document that lets readers see the reporting definition, inspect the records and understand how the conclusion changes with scope. If those interactions improve the operational discussion, expand the approach. If the audience only needs one settled number, a simpler report may be easier to maintain.