The history of software is not a history of dealing with reality itself. It is a history of first converting reality into “state,” and only then working with it.
A customer became a CRM record. A support request became a ticket. A business process became a workflow. A document became extracted fields. A design became a collection of layers and components. What the user wanted was an answer, a judgment, an artifact. But before software could help, reality had to be translated into a form the software could manipulate.
This state-first model was not a flaw. It was the foundation of modern software. Once state was made explicit, information could be searched, edited, shared, verified, reused, and scaled. To give users a software handle on reality, reality first had to be turned into an operable representation.
Machine learning expanded the reach of this model. Images became labels. Speech became text. Documents became structured data. Behavior became recommendations and scores. Much of the world that previously had to be organized by hand could now be converted by machines into readable state.
But machine learning did not eliminate intermediate representation. It made more of reality convertible into intermediate representation. ML did not end the state-first era. It widened the entrance.
Generative AI takes the next step. It does not merely classify, extract, or summarize messy input. It can read documents, conversations, screenshots, spreadsheets, logs, tickets, product data, and design intent, then directly produce reports, answers, interfaces, analyses, plans, replies, decisions, and simulations.
In other words, a new path is opening: not from reality to state to output, but from reality to result.
This is what I mean by **reality-native software**.
Reality-native software does not ask the user to first construct an intermediate state. It takes the world as given and generates the thing the user actually wanted. If state-first software followed the pattern “reality → intermediate representation → output,” reality-native software moves closer to “reality → result.”
Document processing makes the distinction clear. In the traditional system, documents are OCR’d, fields are extracted, items are classified and normalized, exceptions are validated, workflows are routed, and eventually a report is produced. But the user did not want extracted fields. The user wanted a judgment, a summary, a recommendation, a report. The extracted field was only an intermediate object the software required.
Support works the same way. A customer conversation becomes a ticket. The ticket is tagged and routed. An agent reads account history and policy, then writes a response. But the ticket is not the work. It is a container for the work. If a system can directly read the conversation, contract, product state, and policy, then the center of the experience should not be ticket management. It should be the generation of the answer, the action, or the escalation.
The shift is even deeper in data analysis. A dashboard answers questions someone anticipated in advance: revenue, churn, support volume, conversion rate. When the question is stable, this is powerful.
But real business questions are often investigative. Why did revenue fall in this segment? What caused the spike in support volume? Did the pricing change affect expansion? What happened after launch?
A dashboard is static state. An agentic analyst is dynamic inquiry. It can query the warehouse, open spreadsheets, read support tickets, examine outliers, form hypotheses, test them, and produce a report with evidence. Software no longer merely displays a predefined view. It investigates the question being asked now.
Design tools have the same structure. In a tool like Figma, the user manipulates internal design state: frames, layers, components, variants, constraints, auto layout, styles. The visible interface is a rendering of that state. This is an extremely powerful editing model.
But reality-native design changes the starting point. The user does not begin by constructing an object graph. The user provides product intent, brand, constraints, and examples, and the system generates the interface itself. Editable structure may still exist afterward. But the act of creation begins with intent, not state. The interface can come before the object graph.
Games may be the furthest-reaching example. Traditional games render predesigned world state: maps, meshes, textures, physics, animations, quest flags, dialogue trees, NPC behavior, items, combat rules, save files. The player may experience the world as open, but the world is still bounded by what was modeled, authored, and programmed in advance.
In a generative world model, the world can be produced from prompts, context, and player action as play unfolds. The world no longer has to be fully specified before the player enters it. A traditional game renders a prebuilt world. A generative game creates the world as the player moves through it.
None of this means state disappears. Bank balances, medical records, permissions, contracts, audit logs, infrastructure, multiplayer consistency, and institutional memory still require durable, verifiable shared state. Reality-native software does not deny that.
What changes is the assumption that every useful interaction must begin by constructing intermediate state.
The shift also reaches organizations. Companies distribute work across specialized functions: product, design, engineering, data, legal, finance, marketing, support, operations, QA, security, sales. A team often cannot produce the artifact it wants directly because the required skills, judgments, and systems are spread across other teams.
Agents bring some of that distributed capability back inside the team. Product can prototype before writing a spec. Support can identify product-improvement hypotheses rather than merely file tickets. Marketing can create landing pages and copy without waiting on design and engineering. Data teams can delegate much of the investigative work and focus on higher-order judgment.
In organizational terms, reality-native software shortens the distance from intent to artifact.
In the first era of software, reality had to become explicit application state. In the second, machine learning made more of reality convertible into that state. Now, generative AI is making it possible to generate useful artifacts directly from real-world context.
State-first software made reality programmable by representing it. ML expanded the range of reality that could be represented. Generative AI opens the path from reality to result.
The next paradigm is not better manipulation of state. It is a fundamental shortening of the distance between reality and result.