SumSheet and SumDoc understand the application inside the file — formulas, Power Query, VBA, workbook events, form controls, embedded objects and external automation — and let people and AI work with it under explicit control. One native DOCX & XLSX engine, everywhere the work happens.
Open it. Understand it. Run it. Modernize it. Preserve it.
Models are replaceable: Claude · OpenAI · DeepSeek · MCP. The application runtime is ours.
This is not a screenshot. Edit a cell, ask the agent, undo it.
| A | B | C | D | |
|---|---|---|---|---|
| 1 | Item | Price | Qty | Total |
| 2 | Copy paper | |||
| 3 | Toner cartridge | |||
| 4 | Staples | |||
| 5 | =SUM |
The Supplier shall deliver the goods listed in the specification, and the Buyer shall accept and pay for them within ten business days. This paragraph is editable — click and type.
Familiar to everyone — but your process stays tied to an installed copy. Microsoft doesn't support unattended server-side automation.
Easy to embed — but part of your corporate automation has to be rewritten in another language.
A different engine means different document rules — and drift between what a person sees and what the server does.
An assistant next to the editor that still has to be taught how to change a file safely.
A person works in the interface. Your system calls the API. An agent issues typed operations. The server runs the same semantics — and the saved file is verified by opening it again.
different interfacesThe worst thing an Office alternative does: open your file, look fine, and quietly drop what it didn't understand on save. We don't. What the engine doesn't support, it preserves untouched and tells you about. If it can't save without loss, it refuses before changing anything — not after.
Sources, transformations, preview, load, refresh.
what we support →Inspect, plan, preview, budgeted run, rollback.
what we support →Fields, controls and the data bound to them.
what we support →Direction in the document model, not a menu translation.
what we support →Embedded objects survive open and save, lossless.
what we support →Exactly what's supported today is an open list with a last-checked date, generated from the engine's own audits. Can't do it — we say so. Can — we keep it.
We exercise the engine against a corpus of real-world government documents — annual reports, handbooks, toolkits, forms. Here are four of them, verbatim: two light, two heavyweights. The rule that binds them all: what the engine can't draw yet, it preserves byte-for-byte and says so — the file comes back whole.
The stress test: a 32-page annual report — full-bleed photography, budget and acreage tables, staffing profiles. A file that breaks lesser importers.
Real SumDoc and SumSheet, in your browser, no install and no sign-up. Each of these opens a real-world file; edits live only inside the cabin and are saved nowhere.
SumDoc for documents, SumSheet for spreadsheets — free editors for iOS, Android and macOS. They are also the reference integration you can hold: a system WebView around the same surface, assembled exactly the way the quickstart describes. What your integration would feel like — before you write a line of code.
Live in all three stores: iOS, Android, and now macOS — SumDoc and SumSheet are both on the Mac App Store.
The document engine is Rust — ten crates behind SumDoc, twenty-one behind SumSheet. Pagination, print and PDF come out of one scene, and the screen draws that same scene onto a canvas: the browser never lays the text out itself, so a WebView or Chromium update doesn't move a line. SumSheet evaluates formulas in the engine, not in the page. That is why one engine ships unchanged to the desktop, to a browser tab and to a phone.
Compiled for each platform, not wrapped: macOS on Apple silicon, Windows on x64 and ARM64, Linux as deb, rpm and AppImage — on X11 and on Wayland, GNOME included. Every build is on the download page with its checksum.
Startup is measured, not promised. On the live node on 5 September, in a clean browser profile, a two-page brief was on screen in one to three seconds and a 24-page draft with tracked changes in three to four. The desktop editor shows a document about two seconds after launch on a laptop. Open either link and count.
Both editors speak WOPI — the same protocol your document system already uses to hand files to an editor and take them back. The document never leaves your storage; SumDoc and SumSheet bring editing, calculation and collaboration to it, then write the file back natively.
Locks and versions are part of the contract, not decoration. If someone else changed the file while you were editing, the save is refused with the reason — not silently written over. If the storage says you may only read, you only read.
What we don't claim yet: certification against SharePoint, Nextcloud or ownCloud. The protocol is exercised against our own WOPI host; a full editing cycle against an external storage is on the list, not on the shelf.
A macro, a query refresh or an agent's plan can rewrite a lot of cells at once. In SumSheet the run produces a preview of the resulting changes first — not a log of every intermediate write — and only what you accept is committed to the open workbook, through the same cell-edit path a person uses. Decline, and it rolls back.
If the workbook changed underneath the run, the commit is refused rather than merged blindly. Structural changes and Save As are outside this transaction and are refused too — we say so instead of pretending every operation is reversible.
This is where VBA and Power Query stop being legacy and become the organisation's own formalised knowledge: the process you already have, run under rules you can see.
Not every Excel macro: supported VBA scenarios run natively; COM, external libraries and unsupported statements are refused with a message, not emulated. Legacy .doc opens as text and paragraphs — styles, tables and images from that format are listed as not carried over. Collaboration is proven for text operations and cells; objects and formatting under concurrent edits are still being measured. The capabilities page is generated from the engine's own audits and carries a last-checked date.
Macros, workbook events, Power Query, external objects, form controls, embedded objects: the engine maps what the file is made of, runs what is safe on a copy, asks you before anything touches the outside, and preserves the rest untouched. Every demo below is live, on a real workbook in a real editor cabin.
A cash-flow model of a small company: a year of bank-fed actuals, a 2027 forecast built from three assumptions, a VBA macro that flags the months where cash runs out, a Worksheet_Change handler and a Power Query over the bank export — all inside one .xlsm. In the film the agent fills the assumptions (the engine previews 54 cells before Apply) and you press Apply — the forecast changes; then a person types 12% and the sheet’s own event writes the scenario line. The full take also runs FlagCashGaps on a copy and applies 26 cells.
Not a mock-up: the file opens in Excel as is, and the cabin below is the one in the recording.
Open the workbook, press ✦ Agent → …or download it, 19 KB, macro, event and query inside →Three things people do not expect from an agent in a spreadsheet. Each one runs live below, on a real workbook in a real editor cabin, in a few seconds — the answer comes from the engine at the moment you click, not from a recording.
Ask what CloseQuarter does. The agent reads the VBA source out of the workbook, explains it in plain words and names the cells it would touch. The macro never executes.
Then ask it to run. The engine executes the macro on a copy of the workbook, shows every changed cell before and after, checks that no sheets, rows or names moved — and waits for your Apply. Download the .xlsm afterwards and open it in Excel.
…or download the workbook, 8 KB, macro inside →Ask what SalesByRegion does. The agent reads the query definition from the workbook — six steps in order, from the raw order export to the sorted table it loads — and explains the pipeline. Nothing is refreshed, and the M body stays inside the file.
Not lab samples. Three real workbooks from the wild — a World Bank forecast table and two open-source VBA libraries — opened in a live cabin. The agent tells you what it can run here, what it only reads, and what it preserves untouched. We do not restyle these three: unlike our own sample workbooks, they are shown exactly as their authors published them — that is the point of having them here.
169 rows of real GDP growth by economy, 2023–2027f, straight from the World Bank release. Ask which economies slow down next year: the agent reads the cells and cites them, so every number can be checked against the sheet.
…or open the workbook and press ✦ Agent → Source: World Bank, Global Economic Prospects, June 2026 (worldbank.org). Not affiliated.VBA-Web, the open-source HTTP library for Excel. Ask how it is built: the engine reports every module and procedure, which 77 could run natively here, and which 23 need external objects — CreateObject, Application.Run. Nothing runs; the map comes from the engine, not from the model’s guess.
SQLite for Excel: 66 procedures, 63 of them call Windows and SQLite DLLs through Declare. The agent lists the libraries and the procedures that depend on them, says plainly that none of it runs on this Linux node — and the project is preserved byte-for-byte for Excel.
This workbook carries Workbook_Open and Worksheet_Change handlers. Open it, press ✦ Agent and click Enable macros here: that is your decision, like “Enable content” in Excel, and Workbook_Open runs once and fills B15. Then type ORD-1234 in column I — the sheet’s own handler, executed by the engine, writes the verdict in J. Type something wrong and it says so.
Nothing here is scripted by the model: the code is inside the file, the engine runs it, and it runs only after you allowed it.
Open the workbook and try it → …or download it, 8 KB, handlers inside →
Live frame, 6 September: the handlers wrote B15, J6 and J7 in the browser cabin.
The same order-desk workbook carries SummarizeOrders, a macro that creates two Windows objects — Scripting.Dictionary and VBScript.RegExp. The Execution passport in the ✦ Agent panel names them, from the macro’s own text, and says: denied by policy until you allow them for this session. Only you can press Allow, only for the objects the file asks for, only for this session — the model has no such tool.
Then Run safely — on a copy: the engine’s broker serves the objects without Windows and journals every call. The passport shows the journal — 28 calls, which class, which method, what the broker answered — and the open workbook stays untouched until you apply.
Open the workbook, press ✦ Agent → …or download it, 8 KB, three macros inside →
Live frame, 6 September: two grants by a person, one run on a copy, the journal in the passport.
A workbook from the U.S. Office of Natural Resources Revenue, exactly as published: 116 rows of offshore facilities and a data connection to a text file on a network drive nobody outside the agency can reach. The ✦ Agent panel reads connections.xml and says so in the passport: 1 connection, text from P:\buyback_gulf.lst — the data stays as saved in the workbook; nothing is refreshed by the agent, the source is never contacted.
No VBA here — and the passport says that too: this workbook is data, formulas and connections. Open it, ask what it depends on; the answer comes from the file, not from a guess.
Open the workbook, press ✦ Agent → …or download it, 17 KB, connection inside → Source: U.S. Department of the Interior, ONRR (onrr.gov), public record. Not affiliated.
Live frame, 6 September: the passport of a data-only workbook — code, external data, what is never touched.
Ask the agent. A model on our node drives the editor’s own tools on a live cabin. Every step below is an event the runtime actually emitted — which tool ran, what came back. In Prepare changes the engine builds the change on a copy, shows before and after with what the code checked, and nothing changes until you press Apply. Then download the file and open it in Word or Excel.
It doesn't click pixels and doesn't write into the file directly. Same operations, same history, same save path as the person at the screen — every change visible, every change reversible. The engine speaks MCP, so the assistant you already use plugs straight in.
Connect one now. The demo documents on this site are served to MCP clients at https://view.sumoffice.com/mcp — five read tools today (document_open, document_describe, document_read, document_find, document_comments) over the same live editor cabins the buttons above open. Each session gets its own cabin; nothing is written back yet — proposals and approve-then-apply are the next step, and we will say so here when they land, not before.
Or inside the editor. Open a sample in the browser editor and press ✦ Agent in the corner: the same panel — Task, Changes, Checks — works on the document you have open, through the editor’s own tools, and nothing changes until you press Apply. Spreadsheet: event budget · Document: workshop brochure · Spreadsheet with a macro (ask it to explain the macro — it reads the source and never runs it; ask it to run — it runs on a copy and you apply) · Spreadsheet with a Power Query
Word and Excel turned documents into a shared language across whole industries; COM, VBA, XLL and Office.js made it extensible. We even named ourselves after their finest lesson — the first formula anyone ever learns. We're not crossing that work out. We're carrying it where their product can't go by its very nature: inside someone else's application, on a server, in an unattended process.
SumOffice is an independent product, not affiliated with or endorsed by Microsoft. Microsoft, Excel, Word, VBA and Power Query are trademarks of their respective owners.
The document opened. The formula recalculated. The query refreshed. The macro ran. The form saved. The agent showed its changes. The file opened again.
Everything else is the editor's job.