AI Authoring

Use AI to create, edit, explain, debug, and complete normal notebook Python while understanding context, privacy, and review boundaries.

Boardflare AI authoring helps write normal notebook Python. The generated source remains visible and editable, so use the assistant to accelerate implementation while keeping the calculation deterministic, inspectable, and testable.

Boardflare exposes marimo’s notebook AI authoring experience with Boardflare-managed provider and gateway policy. AI is an authoring aid: the durable result remains normal notebook source that can be reviewed, run, tested, and saved with the workbook.

The deployed AI endpoint does not receive notebook execution tools and cannot directly mutate the live Python runtime.

Who can use Notebook AI

Notebook AI is currently available when the Excel add-in resolves an eligible work or school Microsoft identity. Personal Microsoft accounts and sessions without a resolved eligible Office identity do not expose the Marimo AI controls.

Boardflare supplies the model/provider configuration. You do not need to enter an AI provider API key in the notebook.

This eligibility check is separate from notebook calculation. A workbook can still run bf.inputs(), bf.publish(), BF.OUTPUT(), and BF.FUNCTION() while Office sign-in is unresolved or when Notebook AI is unavailable.

For the Office SSO bearer-token path and the current server-side tenant-validation scope, see Security and Data Flow.

What to use AI for

Use notebook AI to accelerate authoring work such as:

  • creating a first draft of one or more cells;
  • revising selected code;
  • explaining a traceback or unfamiliar library call;
  • refactoring notebook structure without changing a stated business rule;
  • completing a small section of code.

Treat the generated result as normal source code. Review the inputs, assumptions, package imports, network access, and calculations before relying on it. For consequential analysis, validate outputs independently rather than treating the model’s prose as the calculation.

Current AI actions

The current notebook integration supports the marimo AI request patterns used for:

Action What the model receives Expected result
Chat Conversation plus selected/supplied notebook context Explanation, debugging help, or code suggestions
Create cell(s) Prompt plus relevant notebook code/context One or more Python, SQL, or Markdown cells
Edit selected code Surrounding code plus the marked section to rewrite Replacement code for that section
Inline completion Code prefix/suffix Missing code only

For code-generation/edit requests, Boardflare’s system prompt includes both marimo reactive-programming rules and the complete public Boardflare notebook API guide.

Boardflare API awareness

Generated workbook-integration code should use only:

  • import boardflare as bf
  • bf.ref(...)
  • bf.inputs(...)
  • mapping reads such as inputs["sales"]
  • bf.publish(outputs=..., functions=...)
  • worksheet consumers BF.OUTPUT(...) and BF.FUNCTION(...)

The prompt explicitly tells the model not to invent notebook globals, private runtime APIs, decorators, workbook bridge objects, or alternative function-discovery mechanisms.

A useful creation prompt is:

Read Project Inputs!A4:H13 and Project Inputs!J4:K6 with bf.inputs(). Validate required columns, build a deterministic allocation model, publish a summary and selected-project table, and expose a short risk_adjusted_value function for worksheet calls. Keep the bf.inputs() and bf.publish() widgets displayed.

For debugging/refactoring:

Refactor this notebook so workbook inputs are declared once upstream, validation happens before the model runs, and there is one downstream bf.publish() registry. Do not change the business rules. Explain any assumption you cannot verify from the code.

Marimo reactivity matters

The assistant is instructed to write for marimo rather than a conventional execution-order notebook. Generated code should:

  • prefer dependency-driven reactive data flow;
  • avoid redefining a variable already owned by another cell;
  • avoid hidden global mutation when normal cell dependencies work;
  • use clear shared variable names;
  • separate distinct logic into logical cells;
  • preserve the displayed Boardflare input/publication widgets.

Review generated code for those properties. Syntactically valid Python can still be a poor reactive notebook design.

Context that may be sent

AI authoring is a separate data path from normal workbook → browser Python calculation.

Depending on the marimo action and the context the author chooses, a request may include:

  • the user’s prompt;
  • notebook source or code from other cells;
  • selected code;
  • cell outputs;
  • variable names/previews;
  • schema/context information;
  • @ context;
  • image attachments;
  • contextual material that may itself have been derived from workbook data.

Treat that as a data-export boundary. Workbook-derived information can leave the local notebook execution path when the author includes it in AI context.

The endpoint’s context-safety instructions tell the model to treat notebook/context content as user-provided data rather than as higher-priority instructions.

Current request bounds

The shipping endpoint currently enforces:

  • maximum request body: 2 MiB;
  • supplementary notebook/context budget: 256 KiB characters before truncation;
  • normal generation token default: 4,096 unless the deployment overrides it;
  • inline completion token cap: 1,024.

Large notebooks or attachments can therefore be truncated or rejected even though the notebook itself still runs normally.

Provider path

Boardflare’s endpoint sends requests through the deployment’s configured AI gateway/provider credentials. The concrete upstream model can change independently of the public workbook API, so this documentation intentionally does not promise one model name.

Do not put provider secrets in notebook code. The model-access credentials belong to the Boardflare AI service configuration, not the workbook.

What the assistant cannot do

The current deployment provides text/code assistance only. It does not give the model tools to:

  • execute a notebook cell;
  • inspect live Python objects unless their information is explicitly supplied as context;
  • read arbitrary workbook cells directly;
  • modify runtime state directly;
  • verify that a generated calculation is correct;
  • call arbitrary external tools on the author’s behalf.

If the assistant says it ran code or inspected live state without that information being supplied, treat that statement as incorrect.

Review generated code as code

For consequential work, require the same controls you would use for manually written software:

  1. define the business rule explicitly;
  2. test representative and boundary inputs;
  3. reconcile totals before and after transformations;
  4. inspect file/network side effects;
  5. add assertions for important invariants;
  6. keep generated source reviewable and use version control when your source workflow supports it;
  7. validate the second-user App-mode path when Open as: App is part of the workbook experience.

The practitioner evidence reviewed for Boardflare’s 2026 research shows the same pattern: AI is most useful when it helps create a deterministic, inspectable tool rather than when a user delegates the final business conclusion to an opaque model. See How AI Is Changing Python Development in Excel for the research synthesis.