How Univer Unifies Spreadsheets, Docs, Slides, Canvases, Tables, and PDFs in One Runtime

Univer unifies six office tools — Spreadsheet, Docs, Slides, Canvas, Relational Table, and PDF Editor — by running them on a single runtime that shares the same storage and computation layer. Instead of stitching together separate file formats and engines, all six tools live inside one .univer file, where blocks of different types can compose and embed freely and stay synchronized. This matters if you want agents and humans to work across multiple file types without losing context or manually reconciling data between them.

The core mechanism: one runtime, shared storage and computation

The unifying idea is that the six tools are not separate products glued together. They share:

• The same storage — content from every tool type is held in one place rather than in isolated files.
• The same computation — formulas, references, and derived values are computed against a common layer.

Because storage and computation are shared, a change in one block can propagate to anything that references it. The site describes this as "Data stays synchronized — sources change, references update."

What this looks like in practice

The clearest example given is composition across types: a slide can hold a live sheet, a doc can cite its source, and a canvas can lay it all out. These aren't static embeds — the embedded content remains connected to its origin, so when the source changes, the reference updates.

The six tools in the runtime

The point of the table isn't feature comparison — it's that all six are addressed through one integration, and they can be "composed and embedded freely."

The .univer file as the container

Rather than exporting between formats, Univer keeps multi-type content in a single .univer file. Within that file:

• Every block lives in one place.
• Blocks of different types can reference each other.
• Humans and agents co-edit the same file, and every change is traceable.

This is what makes cross-type references stable: a doc citing its source, or a slide holding a live sheet, works because both live in the same container under the same runtime.

Why this matters for agent workflows

Univer describes itself as "the office harness for AI agents" — an agent-native runtime. Two properties follow from the unified design:

1. Agents work across every file type without losing context. Because the tools share storage and computation, an agent doesn't need to translate between formats or re-establish context when moving from a sheet to a doc to a slide.
2. Parallel work is isolated and reviewable. Univer supports Multi-Agent Workflows on Worktrees — parallel by default, human-reviewed by design — with isolated worktrees and human-reviewed changes.

The site lists compatibility with a range of agents, including OpenCode, Claude Code, OpenClaw, Hermes, Codex, WorkBuddy, and Kimi Work.

How to start building

Univer offers an Office SDK for embedding all six tools and the multi-agent worktree workflows inside your own product. Per the site, with the SDK you can:

• Build your own UI and UX.
• Self-host and connect your own auth, databases, and knowledge bases.
• Customize formulas, assets, and components down to the engine.
• Use one integration for six office tools, composed and embedded freely.

Entry points referenced on the page: the SDK prompt (copyable), the docs, a live demo, and the GitHub repository.

What to keep in mind

• The unification claim rests on shared storage and computation — the value shows up when content of different types references each other, not when you use a single tool in isolation.
• Synchronization is described as automatic ("sources change, references update"), which is the property to verify against your own use case.
• The page does not state pricing, licensing terms, or login requirements, so treat availability and cost as things to confirm directly before committing.