From Chat to Canvas: The Evolution of Interaction Paradigms in AI Workspaces

1. The Starting Point: Text Is Not the Native Form of Requirements

For the past two years, the main channel for collaborating with large models has been a text input box. This works well for tasks such as mathematical reasoning and code generation, but once work moves into solution planning, process design, or budget preparation, the efficiency of text-based expression drops quickly.

The reason is straightforward: many requirements are inherently spatial and structural. The sequence of dependencies in a project timeline, the hierarchy in an organization chart, and the row-column relationships in a budget table can often be understood in a user’s mind within seconds, but describing them fully in natural language may require hundreds of words and can easily introduce ambiguity.

The more practical pain points appear in three areas:

• Structural information is lost in text. “Change the owner of the third step to Zhang San and keep everything else the same” may be easy to understand when a canvas exists, but without a canvas, the reference to “the third step” does not exist.
• The feedback loop is too long. The user writes a prompt, the model returns a result, the user notices a misunderstanding, and the user rephrases. Each round re-explains context instead of editing the original object.
• The output format does not match the delivery format. Users often need editable timelines or computable worksheets, not a paragraph describing them.

As a result, the emerging paradigm in the industry is not “better chatting,” but upgrading conversation into a shared operational interface: users can circle, drag, annotate, and otherwise manipulate content directly on a canvas, while AI extracts intent from those actions and writes results back as structured objects. In essence, prompt engineering moves down from the natural-language layer to the interaction-event layer.

2. Breaking Down the Capability: A Common Technical Model Behind Three Types of Tools

Whether the tool is a whiteboard, a spreadsheet, or a data-analysis panel, these capabilities can be abstracted into the same pipeline:

multimodal input → intent parsing → structured intermediate representation (IR) → validation → rendering/write-back → auditable trail

The difference lies in the form of the intermediate representation: graph structures, table structures, or query-and-chart structures. Understanding this is more valuable than memorizing the button positions of any specific product.

2.1 Interactive Whiteboards: From Operation Sequences to Graph Structures

The core of whiteboard capabilities is translating users’ spatial behavior into a machine-readable graph. Supported input channels typically include:

• Text and speech: verbally describing a rough plan;
• Hand-drawn shapes: sketching a box or an arrow;
• Existing materials: pasting documents, images, or data fragments;
• Selection-based instructions: selecting a region and then requesting a local modification.

The last item is key to the paradigm shift. It makes the scope of an instruction explicit. Without a selection, the model faces the entire viewport. With a selection, the model only needs to solve within that subgraph, which makes changes more controllable and easier to explain.

A minimal usable intermediate representation looks like this:

{
  "canvas_id": "ws-20251110-01",
  "revision": 7,
  "nodes": [
    {
      "id": "n1",
      "type": "milestone",
      "x": 120,
      "y": 80,
      "label": "Flavor Finalized",
      "owner": "team-A",
      "due": "D+3"
    },
    {
      "id": "n2",
      "type": "task",
      "x": 360,
      "y": 80,
      "label": "Cost Accounting",
      "owner": "team-B",
      "due": "D+5",
      "depends_on": ["n1"]
    }
  ],
  "edges": [
    {
      "from": "n1",
      "to": "n2",
      "kind": "finish_to_start"
    }
  ]
}

With this representation, several things become possible:

1. Local modifications do not break the whole. Changing node coordinates or replacing an owner is a field-level update to the JSON, not a regeneration of the entire diagram.
2. Multi-format export. The same graph can be rendered as a timeline, flowchart, task list, document structure, or presentation structure. Because charts and text share the same source, inconsistencies such as “one version in the chart and another in the document” can be avoided.
3. Automatic layout. The model provides semantics, such as who depends on whom, while layout is completed by deterministic algorithms. For example, hierarchical layout can be applied according to dependencies, or force-directed layout can be used when relationships are dense. Letting the model directly output pixel coordinates is a common cause of broken layouts.

2.2 Spreadsheet Generation and Editing: Computable Structured Output

The technical difficulty of spreadsheet generation is not generating a column of data, but generating a correct and maintainable model: worksheet division, field types, formulas, data validation, and conditional formatting.

The recommended approach is patch-based editing, rather than asking the model to rewrite the entire workbook:

{
  "sheet": "Recruitment Budget",
  "ops": [
    {
      "op": "add_column",
      "at": "F",
      "header": "Budget Balance",
      "type": "currency",
      "formula": "=E2-D2",
      "range": "F2:F200"
    },
    {
      "op": "conditional_format",
      "range": "B2:B200",
      "rule": "status == \"Overdue\"",
      "style": {
        "fill": "#FFE3E3"
      }
    },
    {
      "op": "data_validation",
      "range": "C2:C200",
      "list": ["In Progress", "Completed", "Overdue"]
    }
  ],
  "audit": {
    "actor": "agent",
    "reason": "Add balance column and highlight overdue items"
  }
}

This approach brings three engineering benefits:

• Changes are visible. The system can mark changed cells and regions in the UI and let users confirm them one by one, instead of presenting a fully rearranged table that cannot be checked.
• Changes are reversible. Each patch has a clear inverse operation, making rollback inexpensive.
• Changes are verifiable. Formula reference ranges, fields used by conditional formatting rules, and values in drop-down lists can be statically checked before application. Numeric and formula-based outputs must pass validation; otherwise errors can spread under the appearance of being professional.

Collaboration scenarios also require concurrency control. When multiple people edit the same sheet, teams need to choose between eventual consistency mechanisms, such as conflict-free replicated data types (CRDTs), and operational transformation. They should also distinguish between human edits and model edits in the operation log for later accountability.

2.3 Data-Analysis Agents: From Charts to Conclusions

The third type of capability turns the canvas from an expression tool into a decision-making tool. Its technical stack is relatively independent:

1. Metadata understanding. The agent must first understand table structures, field meanings, and partitioning strategies. This is especially true for metric definitions: what exactly counts as an “active user,” or whether “sales” includes tax. Without a semantic layer, generated SQL can be syntactically correct but business-incorrect.
2. Query generation and admission control. Natural-language-to-query conversion should be tightly constrained: read-only accounts, statement whitelists, mandatory time ranges and row limits, and a ban on unbounded full-table scans.

-- Example generated query: read-only, time-windowed, and result-limited
SELECT region, SUM(amount) AS gmv
FROM sales_order
WHERE order_date >= DATE '2025-07-01'
  AND order_date <  DATE '2025-10-01'
GROUP BY region
ORDER BY gmv DESC
LIMIT 50;

1. Narrative results. Convert result sets into charts and written conclusions while preserving a traceable chain from conclusion to data to metric definition. This point is often overlooked: analysis conclusions without a traceable path are almost unusable in business reviews.
2. Enterprise system integration. Connect to data warehouses, cloud data-analysis services, customer relationship management systems, and other enterprise systems through a unified data-access layer for authentication and auditing, rather than writing a separate adapter for each system.

3. Engineering Challenges That Must Be Addressed Directly

3.1 Consistency Between Semantics and Geometry

Hand-drawn sketch recognition allows considerable tolerance, but when a sketch is converted into a formal diagram, misplaced nodes or incorrect arrows turn the output from helpful into misleading. A practical approach is to structure first, then lay out, and to have the model output semantic labels and confidence scores during generation. Low-confidence elements can be highlighted in a different style for user confirmation.

3.2 Stability of the Intermediate Representation

The intermediate representation is the foundation of the entire system. It should follow three principles: serializable for storage and transmission, diffable for collaboration and auditing, and schema-constrained with clear field enumerations for validation. If the model directly outputs HTML or UI code as the intermediate representation, multi-end rendering and incremental updates can quickly become unmanageable.

3.3 Amplified Hallucination in Structured Outputs

Text hallucinations are easy to notice, but a wrong formula, a missing dependency edge, or an incorrect date may only appear after users actually use the output. The response is layered validation: syntax layer (whether it can be parsed), reference layer (whether referenced nodes or fields exist), semantic layer (whether values can be recomputed and whether time is earlier than prerequisite tasks), and business layer (whether it conforms to established definitions).

3.4 Permission and Security Boundaries

Canvas collaboration is inherently multi-user, and every model write should inherit the permissions of the initiating user rather than using a high-privilege service account. Tables and queries involving sensitive data require masking policies, row-level permissions, and complete audit logs. When generative capabilities connect to enterprise production data, these are not bonus features; they are admission thresholds.

4. Suggested Enterprise Adoption Path

Do not try to replace the existing office toolchain all at once. A more reliable order is:

1. Single-point efficiency gains. Start with scenarios that are highly structured and have obvious rework costs, such as first drafts of project schedules, standard budget-table templates, and periodic data reports.
2. Team collaboration. Introduce shared canvases and change trails so AI-generated outputs become objects for team review rather than personal drafts.
3. System integration. Connect canvas outputs to existing document, task, and data platforms through standard interfaces to avoid creating new data silos.

At the infrastructure level, such systems usually require a combination of model services, object storage for canvas versions and exported files, message queues for asynchronous generation tasks, container platforms for rendering and agent services, logging services, and monitoring and alerting. For example, cloud platforms such as Baidu AI Cloud already offer many of these capabilities as general product categories, which can be combined as needed instead of being built entirely in-house.

At least four evaluation metrics are recommended: first-pass success rate (outputs usable without modification), manual rework rate, structural correctness rate (the proportion of errors in formulas, dependencies, or metric definitions), and end-to-end latency. Features launched without quantitative metrics are difficult to sustain in real workflows over the long term.

5. Capability Boundaries and Rational Expectations

It is important to be clear that these tools change interaction efficiency, not accountability for judgment.

• Highly regulated scenarios are not suitable. Financial reports, legal clauses, and audit working papers that require signatures or seals must receive final human confirmation.
• Complex financial modeling remains a weak area. Multi-round sensitivity analysis and complex scenario-assumption modeling should still be handled by specialized tools and professionals.
• Precise layout cannot be replaced. Formal deliverables still depend on professional typesetting tools for layout standards.
• Data-analysis conclusions require review. Agents are good at organizing existing data into readable form, but causal judgment and business attribution still require human judgment.

6. Conclusion

From dialog boxes to operable canvases, the surface change is that users can “show” things by drawing, but the substantive change is moving interaction cost from description to operation. For developers, the areas worth investing in are not chasing specific features, but three things: designing a stable intermediate representation, building a layered validation system, and clarifying permission and audit boundaries. If these three things are done well, generative outputs can reliably enter real workflows regardless of how underlying models iterate. Otherwise, even the most impressive interaction is only a demo.