What “agent-native runtime” means for office files in Univer

Univer is an office runtime built for AI agents: spreadsheets, docs, slides, canvases, relational tables, and PDFs share one storage and computation layer, and every file becomes structured, verifiable code that agents can read and change. That matters if you want agents to work across mixed office files without losing context, and if you need human review of every change. It is not a single-purpose spreadsheet library, and it is not a hosted product you simply log into — the site positions it as an SDK you embed, self-host, and connect to your own auth, databases, and knowledge bases.

What “agent-native” changes in practice

In a conventional office suite, a file is a document for humans and an opaque blob for software. An agent can open it, but it cannot reliably reason about its structure, and it cannot verify what it changed.

Univer inverts that. The runtime treats office content as structured, verifiable code. The practical consequences:

• Agents work across every file type without losing context. Sheets, docs, slides, canvases, relational tables, and PDFs run on the same runtime, so an agent moving from a table to a slide that cites it does not restart from zero.
• Data stays synchronized. When a source changes, references update. A slide can hold a live sheet; a doc can cite its source; a canvas can lay out the result.
• Humans and agents co-edit the same file. Every change is traceable, and the design assumes human-reviewed changes rather than unreviewed automation.

One runtime, six tools

The composition model is the part that distinguishes Univer from stitching together separate libraries.

Because sheets, docs, slides, and canvases live in one .univer file, they compose and embed freely. A slide holding a live sheet is not an import — it is the same object, so the reference stays current.

Multi-agent workflows on worktrees

Parallel agent work usually fails at merge time. Univer's answer is isolated worktrees: agents work in parallel by default, and their changes are human-reviewed by design. You get concurrency without giving up a review gate.

The runtime is built for any agent — the site lists OpenCode, Claude Code, OpenClaw, Hermes, Codex, WorkBuddy, and Kimi Work — so the workflow layer is not tied to one vendor.

How you would actually adopt it

Univer is an SDK, so the path is build-and-embed rather than sign-up-and-use:

1. Start from the SDK. Build with all six office tools and multi-agent worktrees inside your own product.
2. Build your own UI and UX. The SDK does not dictate the interface.
3. Self-host. Connect your own auth, databases, and knowledge bases.
4. Customize down to the engine. Formulas, assets, and components are all adjustable.
5. Use one integration for six tools. They compose and embed freely rather than requiring six separate integrations.

The site offers a copyable SDK prompt, a live demo, and documentation as entry points.

Where it fits, and where it does not

Choose Univer when you are building a product where agents and humans edit office files together, you need cross-file context and synchronized references, and you want to self-host with your own auth and data layer.

Look elsewhere if you want a finished end-user office app, or if you need a single spreadsheet component with no document, slide, canvas, table, or PDF surface. The site does not publish pricing or a hosted sign-up flow, so treat it as an SDK to evaluate and self-host rather than a service with a free tier — verify licensing and deployment terms with the project before committing.