Skip to main content

The Real Backend Is a Spreadsheet — and Your Agent Just Got Write Access

· 10 min read
Tian Pan
Software Engineer

Ask an engineer where their company's business logic lives and they'll point at a Git repository. Ask the finance team, the ops team, or the sales team, and the honest answer is a file called pricing_model_v7_FINAL_final.xlsx. The pricing formulas, the headcount plan, the commission calculations, the month-end reconciliation macros — the operational core of most companies runs on Excel and Google Sheets. It has no types, no tests, no code review, and no deploy pipeline. It is production infrastructure maintained like a napkin sketch.

For thirty years this mostly worked, because the only things reading and writing those files were humans — slow, cautious, and equipped with an intuition for "that number looks wrong." That era just ended. MCP servers for Google Sheets and Excel now expose full create-read-update-delete access as first-class agent tools, and every agent platform ships a spreadsheet connector because that's where the customers' data actually is. We have connected the fastest writers ever built to the most fragile production system ever deployed, and most teams did it in an afternoon without a single design review.

The failure mode isn't hypothetical. A 2024 study of business spreadsheets found errors in 94% of them — and that's the baseline quality of the systems agents are now editing, before any agent touches them. The question isn't whether your agent will corrupt a spreadsheet. It's whether you'll notice before the number it corrupted becomes a decision.

Spreadsheets Are an Untyped Production API

Strip away the grid UI and a business spreadsheet is three things at once: a database, a program, and a report. Column C is a table schema that exists only in the header cell's text. The formula in D14 is business logic. The conditional formatting on the totals row is the monitoring dashboard. All three layers live in the same mutable cells, and nothing enforces the boundaries between them.

This makes a spreadsheet an API with the worst possible contract:

  • No types. A column of dates can silently hold a string. A percentage can be stored as 0.15 in one row and 15 in the next. Nothing complains until a downstream SUM produces garbage — and often not even then.
  • No schema enforcement. Insert a column between B and C and every consumer that addressed data positionally is now reading the wrong field. There is no compiler error. There is no runtime exception. There is just a wrong number, formatted beautifully.
  • No tests. The formula that computes your gross margin has no assertion checking it. Its correctness was verified once, by the person who wrote it, by eyeballing the output. That person may have left the company.
  • No review. Edits go straight to production. Version history exists, but nobody reads a Google Sheets revision log the way they read a pull request.

The error-detection system for all of this has always been human perception. Someone senior glances at the quarterly roll-up and says "that can't be right." That check is slow, unreliable, and — crucially — calibrated to human editing patterns. A human makes one or two edits and looks at the result. An agent can make four hundred edits in the time it takes to read this sentence.

What Agents Break That Humans Don't

It's tempting to think an agent is just a faster human editor, so existing informal safeguards will scale. They don't, because agents fail in structurally different ways.

Agents overwrite formulas with values. The single most common corruption pattern: the agent is asked to "update the Q3 revenue number," and it writes 1250000 into a cell that used to contain =SUM(Sheet2!B4:B87). The sheet now shows a plausible number that will never update again. Every future quarter silently reports stale data. A human might do this too — but a human usually notices the formula bar; an agent working through an API sees a cell address and a value, and many spreadsheet tools return computed values rather than formulas by default, so the agent may not even know a formula was there.

Agents trust positional addressing. Most agent-to-sheet interactions resolve to A1-style references. But A1 references are pointers into a layout, not into a schema. If anyone — human or agent — inserted a row above the target since the agent last read the sheet, the write lands one row off. In a codebase this is a merge conflict; in a spreadsheet it's a silent misalignment that shifts an entire column of data against its labels. Read-then-write races that Git would catch structurally are invisible here.

Agents flatten what they can't see. Hidden sheets, macros, pivot cache, data validation rules, cell comments explaining "don't touch this, it feeds the board deck" — most programmatic access paths either don't surface these or actively destroy them on write. Several current AI spreadsheet tools are documented to flatten files with macros or hidden sheets to raw values. The invariants a workbook's author encoded in structure and formatting are exactly the parts an agent's file representation throws away.

Agents coerce at scale. Excel's type coercion famously mangled genetics research — it converted gene names like SEPT1 and MARCH1 into dates so persistently that the genes were eventually renamed (SEPT1 is now SEPTIN1: the scientific nomenclature changed because the spreadsheet wouldn't). That was humans pasting data. An agent doing bulk enrichment across ten thousand rows hits every coercion edge case in the format at once, and unlike the geneticists, it doesn't publish a paper about the damage.

Loading…
References:Let's stay in touch and Follow me for more thoughts and updates