Your agent can't do math.

The spreadsheet built for agents. Ask it for a hiring plan, a burn model, runway three ways.

scroll

You've tried pointing it at a spreadsheet.

It reads B14 and has no idea that means March payroll. The meaning lives in labels printed for your eyes, not for a reader parsing text.

Your files still come along: our open reading format scored highest of the eleven tested, 26 to 53 percent fewer tokens than JSON, zero context overflows in 19,000 model calls. Method and runs.

Your model floods its context window.

Every cell arrives as tokens. The window fills before your agent finds the number you asked about.

Your questions have more dimensions than a sheet.

"What's our burn if we hire three engineers in October, in the downside case?" Team by month by scenario. For an agent, that should be one address.

So we removed the grid.

payroll = headcount * salary

Written once. It fills itself.

Names, not coordinates.

Add a dimension. The address grows. The formula doesn't.

Every number shows its work.

Ask why burn jumped in March and your agent traces the chain: which formula, which inputs, which write. Bad assumption? Undo it. The engine underneath is six years in the making and runs real company finances in production today.

A runway model in six tool calls.

1. edit_tables · create runway_model [month, team, scenario]

   One call. No tabs, no ranges, no copied sheets.

2. set_default · dry_run: burn = payroll + tooling

   A dry run writes nothing. Validation and warnings come back first.

3. set_default · write: burn = payroll + tooling

   Committed. One formula, every cell.

4. edit_scenarios · create: downside

   A scenario is a real object, not a copied file.

5. edit_cells · hires[month=Oct, team=Eng] = 3

   Your question, written as an address.

6. edit_history · undo

   Bad assumption? The write reverts, and the chain shows why.