Conversational Office: How AI Reconstructs Spreadsheets, Whiteboards, and Data Analysis

1. A Shift in Interaction Paradigm: From UI Operations to Describing Intent

For more than a decade, the core interaction model of office software has been “open the application and operate manually.” Users enter formulas cell by cell in a grid, drag shapes on a canvas, and repeatedly configure dimensions and metrics in reporting tools. The main cost of this model lies in the operation path, not in the thinking itself.

Large language models replace the entry point with natural language. Users describe a goal, such as “calculate monthly sales by region and highlight regions with obvious month-over-month declines,” and the system converts that description into table structures, calculation formulas, and charts. This shift raises two technical questions. First, how can natural language be reliably mapped to executable structured operations? Second, how can generated results be validated, edited, and collaboratively authored? The following sections focus on these two questions.

2. Technical Breakdown of Three Capability Areas

2.1 Conversational Generation of Structured Spreadsheets

A spreadsheet is essentially typed two-dimensional data plus calculation relationships between columns. If a model directly outputs free-form text, it is difficult for a program to parse and execute reliably. A more robust approach is to have the model output a constrained intermediate representation, such as column definitions, data sources, and a formula list, which the program validates before applying.

Below is an illustrative intermediate representation. The field names and formula syntax are examples, not a standard format:

{
  "sheet": "monthly_sales",
  "columns": [
    {"name": "region", "type": "string"},
    {"name": "month", "type": "date"},
    {"name": "amount", "type": "number"},
    {"name": "mom_change", "type": "number",
     "formula": "(amount - prev_amount) / prev_amount"}
  ],
  "chart": {"type": "line", "x": "month", "y": "amount", "group_by": "region"}
}

Before execution, the program needs to check three things: whether column types are valid, whether columns referenced by formulas exist, and whether there are circular references. It should also set upper limits on the number of rows and columns to prevent generated structures from consuming excessive resources.

2.2 Conversational Generation of Whiteboards and Flowcharts

Whiteboard content can be abstracted as a graph structure, including nodes, edges, groups, and style attributes. The model is responsible for determining the logical relationships between nodes, while layout is handled by deterministic algorithms, such as hierarchical layout or force-directed layout. Letting the model output coordinates directly is usually unstable; the same requirement may produce very different layouts across multiple generations.

{
  "nodes": [
    {"id": "req", "label": "Requirements review"},
    {"id": "design", "label": "Solution design"},
    {"id": "review", "label": "Technical review"}
  ],
  "edges": [
    {"from": "req", "to": "design"},
    {"from": "design", "to": "review"}
  ],
  "layout": "hierarchical"
}

Multi-user real-time editing requires handling concurrency conflicts. Common industry approaches are based on operation merging, such as OT (Operational Transformation) or CRDT (Conflict-free Replicated Data Type). The choice depends on data structure complexity, network latency, and offline editing requirements.

2.3 Natural-Language-Driven Data Analysis

Natural language to query statement is the highest-risk part of this capability area. If a model reads raw table schemas directly to generate queries, it is easy to confuse field meanings and misuse filter conditions. A more robust approach is to build a semantic layer above the database that uniformly defines metric names, calculation definitions, available dimensions, and default filters. The model only selects and combines metrics on the semantic layer, and a generator ultimately outputs a controlled query statement.

Suppose a user asks, “order amount in East China last month.” The semantic layer maps “order amount” to a defined metric, maps “East China” to the region dimension, and converts “last month” into a concrete time range. The generated query uses parameter placeholders rather than concatenating values into the string:

SELECT SUM(amount) AS total_amount
FROM orders
WHERE region = :region
  AND order_date >= :start_date
  AND order_date < :end_date;

Parameters are bound by the database driver, which avoids injection risk. At the same time, the execution account should have read-only privileges and be restricted to accessible tables and fields.

3. Interactive Components: From Static Results to Actionable Outputs

When generated results need to be interactive, the frontend must embed runtime components. There are three key points here: isolation, communication, and permissions.

First, components should run in an isolated environment. Using an iframe with the sandbox attribute can restrict the component’s script capabilities and cross-origin behavior:

<iframe
  src="/embed/chart/123"
  sandbox="allow-scripts"
  referrerpolicy="no-referrer"
  title="Sales trend chart">
</iframe>

Second, the host page and the component communicate through messages. The receiver must validate the message origin and perform structural validation on the message content:

const EXPECTED_ORIGIN = window.location.origin;
window.addEventListener("message", (event) => {
  if (event.origin !== EXPECTED_ORIGIN) return;
  const { type, payload } = event.data ?? {};
  if (type === "chart:select" && isValidSelection(payload)) {
    handleSelection(payload);
  }
});

Message content should be treated as untrusted input; it should not be trusted simply because it comes from the component.

Third, component permissions should be controlled centrally by the host. A component can display data, but it should not be able to directly read the host’s login state or initiate arbitrary network requests. A Content Security Policy (CSP) can provide a fallback constraint at this layer.

4. System Architecture Design

A complete conversational generation system is usually divided into five layers: intent understanding, constrained generation, validation and permission checking, execution and rendering, and auditing and feedback. Clear responsibilities across these layers make it possible to locate problems quickly when errors occur.

The pseudocode below shows the main request-processing flow:

function handleRequest(user, utterance):
    intent = parseIntent(utterance)
    plan = buildPlan(intent, user.permissions)
    validatePlan(plan)              // structure, permissions, resource quotas
    if plan.requires_confirmation:
        return askConfirmation(plan)
    result = execute(plan)          // read-only query or sandboxed rendering
    audit(user, utterance, plan, result)
    return render(result)

The output of buildPlan is an intermediate representation, not directly executable code. validatePlan is a key line of defense: it isolates model output from real permissions and resource constraints. audit ensures that every generation and execution can be traced.