From Excel to SSOT

Excel’s genius is that it compresses three things into a single cell. Data is the cell’s value; computation is a formula such as =SUM(A1:A10); and the interface that displays the result is the grid itself.

Anyone can “write software” in Excel because they do not need to understand the abstraction layers first. Data, logic and presentation are all visible. Change a value and inspect the result; spot an incorrect formula and edit it directly. Knowing how the business should calculate something also tells you how to build the spreadsheet. That intuition suits an excellent accountant.

This was precisely the accounting manager’s craft. His understanding of the business was inseparable from his tools. Which numbers belonged together, which needed separate treatment, and when a calculation needed checking could all be expressed directly in the sheet, without first becoming a requirements document handed to someone else.

The cost of that elegance is equally clear: a company with a thousand people cannot run on a single sheet. Send the same file to several departments, let each edit it, and collect the copies; merely determining which one is valid becomes another job. Beautiful formulas do not automatically settle who may make changes or who is responsible afterward.

Excel is elegance at a small scale. It shows how direct and close to the business software can be when the whole has not been dismantled. Expanding that scale to an organization introduces another set of problems.

To support a thousand people working together with limited computing resources, division is a natural approach. Divide by business domain, then by technical layer. Make several cuts in each direction and assign every piece to specialists.

Excel’s three-in-one cell is separated into several concerns. Data moves into relational tables with fields, types and relationships defined in a schema. Processes and orchestration move into tools and programs such as triggers, Flow and ABAP. Forms and reports remain in the interaction layer. Products implement this differently, but business users now encounter the result of these layers being reassembled.

The price is the loss of Excel’s immediacy. A business user who wants to change a field must go through IT. What sounds like adding a column requires decisions about where it is stored, who maintains it, which pages display it and whether old reports must change. Documents and processes maintain consistency across layers. When the business changes, underlying data structures may need revision, along with the rules and pages above them.

Each step has a sound justification when considered alone. Not everyone should casually edit production data, and every department should not write its own separate programs. Yet together these reasons make it increasingly difficult for business people to modify their own tools. The person who understands the work best ends up waiting for a scheduled slot.

From ERP to SaaS, enterprise software has grown richer, while the division of labor behind it remains familiar: data structures form the foundation, applications sit on top, then another layer or another system is added until few people can explain the whole.

And the independent craftspeople become fewer and fewer.

At this point, many people assume Palantir arrived with a new paradigm called Ontology. Look closely, however, and it still follows a structure of separation. The Ontology and Action layers discussed today mediate between SSOT and a specific business: facts below, and ways of understanding those facts and acting on them above.

SSOT stands for Single Source of Truth, meaning a commonly accepted source of facts here. Ontology explicitly describes business objects such as customers, orders and vehicles, their relationships, and the actions that can be performed on them.

I see Palantir’s value as the combination of two things: integrating previously scattered capabilities into one product, and using intensive implementation and consulting to make that product usable by both people and AI. For institutions long trapped by complex processes and bureaucracy, having someone turn that tangle of business into a working system is already a breath of fresh air.

① The product layer: reconnect scattered capabilities

Data integration, semantic modeling and business processes all have long histories. Data platforms, the Semantic Web, BPM and DDD have each addressed parts of the problem. The product value of Ontology lies in assembling ideas from different schools and systems into a relatively unified, deployable interface.

When looking at an order, for example, a user can follow relationships to the customer and delivery, and make updates within permitted limits. Data queries, business understanding and action can finally revolve around the same object. Customers no longer need to assemble all those technologies individually.

The return of Ontology to the center also recognizes something long overlooked: software should acknowledge that an organization may interpret the same facts in multiple ways. Finance, sales and operations do different jobs. Building only one form should not force everyone to understand the business in the same way.

Fixing one interpretation in a system is like developing a photograph and hanging it on the wall: to change the angle, you must take another picture. Preserving facts while allowing different interpretations is like keeping the original negative. You can make a new print from another perspective while the old one remains on the wall.

② The execution layer: someone brings the customer’s business into it

Once the product exists, someone still has to understand the customer’s messy business. Which system’s customer record is authoritative? Are two companies with the same name actually the same entity? At what point may an order be canceled? A data table alone cannot answer these questions.

This is the work of FDE teams, or forward-deployed engineers. They work alongside customers to express the business in the Ontology. The product supplies the tools; implementation teams organize the company’s specific rules, exceptions and responsibilities. The on-site implementation work I knew in 2005 has not disappeared simply because the tools are newer.

It is unsurprising to see AI FDEs enter this layer. The product has already prepared a typed, bounded working environment. An agent can face clearly defined Customer, Vehicle and Subscription objects, with documented actions, parameters and permissions. It can write functions, change processes and operate on objects directly in that environment.

What is now often called Harness Engineering means preparing tools, context, constraints and checks around a model. Within an organization, this aspect of Ontology is precisely about preparing the same worksite for people and agents.

Together, the two layers integrate engineering and people: a technical product underneath, and the service that helps customers use it above. A collection of parts is plainly insufficient for a customer trying to solve a real problem.

Following the path of separation, Palantir reorganizes distributed capabilities into a unified interface and brings people and AI together to implement it. That integration is valuable, but I still see it as transitional. How much of the intensive, highly skilled work it requires can agents take on in the future? That is the more interesting question ahead.

Return to Boris’s idea from the beginning: producing and distributing software like sending a text, and creating as freely as in Excel. Let us make an assumption: what happens when agents can assemble datasets, Ontology, business orchestration and interfaces around the task at hand?

The user explains what needs doing; the agent finds relevant data, invokes existing business rules and generates the interface needed now. Several layers that engineering teams previously built separately and then assembled can come together during use. This is the runtime composition meant here.

For example, investigating why a batch of orders was not delivered on time might only require bringing order, inventory and delivery records into one table organized around the current question. Previously, that could become a new reporting project. Under this assumption, it can emerge in one conversation. The page need not become a permanent menu item afterward.

Excel compresses three things into one cell. AI-generated software aims to combine several layers of work in one conversation. The user once again faces a single entry point and has a chance to decide directly how the tool should work.

The curve shows my understanding of software’s separation and integration: Excel integrates within a sheet; enterprise software separates concerns to support organizations; Palantir reconnects them through engineering; AI makes runtime composition possible.

The scale of the return has changed. Excel operates at the scale of a sheet. An agent might operate at the scale of an individual, a temporary task or an organization. The hardest part lies in those last two words: an organization.

Andrej Karpathy describes three generations of software: 1.0 explicitly encodes rules; 2.0 develops capabilities by training neural networks; 3.0 describes intent in natural language within context. We move from writing code for machines, to feeding them data, to explaining what they should do.

Following that line of thought, agents take over part of the role once played by an Excel cell. Values are facts, formulas are methods of calculation, and the grid is what business people use. A conversation similarly tries to let users reach these layers together, without handling each underlying abstraction separately.

But can things really go that smoothly?

On the personal side, experimentation is already easy. Build a tool for yourself with ChatGPT or Claude Code; if it works for you, keep using it. An individual can generate the software they need without waiting for a SaaS company’s schedule.

Inside an organization, things change. Finance, HR and CRM teams all want agents, and all have features they can demonstrate. Yet after the demonstration, who decides the rules and who owns the outcome often remain unresolved. Blaming all this on model capability probably misses the point. A large part of enterprise software is getting people to agree on the business.

Consider a single transaction. Finance determines which amounts are deferred revenue, sales calculates commissions, and operations checks inventory and delivery commitments. All three interpretations can be valid. They refer to the same transaction but answer different questions.

The same data needs different business interpretations across departments, situations, times and even motives. Establishing an Ontology means confirming those meanings as an organization. It must therefore be able to change, and it must be an agreement: people agree that, in this situation, an object is used according to these meanings and rules.

Sales may choose signed contract value to measure performance while finance recognizes revenue based on fulfillment. Both definitions can coexist if their grounds and purposes are clear. The real problem arises when both sides call their result “revenue” without explaining to subsequent users how each number was calculated.

SSOT should help everyone find the shared source of facts: which order, which contract version, whether payment arrived. Those must align. Business interpretations above them may differ. Moving every record into one database does not automatically reconcile the definitions.

The strength of required agreement also varies within a company. Requirements from law, regulation and industry rules can be called hard consensus: AI must follow them and cannot change them through a conversation. Commission methods and workflows agreed between departments are soft consensus: AI may propose changes, but negotiation is required. Temporary calculations and pages for personal use usually need no one else’s approval.

Put the strength of consensus on one axis and data, business meaning and process, and interface layers on the other, and the differences become visible. Personal interfaces can be generated freely; for team rules, agents can calculate and compare proposals before an owner adopts one; formal records must follow established permissions and change procedures.

The broad middle territory of soft consensus is where organizations spend the most effort. Changing commission rules benefits some and disadvantages others. Reassigning customers affects several teams’ performance. An agent can finish the calculations, but has no standing to announce that everyone has agreed.

Software 3.0 will probably enter organizations along a similar gradient. Change is faster where consensus is light; traditional systems and established processes remain useful where it is heavy. When discussing AI implementation, we should examine which layer changes and whom it affects, rather than merely ask whether it can generate an application.

If it becomes simple enough—like sending a text—software may turn from a noun into a verb.

Through conversation, several layers of work combine into an application usable at this moment. The application becomes more like an event: it appears for the problem at hand and may never be opened again afterward. What remains is the set of facts and agreements needed next time.

The form is still uncertain. For now, I call it AI-generated software; it can also be discussed within Karpathy’s Software 3.0. At its core may be a complete, reliable and evolving description of business consensus. Its defensibility, however, will certainly not lie in features.

Redraw the opening Excel diagram for this situation and a critical step appears in the middle: the agent must first establish what these words mean here and now.

Consider a hypothetical client who explicitly opposes war and holds an ESG-managed portfolio containing PLTR. The client asks whether the holding meets their requirements.

The label ESG alone cannot give the agent an answer. It must find the client’s preferences, the portfolio’s management agreement and how that agreement treats the relevant activities. Only if its classification identifies a conflict with the client’s anti-war requirement is there a basis for proposing removal. Another client or portfolio agreement may lead to a different conclusion. This illustrates the alignment of business meaning, rather than assigning a universal label to a stock.

This is soft consensus applied to a specific task at runtime. The client’s phrase “meets my requirements” must be matched to the corresponding agreement before data queries, interfaces and actions can proceed. Whether a recommendation is executed remains a decision for an authorized person under the actual business process.

Models can already create dynamic pages very well. But why the page shows that result, and whose agreement it follows, determines whether it can be used in an organization. The understanding once held in an excellent accountant’s mind and formulas must, at this scale, be discoverable and usable by other people and agents.

Ultimately, a thought replaces a cell, as simply as sending a text.