Google just paid $10 million for something most companies treat as exhaust: the data inside the operational systems employees use day to day. Its bid, for the data of the now-defunct Spirit Airlines, was not an attempt to capture passenger information or credit-card transactions. It was for operational workflow data. More than 100 million emails, 500 million Teams messages, ERP records, booking curves, pricing systems, code and years of internal decisions. The data companies store for the historical record but rarely structure, and almost never use to inform the next decision.
So why the premium?
Foundation models are weak where operations are hard
Foundation models are surprisingly poor at understanding how decisions get made in real-world operations. They perform well on coding tasks, where Stack Overflow and GitHub provide decades of information with clear lineage: commits, commentary and ratings for every repository. The reasoning behind each change is written down next to the change. Knowledge work does not look like that. Decisions are spread across multiple systems, locked behind enterprise firewalls and unstructured. What lands in a system of record is the data a human decides to enter, not how the work actually got done, and not the considerations weighed before the number went in.
That gap is the whole story. A model trained on the public internet has seen a great deal about how software is written and very little about how a revenue desk decides to hold a fare.
Four systems. One decision.
Take the airline. A flight falls behind its booking curve. A competitor lowers its fare. Fuel costs move. An aircraft becomes unavailable. Crew constraints reduce the options. The revenue team weighs remaining seats, time until departure, ancillary revenue and the effect on the wider network. Then somebody makes a decision.
The booking system records the price. Finance records the revenue. The ERP records the cost. Email and Teams preserve why the forecast was overridden, which alternatives were rejected and who approved the exception. Four systems. One decision. No single system holds the decision itself, only its footprints.
A public model can understand a booking curve. It cannot reconstruct years of company-specific decisions scattered across operational systems, because the connective tissue between those footprints was never written down as data. It lived in the heads of the people who made the calls and in the threads where they argued about them.
What a bigger context window does not fix
The instinct is to solve this with scale. Give the model a larger context window. Point an agent at the raw data lake. Neither works, and the reason is structural rather than a matter of model quality. Language models can only reason over the context they receive. They have no persistent decision memory. Every request starts from zero, so the model has to rediscover the entity, the timeline, the rule and the exception each time, and it will rediscover them slightly differently each time.
You can watch this happen in any inbox-driven operation. The same customer appears under four spellings. The same request arrives as an email, a forwarded thread and a spreadsheet. The instruction that matters is the correction sent an hour after the original. A model reading the raw stream has to get all of that right, from scratch, on every pass. Sometimes it does. The problem is that you cannot tell which times.
The governed layer
Making decision history usable requires a layer that sits between the raw sources and the model. It has five jobs:
- Resolve entities across systems, so the customer in the ERP, the sender of the email and the counterparty on the invoice are one record.
- Assemble events into timelines, so the correction supersedes the original and the approval follows the exception.
- Persist state between actions, so the second step of a workflow knows what the first step concluded.
- Apply rules and approval paths, so the decisions a business has already made once are made the same way again.
- Link decisions to evidence and outcomes, so every result can be traced back to the sources and the logic that produced it.
That layer handles what must be fast, consistent and auditable. The language model receives only the judgement calls. This is the opposite of the common architecture, where the model is asked to do everything and a thin wrapper hopes for the best. It is also what makes the next part possible.
Backtesting agents against the last thousand decisions
Once the state, the rules and the evidence links exist, you can replay history. Take the last thousand decisions the operation made. Give the agent only the information that was available at the time. Then ask the questions that actually matter. Did it identify the constraints? Did it escalate the exception? Did it follow policy? Did it produce a better outcome than the person did? Does it still perform after a prompt change or a model change?
Most companies are deploying agents before building the state, rules and evaluations needed to know whether their decisions are any good. They are measuring the agent by how fluent it sounds rather than by how it would have handled last quarter. The airline data is valuable precisely because it contains the answer key: thousands of decisions, with the constraints that shaped them and the outcomes that followed.
What this means if you run an operation
You already own the asset Google paid for. It is sitting in your inboxes, your chat history and your systems of record, in the same fragmented state Spirit’s was. Three things follow from that. Structure it before you automate over it, because an agent pointed at unstructured history inherits every ambiguity in it. Write the rules down where the software can apply them, because the decisions your experts make consistently are the ones worth encoding. And build the replay before the rollout, because the only honest test of an agent is the decisions it would have made when the answer was already known.
Google was not bidding on old emails. It was bidding on examples of how a complex business made decisions under real-world constraints. Before your agents make the next decision, make them solve the last thousand.