What an agent-native spreadsheet actually looks like

Most of the software your team uses was designed for a human with a mouse and a keyboard. When an agent tries to use it, the fit is awful. You've probably seen all three failure modes:

1. The agent pastes a CSV into the chat and asks you to save it somewhere.
2. The agent calls a REST API that returns a 400 because it wasn't designed for the thing the agent needed.
3. The agent spins up a headless browser and drives Google Sheets with a mouse, which is slow, flaky, and embarrassing to everyone involved.

None of these are the agent's fault. They're the fault of tools that were never built with an agent in mind.

This post is about what we did differently with Spatio Sheets.

The three things an agent needs that a human doesn't

A human editing a spreadsheet has a monitor, a pointer, and short-term memory. An agent has a tool-call API and a context window. If you want an agent to be good at a spreadsheet, you have to give it three things.

Addressability at the smallest useful unit. A human can click cell B3 and type 142. For an agent, "click cell B3" has to be a single, reliable primitive. Not "find the spreadsheet, download it, modify the XML, re-upload it." Just PATCH /v1/sheets/:id/rows/3/cells/B with {"value": 142}. One call, one cell, done.

Semantic operations, not screen operations. A human drags the bottom-right corner of a cell to fill down. An agent should never have to simulate that. It should call POST /v1/sheets/:id/rows with a row shape and know the row is now in the sheet. Fill-down, if it ever matters to an agent, is a named operation, not a screen gesture.

Every edit is a diff. Agents are going to make mistakes. The fix isn't "don't let agents edit." The fix is "make every edit reversible and reviewable." Every cell write in Spatio becomes a diff on a feed your team sees, attributable to the agent session that made it.

What this looks like concretely

A real example, from last week. I asked Claude Code to update our forecast with this quarter's numbers. The agent did this:

POST /v1/sheets/fcst_q1/rows
  { cells: { A: "Signups", B: 142, C: "+18%" } }

POST /v1/sheets/fcst_q1/rows
  { cells: { A: "Revenue", B: 12450, C: "+22%" } }

PATCH /v1/sheets/fcst_q1/rows/7/cells/D
  { value: "On track" }

Three tool calls. No downloaded file, no re-uploaded file, no race condition with someone else who had the sheet open. Each call is atomic, addressable, and shows up in my Desktop review feed as three distinct diffs I can approve or revert.

Compare that to the "agent drives a browser" version of the same thing. The agent opens the sheet in Chromium, waits for it to load, finds the right cell, types, tabs, types, and prays the DOM didn't mutate out from under it.

One is a tool designed for an agent. The other is a human tool being held hostage by one.

The same thinking, applied everywhere

The sheets example is the easiest to explain, but this principle shapes every resource in the SpatioAPI.

Notes are block-level. Each paragraph, heading, or list is a block with a stable ID. An agent appending a section to a note is one POST /notes/:id/blocks call, not a full-document rewrite that clobbers whatever a human just wrote.

Slides are slide-level. Each slide is addressable. Building a deck is a sequence of POST /slides/:id/slides calls. Editing a single slide is PATCH. No deck-regenerate-from-scratch flow.

Mail is draft-level. Agents create drafts. Drafts wait in your inbox until a human clicks send. No misdirected autonomy, no "the agent sent an email to the customer I didn't want it to send." Every outbound action lands in a review queue first.

Files are chunk-level. Large files get a manifest-based chunked upload, so an agent can stream a file up in pieces instead of holding the whole thing in its context.

Every design decision filters through the same question. Can an agent do this correctly in one or two calls, and can a human review the result as a diff? If not, we redesign until the answer is yes.

Why I'm writing about this

I think this is going to be a quiet but important split in the next couple of years.

Some software is going to add an "AI button" to the corner of its existing UI. It will feel impressive in a demo and fall apart the moment an agent tries to use it at volume.

Some software is going to be rebuilt, from the data model up, to treat agents as first-class clients. Addressable primitives. Reviewable diffs. Semantic operations. No more browser automation, no more "let me paste a CSV into the chat."

That's what we're building. The surface you see (Sheets, Notes, Slides, all of it) looks mostly like the tools you already know. The thing that's different is underneath.

If you want to see it, the easiest demo is to give Claude Code access to SpatioMCP and ask it to build you a pricing model in a sheet. Watch the rows appear in Desktop in real time. The whole thing will feel strangely natural, and that's the point.

Matt