Three Things a Spreadsheet Model Knows That the Language Model Doesn't
Why Microsoft's AI Function Had to Die
Microsoft is killing =COPILOT, its attempt to put a language model inside an Excel formula. On August 13 it withdrew the function’s desktop general-availability roadmap item. The next day, Microsoft announced that the feature would be retired on September 14. It never made it to general availability.
=COPILOT launched in August 2025 with a compelling premise: put a prompt in a cell, reference some data, and let Excel’s calculation engine automatically update the AI output as the data changed. This was Microsoft’s second attempt at the idea, after the experimental LABS.GENERATIVEAI.
The problems showed up immediately. Four days after launch, the Institute of Chartered Accountants in England and Wales tested =COPILOT on a five-year product forecast. The output looked plausible but was wrong, including errors that were small enough to survive casual inspection. Microsoft itself warned users not to rely on the function for numerical calculations.
The feature expanded to Excel for the web, but general availability kept slipping, from December 2026 to January 2027, and then disappeared altogether. Thirteen months after launch, Microsoft pulled it.
Microsoft hasn’t said why, and I don’t know its internal reasoning. But the architecture was public, and so were its constraints.
But the interesting question isn’t why Microsoft killed =COPILOT. It’s why putting a general-purpose language model behind spreadsheet-function semantics creates such a predictable set of problems.
The model knows more than the LLM
Frontier language models can build competent financial models. That’s becoming less interesting by the month. Give Claude or ChatGPT an earnings release, some historical data and decent instructions, and it can produce something recognizable and useful in minutes: revenue, margins, EPS, forecasts and, more important, a set of assumptions. For many purposes, that’s a reasonable starting point. I call it the consensus model, since as more people do this, that’s what it will be.
The harder problem starts afterward. A financial model contains information the language model doesn’t have, even when the model can see the numbers. Three things matter: Model Logic, Model Memory and Semantic Compression.
Model Logic is how the financial model works. Formula dependencies are facts. Precedents and consumers are facts. Dependency closure can be computed. Period structure, units and forecast responsibilities can be deterministically qualified from the workbook as well. Where they cannot, that uncertainty matters.
The basic principle is simple: don’t pay a language model to guess relationships that a computer can establish exactly, deterministically.
Model Memory is what happened. What did the analyst decide last quarter? What method did they approve? What evidence supported it? What changed afterward? Does that judgment still apply, or has its basis changed?
Without memory, every LLM invocation starts from zero. A financial model may have years of analytical history behind it while the language model experiences every call as the first day on the job against the current workbook.
Semantic Compression is what becomes possible when you combine the first two. A workbook with 11,112 cells may contain one bounded analytical responsibility called Services Revenue Growth. That responsibility has a forecast horizon, inputs, consumers, dependencies, prior analyst judgment, supporting evidence and perhaps some facts that remain unresolved. Once those things are established, the frontier model doesn’t need an abbreviated version of 11,112 cells.
It can receive a different, smaller object altogether.
That’s the distinction. Semantic compression isn’t just prompt shrinking - the goal is to give the language model bounded context, and less uncertainty. Fewer tokens are a very useful side effect of proper context.
What =COPILOT knew
Microsoft’s documentation makes the informational boundary fairly clear. The function worked from the prompt and the ranges supplied to it. It received values, but not the financial model surrounding those values.
Suppose one of those values is 4.7%. Is that revenue growth, a tax rate, deposit beta, cost of capital or charge-offs? Now suppose the cell containing that assumption ultimately affects 298 downstream cells. Excel knows those relationships because they are encoded in the workbook. A language model doesn’t know them merely because somebody handed it 4.7%.
That’s the absence of Model Logic.
Run the function again next quarter and there’s another problem: There is no inherent analytical continuity between that call and the previous one: no approved thesis, no durable understanding of why an assumption changed, no evidence record and no concept of what the analyst believed going into the last earnings report.
That’s the absence of Model Memory.
Without either one, there is no meaningful semantic layer between the grid and the probabilistic model. The prompt becomes the interface, and every call carries the burden of reconstructing meaning from whatever values and instructions happen to have been supplied.
Then Microsoft put that architecture inside a spreadsheet calculation engine.
Bad placement creates bad economics
Excel formulas are cheap and fast. They can run constantly. Change an input and Excel recalculates. Open the workbook and Excel recalculates. Change another dependency and Excel recalculates again. This works because arithmetic is effectively free.
Frontier-model inference is none of those things. It costs money, takes meaningful time and is probabilistic. Yet =COPILOT inherited the invocation semantics of a spreadsheet formula. That matters because placement determines invocation frequency, invocation frequency determines cost, and cost determines how much intelligence you can afford behind each call.
Microsoft’s preview documentation showed the consequences: gpt-4.1-mini, usage limits and explicit warnings against numerical calculation, workbook lookups and other consequential applications. Those can look like an arbitrary collection of preview restrictions. I think they are better understood as consequences of the architecture.
No Model Logic and no Model Memory mean high semantic load per call. Put those calls at spreadsheet recalculation frequency and the inference has to be cheap. Once it has to be cheap, fast and bounded, the viable problem set collapses: summarize these comments, classify these descriptions, generate some labels.
Those are legitimate tasks. They’re just not why complex financial models exist.
The problem wasn’t simply that the model needed to get better. The intelligence was sitting at the wrong boundary. The spreadsheet cell is a useful application boundary. It is a terrible inference boundary.
IRIS starts on the other side
IRIS starts before the model call. It reads the workbook and computes the structure that can be computed: formula dependencies, consumers, period structure (where it can be established), row labels, and bounded forecast responsibilities where they can be qualified.
It does not ask a frontier model to rediscover facts the workbook already contains.
Consider Services Revenue Growth. IRIS may be able to establish that this is one forecast responsibility covering eight quarters, consuming a bounded set of inputs and affecting a known set of downstream calculations. Only then does the interesting problem begin, because knowing what is being forecast is different from deciding how it should be forecast.
IRIS represents that judgment as a Method. A Method isn’t just a prompt hidden in a cell. It is an analytical specification for how one part of the model should be forecast: the calculation convention, evidence hierarchy, judgment rules, guardrails and output contract.
Now take an imported model that effectively represents consensus. Maybe Services growth decelerates in line with the Street. But the analyst believes attach rates remain stronger for another two quarters. The analyst changes the Method, runs the model and sees the consequence in the workbook (and diffs if they want). That decision, its application and its resulting model Version become part of the record.
The spreadsheet can still expose the Method through an =AI() formula. The difference is what that formula means. It isn’t asking a language model to figure out what this part of the spreadsheet means from scratch. It is applying an already identified analytical Method at a known location in the model.
That distinction changes both the product and the economics.
Model Memory changes the next question
Once the analyst changes a Method, IRIS retains the analytical history. Three months later, after another earnings report, the system doesn’t need to begin again with a blank prompt. It can ask better questions: What did we believe? Why did we believe it? What happened? What changed? Does this Method still hold against the current version of the model?
That’s Model Memory. Financial modeling becomes an accumulating analytical process rather than a sequence of disconnected prompts.
It also creates another form of compression. The frontier model doesn’t need the entire history of the workbook any more than it needs the entire workbook. It needs the relevant history of the analytical responsibility in front of it: the prior Method, evidence, consequences, subsequent changes and anything that invalidates the earlier judgment.
This is where the economics invert.
=COPILOT had to make inference cheap enough to call constantly. IRIS tries to make the analytical problem small enough that expensive intelligence can be called rarely. Twenty forecast cells governed by one Method don’t necessarily require twenty independent provider calls. The workbook can retain twenty visible, cell-specific applications while the underlying Method is evaluated as one bounded analytical problem returning validated period outputs.
Instead of many calls to a cheap model with weak context, you get fewer calls to a frontier model over prepared context. Semantic compression is what makes the expensive model affordable.
A formula that has to become a constant
Microsoft’s documentation contained another clue about the underlying mismatch. The same =COPILOT arguments could produce different results over time. That’s normal behavior for a probabilistic model. It’s unusual behavior for an Excel formula.
Microsoft’s practical workaround was revealing: if a user needed to preserve an output, copy it and paste it as values. In other words, the remedy for a probabilistic formula was to turn it into a constant.
IRIS’ solution is snapshotting and versioning.
The bill
IRIS’s approach gives up some things that make AI demos look magical. There is less type-a-sentence-and-watch-the-numbers-move. The system sometimes says it doesn’t know. Structural recognition has to be recomputed when its basis changes. Some apparently obvious relationships may remain unresolved until there is enough evidence to establish them.
That’s a real product cost. Blind randomness demos better.
But financial analysts already live with the underlying distinction. Facts are facts. Judgments are judgments. Unknowns are unknowns. A system that operates on financial models should know which is which.
The objective isn’t to remove probabilistic reasoning. It’s to reserve probabilistic reasoning for the part of the problem where it has comparative advantage: analytical judgment under uncertainty. Computers are already very good at following formula edges and comparing versions exactly.
Don’t pay a frontier model to guess those things.
The bigger point
This isn’t really about Excel. A codebase has structure. So does a ledger, a schematic or any other deterministic artifact. Each presents the same architectural choice: hand the frontier model the blob and ask it to reconstruct what matters, or compute the structure first, preserve what has already been learned, declare what remains unknown and then ask the model to reason.
Microsoft tried putting the intelligence directly in the cell. IRIS puts structure and memory in front of it.
That’s semantic compression.
The lesson from =COPILOT isn’t that AI doesn’t belong in financial models. It’s almost the opposite. Frontier models are becoming good enough that the important architectural question is no longer whether to use them.
It’s what they should know before you call them.