The Third Restructuring of Software Form: From the Three-Tier Architecture to Storage, Models, and Agents

# The Third Restructuring of Software Form: From the Three-Tier Architecture to Storage, Models, and Agents
Source: [https://arxiv.org/html/2608.20201](https://arxiv.org/html/2608.20201)
Wei Lin1, Tao Zhou1, Zhaofei Xie1, Changgui Hong1Affiliation:1Nanjing Liancheng Intelligent Technology Group, Nanjing, China Email: \{linwei, zhoutao, xiezhaofei, hongchanggui\}@chinaliancheng\.com

###### Abstract

Software form has undergone two paradigm shifts since its inception: Software 1\.0, in which instructions determine behavior, and Software 2\.0, in which data determines behavior \(machine learning\)\. This paper argues that a third shift—Software 3\.0, in which context and reasoning determine behavior—is now underway, and contends that its terminal form converges to three elements: a*generalized database*\(the unified abstraction of all persistent state and memory\), a*large model*\(the intelligence core that performs reasoning and generation\), and an*agent*\(the execution loop connecting the first two\)\. The core argument is as follows: in the traditional three\-tier architecture, the user\-interface layer will be absorbed by the model’s ability to generate interfaces on demand, the business\-logic layer will be re\-partitioned along “expressibility×\\timescriticality” into model reasoning and storage constraints \(with residual deterministic logic retained as tools\), and only the data layer will be elevated into the sole persistent infrastructure\. We formalize this convergence thesis, present a minimal reference architecture, report evidence from real prototypes and a live model, and systematically analyze both the conditions under which it holds and the boundaries where it fails—determinism, cost, security, and verifiability delimit the thesis’s domain of applicability\. We argue that the thesis holds in task domains that are expressible, verifiable, externally stateful, and tool\-complete, and that it will reshape the roles of developers, the database industry, and the software\-engineering discipline\.

###### Index Terms:

software form, large language models, agents, database, Software 3\.0, LLM OS, agentic computing

## IIntroduction

Software is the medium by which humans prescribe machine behavior, and its form has never been constant: it restructures itself whenever the cost of expressing behavior drops\. Marc Andreessen’s claim that “software is eating the world” presupposes that software is cheap enough to build and easy enough to reuse\[[1](https://arxiv.org/html/2608.20201#bib.bib1)\]\. When large language models \(LLMs\) reduce the cost of translating natural language into executable behavior to an unprecedented low, the*form of software itself*ceases to be a given and becomes a variable worth re\-examining\.

This paper pursues a question that appears radical yet already shows abundant signs:*if interfaces can be generated instantaneously by a model, and business rules can be reasoned about instantaneously by a model, what remains of traditional software?*Our answer: only three things remain—state \(storage\), intelligence \(model\), and execution \(agent\)\.

This thesis does not arise from a vacuum; it surfaces simultaneously across several independent research strands\. Andrej Karpathy’s “LLM OS” casts the large model as a kernel and the database as a file system\[[2](https://arxiv.org/html/2608.20201#bib.bib2),[3](https://arxiv.org/html/2608.20201#bib.bib3)\]\. Work such as DBOS argues for making the database, rather than the operating system, the foundation of distributed applications\[[4](https://arxiv.org/html/2608.20201#bib.bib4)\]\. Agent research—ReAct, Toolformer, AutoGPT, Voyager—demonstrates that models can autonomously complete multi\-step tasks through think–act–observe loops\[[5](https://arxiv.org/html/2608.20201#bib.bib5),[6](https://arxiv.org/html/2608.20201#bib.bib6),[7](https://arxiv.org/html/2608.20201#bib.bib7),[8](https://arxiv.org/html/2608.20201#bib.bib8)\]\. Work on retrieval\-augmented generation \(RAG\) and MemGPT shows that external storage and memory are the key to transcending the context window and acquiring long\-term state\[[9](https://arxiv.org/html/2608.20201#bib.bib9),[10](https://arxiv.org/html/2608.20201#bib.bib10)\]\. These strands are independent, yet they point toward the same convergence\.

Our contributions are as follows:

- •Thesis formalization: we elevate “software = storage \+ model \+ agent” from a slogan to a discussable, testable proposition, with precise boundaries and relations among the three elements \(Section[III](https://arxiv.org/html/2608.20201#S3)\)\.
- •Collapse mechanism: we systematically argue why each layer of the three\-tier architecture is either absorbed or elevated \(Section[IV](https://arxiv.org/html/2608.20201#S4)\)\.
- •Minimal reference architecture: we give an end\-to\-end architecture showing how the three elements compose into a complete, working software system \(Section[V](https://arxiv.org/html/2608.20201#S5)\)\.
- •Boundary analysis: we state the conditions under which the thesis holds and the counterexamples where it fails, so the vision does not degenerate into a slogan \(Sections[VI](https://arxiv.org/html/2608.20201#S6)–[VII](https://arxiv.org/html/2608.20201#S7)\)\.
- •Implications: we discuss what the thesis means for developers, the database industry, the software\-engineering discipline, and governance \(Section[VIII](https://arxiv.org/html/2608.20201#S8)\)\.

## IIBackground and Related Work

This section reviews the four strands that support the thesis and locates our contribution relative to them\.

### II\-A“Software 2\.0” and “Software 3\.0”

In 2017, Karpathy introduced “Software 2\.0”: software behavior is no longer specified by explicit code but is implicit in neural\-network weights trained on data\[[2](https://arxiv.org/html/2608.20201#bib.bib2)\]\. This insight captures the first shift, from “program\-specified behavior” to “data\-determined behavior\.” Along the same logic, the community has begun to sketch “Software 3\.0”: a further decision factor—*context and reasoning*—is layered on top of Software 2\.0; a model is no longer a static, trained function but a system that dynamically decides behavior at runtime based on prompts, tool feedback, and external memory\. Our thesis can be read as the most radical version of Software 3\.0: once context and reasoning dominate behavior, the only durable part of software is storage\.

### II\-BThe LLM Operating System

Since the Transformer architecture\[[11](https://arxiv.org/html/2608.20201#bib.bib11)\]and GPT\-style scaled pretraining\[[12](https://arxiv.org/html/2608.20201#bib.bib12)\]established large models as general intelligence cores, Karpathy’s 2023 “LLM OS” analogy casts the large model as the kernel \(CPU/RAM\), external tools as peripherals \(I/O\), and the database/file system as persistent storage\[[3](https://arxiv.org/html/2608.20201#bib.bib3)\]\. The analogy is evocative but remains metaphorical\. This paper asks the follow\-up question: if the metaphor is taken literally, what is the*minimal*composition of a system with a model as its core and storage as its foundation? Our answer: storage, model, and agent together suffice to close the loop\.

### II\-CAgents and Tool Use

The breakthrough that lets models “not only speak but also act” comes from two lines of work\. The first couples reasoning with action: building on the step\-by\-step reasoning capability established by chain\-of\-thought prompting\[[13](https://arxiv.org/html/2608.20201#bib.bib13)\], ReAct proposes an interleaved think–act–observe paradigm in which a model invokes external tools during reasoning and learns from feedback\[[5](https://arxiv.org/html/2608.20201#bib.bib5)\], and Toolformer shows that models can learn to call APIs through self\-supervised learning\[[6](https://arxiv.org/html/2608.20201#bib.bib6)\]\. The second closes the autonomous task loop: AutoGPT/BabyAGI demonstrate an automatic goal–plan–execute cycle\[[7](https://arxiv.org/html/2608.20201#bib.bib7)\], and Voyager goes further by letting an agent accumulate reusable capabilities through a skill library in Minecraft\[[8](https://arxiv.org/html/2608.20201#bib.bib8)\]\. Together these works establish the agent as an independent*execution loop*—neither the model itself, nor hand\-written glue code, but the institutional carrier of the plan–memory–tool\-use dynamics\.

### II\-DThe Convergence of Databases and AI

A fourth independent strand is the convergence of databases and AI\. On the query side, text\-to\-SQL translates natural language into structured queries, sharply lowering the barrier to data access\. On the storage side, vector databases make semantic similarity a first\-class capability that directly serves RAG\[[9](https://arxiv.org/html/2608.20201#bib.bib9)\]\. On the memory side, MemGPT proposes a hierarchical memory architecture that lets a model manage context the way an operating system manages memory, with an external database serving as the model’s “long\-term memory”\[[10](https://arxiv.org/html/2608.20201#bib.bib10)\]\. DBOS approaches the same destination from the opposite direction, arguing that the database—not the OS—should be the foundation of distributed applications, with transactions, scheduling, and logging all provided as database primitives\[[4](https://arxiv.org/html/2608.20201#bib.bib4)\]\. The shared implication of this strand is that*the database is being elevated from a passive storage appendage into an active infrastructure*\.

### II\-EGaps in Prior Work and Our Positioning

These strands each make progress, but share a common blind spot: they study “how a model becomes the kernel,” “how an agent becomes the execution loop,” and “how a database becomes the foundation”*separately*, yet few works unify all three into a single convergence thesis at the*macro level of software form*, and answer the question “what gets replaced, what does not, and under what conditions\.” This paper fills that gap with an integrated treatment of the thesis, its argument, an architecture, and its boundaries\.

Software 2\.0 / 3\.0LLM OSAgents & Tool UseDatabase×\\timesAILarge ModelAgentGeneralized DatabaseFig\. 1:Convergence of four independent research strands onto the three elements; each strand contributes to one or more elements, jointly pointing toward the storage–model–agent convergence\.
### II\-FA Skeptical View and Our Response

A substantial body of work cautions against overstating LLM capability\. Surveys of code hallucination document that models generate plausible but incorrect outputs with no correctness guarantee\[[14](https://arxiv.org/html/2608.20201#bib.bib14)\], and empirical studies of industry needs report that reliability and explainability remain the top concerns that current academic approaches fail to address\[[15](https://arxiv.org/html/2608.20201#bib.bib15)\]\. These findings are often read as evidence against agentic software\.

This paper does not dispute them; rather, the convergence thesis is built to be*compatible*with them\. We do not claim the model is reliable—we claim the model should not have to be\. By confining the model to the expressible, non\-critical tier and guaranteeing the critical tier through deterministic storage constraints \(Section[IV\-B](https://arxiv.org/html/2608.20201#S4.SS2)\), the thesis limits the damage of hallucination to the region where verification can catch it \(Section[VII](https://arxiv.org/html/2608.20201#S7)\)\. The skeptical view therefore strengthens, rather than weakens, the central role the thesis assigns to the storage layer\.

## IIIFormalizing the Thesis

### III\-AStatement

Let a software systemSSbe the composition of the three traditional tiers:

whereUUis the user\-interface layer,LLis the business\-logic layer, andDDis the data layer\. Our central thesis is:

Convergence Thesis: within the task domain satisfying the conditions of Section[VI](https://arxiv.org/html/2608.20201#S6),UUis absorbed by the model’s on\-demand generation,LLis absorbed by the model’s reasoning and tool use, and the software form converges to:

S′=\(𝒟,ℳ,𝒜\)S^\{\\prime\}=\(\\mathcal\{D\},\\mathcal\{M\},\\mathcal\{A\}\)\(2\)where𝒟\\mathcal\{D\}is the*generalized database*—the unified storage abstraction of all persistent state, constraints, memory, and knowledge \(a single semantic layer over heterogeneous relational, vector, graph, key\-value, and object stores\);ℳ\\mathcal\{M\}is the*large model*—the intelligence core carrying understanding, reasoning, generation, and decision\-making; and𝒜\\mathcal\{A\}is the*agent*—an execution loop structured as plan–memory–tool\-use, acting as the dynamic connector between model and storage\.

### III\-BPrecise Definitions of the Three Elements

To keep the thesis from degenerating into a slogan, we define the three concepts precisely:

1. 1\.The generalized databaseis not a single database product, but a unified abstraction of the*functional role*of “persistent state\.” It encompasses structured relational data, semi\-structured documents, unstructured vectors and objects, together with the constraints \(schemas, integrity rules, permissions\) and version history that describe them\. Its defining property is that it is the*only*part of the system possessing persistence, auditability, and transactionality\.
2. 2\.The large modelis the carrier of the functional role of “intelligence\.” We presuppose no specific model, but require two indispensable capabilities:*reasoning*\(making decisions under a given context\) and*generation*\(translating decisions into executable actions or interfaces\)\.
3. 3\.The agentis the carrier of the functional role of “execution loop\.” Its essence is a*closed loop*: perceive context→\\rightarrowplan→\\rightarrowinvoke tools \(read/write𝒟\\mathcal\{D\}\)→\\rightarrowobserve results→\\rightarrowupdate memory→\\rightarrowcontinue\. The agent stitches the stateless reasoning of the model and the stateful storage together into a whole that keeps working over time\.

The relation among the three can be summarized as:*storage is the software’s “past” \(memory and state\), the model is its “present” \(reasoning and decision\), and the agent is its “future” \(advancing past and present into the next moment\)\.*

## IVArgument: Why the Three\-Tier Architecture Collapses

This section argues, layer by layer, why each tier is absorbed or elevated\.

### IV\-AThe UI Layer Dissolves: Interfaces Generated on Demand

The traditional UI layer exists to present business capability in a human\-perceivable form\. But a UI is, at bottom, a translation from state to presentation\. When a model can perform this translation reliably, statically pre\-built interfaces are no longer a necessity—an interface can be generated at each interaction from thecurrent state, user intent, and device context\. This trend is already visible in “generative UI” and “chat\-as\-interface\.”

But “dissolution” must be qualified precisely, lest we repeat the mistake of treating reliability as a free premise\. A UI is not monolithic; it splits into two layers: adeterministic projection layerand agenerative decoration layer\. The former carries information that “must be presented correctly”—account balances, contract amounts, compliance disclosures, medical warnings, accessibility semantics—whose probabilistic mis\-generation constitutes a substantive safety/compliance failure, not a cosmetic blemish; it must be obtained as a*deterministic projection*of stored state \(state\-driven UI\)\. The latter—layout, wording, interaction rhythm, and other “expressible and non\-critical” presentation—may be delegated to on\-demand generation by the model\.

In other words, the UI layer’s dissolution obeys the*same law*as the business\-logic layer’s differentiation: the expressible and non\-critical part goes to the model, and the must\-be\-correct part anchors on storage\. The UI layer therefore does not vanish; it is restructured from “a pre\-hard\-coded whole” into “a deterministic projection of storage plus a generative decoration by the model\.” This restructuring also exposes the traditional usability costs of a UI—consistent mental models, branding, accessibility—which belong to the part the deterministic projection layer must retain, not the latitude of the generative layer\.

### IV\-BThe Business\-Logic Layer Dissolves: Reasoning and Tool Use Replace Hard\-Coded Rules

The business\-logic layer \(LL\) is the most expensive and the most perishable part of software: it consists of large amounts of branching, rules, and glue code, and it corrodes as requirements drift\. When a model can reason about business rules from context and trigger side effects through tool calls,LLis re\-partitioned—*not into a clean dichotomy*, but along the two axes of “expressibility×\\timescriticality” into three kinds:

1. 1\.Expressible and non\-critical: rules that can be clearly stated in language and whose errors are tolerable, absorbed by the model’s reasoning;
2. 2\.Critical but declaratively expressible: rules that map onto deterministic primitives such as uniqueness, foreign keys, CHECK constraints, triggers, and transactions, sunk into storage constraints on𝒟\\mathcal\{D\};
3. 3\.Critical yet not declaratively expressible: multi\-step cross\-system orchestration with external calls, temporal dependencies, and intricate exception branches—these exceed the expressive ceiling of declarative constraints and cannot be carried cleanly; this part*does not vanish*, but survives as verified, deterministic code exposed to the agent as controlled tools\.

In short,*business logic does not undergo a clean “polarization”: it differentiates into three kinds, the third of which constitutes a crucial correction to the thesis’s most naive reading*—not all logic can be absorbed by model or constraints, and the thesis’s scope is precisely delimited by how small this third kind can be made\. Table[I](https://arxiv.org/html/2608.20201#S4.T1)grounds the three kinds in a concrete domain—intelligent production scheduling \(APS\)—which we carry through Section[V](https://arxiv.org/html/2608.20201#S5)\.

TABLE I:The three\-way differentiation of business logic, instantiated with rules from an intelligent production\-scheduling \(APS\) system\.
### IV\-CThe Data Layer Rises: The Generalized Database Becomes the Sole Persistent State

OnceUUandLLretreat,DDbecomes the only surviving durable layer—and its status rises, not falls\. Three reasons\. First, model reasoning is*stateless*; long\-term state must be externalized, and the database is the only reliable carrier\. Second, the model’s capability boundary is precisely determined by “what state it can see,” so the database becomes the ceiling of the model’s ability\. Third, under hard requirements of auditability, rollback, and transactionality, only the database can provide deterministic guarantees\[[16](https://arxiv.org/html/2608.20201#bib.bib16)\]\. The data layer thus rises from “an appendage dominated by the logic layer” to “the foundation of the entire system”—mutually reinforcing DBOS’s “database\-as\-foundation” argument\[[4](https://arxiv.org/html/2608.20201#bib.bib4)\]\.

### IV\-DThe Agent: The Execution Loop Connecting Model and Storage

WithUUandLLgone andDDelevated to the foundation, the system still needs a mechanism that connects the stateless model to stateful storage so that software can*keep working*rather than merely answer once\. That is the agent’s role,𝒜\\mathcal\{A\}\. The agent is not a new layer conjured from nothing; it is the institutionalization of the plan–memory–tool\-use loop\. It decides what state to read next, which tool to call, what result to write back, and what to remember\. In this sense,the agent replaces precisely the “main loop” that was frozen into the control flow of traditional software\.

In summary, the collapse of the three\-tier architecture can be expressed in one sentence:*the UI regresses into a model output, the logic differentiates into model reasoning, storage constraints, and residual deterministic tools, the control flow is reconstructed as the agent’s loop, and only the state survives—and is elevated\.*Table[II](https://arxiv.org/html/2608.20201#S4.T2)summarizes the mapping\.

TABLE II:From the three\-tier architecture to three elements\.

## VA Reference Architecture: A Minimal Storage–Model–Agent System

This section gives the thesis a concrete landing form, showing how the three elements compose into a complete, working system\.

### V\-AOverall Architecture

Agent Layer \(Execution Loop\)Model LayerStorage LayerPlannerMemoryToolDispatcherLarge LanguageModelRelationalVectorGraphObject/KVConstraints / HistoryExternalWorldretrieveread / writeFig\. 2:A minimal reference architecture for a storage–model–agent system: a stateless model core, an agent execution loop, a heterogeneous generalized database, and the external world reached only through tools\.
### V\-BStorage Layer: Unified Semantics over Heterogeneous Stores

The storage layer is not “one database,” but a unified abstraction over heterogeneous relational, vector, graph, and object stores—continuing the “one\-size\-fits\-all no longer applies” line of specialized engines\[[17](https://arxiv.org/html/2608.20201#bib.bib17)\]—augmented with two kinds of semantics: \(1\)constraints—the parts of business logic that “must be correct” are sunk into deterministic storage\-level constraints \(uniqueness, foreign keys, transactions, stored procedures, triggers\), guaranteed by the database engine rather than the model; and \(2\)version and history—the full evolution trace of state is preserved for auditing, rollback, and verifiability, the source of reliability and interpretability for long\-running agents\.

### V\-CModel Layer: A Stateless Intelligence Core

The model layer does three things: it parses user intent and context into aplan; it decomposes the plan intoexecutable actions; and it synthesizes raw tool results into auser\-comprehensible presentation\. The model itself remains stateless—all long\-term state is hosted in the storage layer\. This “stateless core \+ stateful external memory” division is a continuation, in a new era, of the classical database/stateless\-service layering\.

### V\-DAgent Layer: Plan–Memory–Tool

The agent layer consists of three cooperating modules: thePlanner, which decomposes a goal into steps, decides which tools to call and in what order, and revises the plan dynamically based on feedback; theMemory, which maintains short\-term context and long\-term memory \(persistent knowledge written into the storage layer\), transcending the model’s context\-window limit\[[10](https://arxiv.org/html/2608.20201#bib.bib10)\]; and theTool Dispatcher, which executes reads/writes to the storage layer and calls to the external world in a controlled manner—the sole exit through which the agent produces side effects\.

### V\-EA Proof\-of\-Concept: Intelligent Production Scheduling

We ground the architecture in an intelligent production\-scheduling \(APS\) scenario—a long\-lived, constraint\-rich domain where the convergence thesis applies most directly\. A conventional APS is a monolithic application coupling a scheduling interface, hard\-coded dispatching rules, and a relational database\. In the converged form it reduces to three elements\.

Storage layer\.Orders, operations, machines, and material inventories are persisted as state, together with the declarative constraints that must never be violated: one machine executes one operation at a time \(an exclusion constraint\), an operation starts only after all its predecessors finish \(a precedence constraint\), and a schedule must respect machine capacity and material availability \(integrity constraints\)\. These are enforced by the database engine, not by the model\.

Model layer\.The model interprets natural\-language requests—“re\-schedule shop floor A around the urgent order \#2047,” or “why is order \#1881 slipping?”—into a plan over the available tools, and renders the returned schedule and its rationale back into prose\.

Agent layer\.For a re\-scheduling request, the Planner decomposes the goal into steps: read the affected orders and current assignments from the storage layer, invoke the*solver tool*\(a deterministic constraint/optimization routine, e\.g\., a CP\-SAT solver\) to compute a new feasible schedule under the stored constraints, write the resulting assignment back, and update Memory with the incident context\. The Tool Dispatcher is the sole channel through which the solver and the shop\-floor systems are invoked\.

The three\-way split of Section[IV\-B](https://arxiv.org/html/2608.20201#S4.SS2)is visible end to end: the expressible, non\-critical parts—diagnosing a delay or summarizing a plan—are model reasoning; the critical, declaratively expressible parts—mutual exclusion, precedence, capacity—are storage constraints; and the critical, non\-declarative part—the combinatorial search for a schedule minimizing tardiness—remains a deterministic tool\. A query such as “why is order \#1881 late?” is answered entirely by reading state and reasoning over the stored precedence and capacity facts; a request to re\-schedule is executed by the agent loop while the storage layer guarantees the result remains feasible\.

### V\-FPreliminary Evidence from a Minimal Prototype

To make the storage layer’s role concrete, we implemented a minimal prototype in Python and SQLite: a job shop of 10 machines and 200 unit\-time operations \(four precedence chains per machine\), in which machine exclusion is aUNIQUE\(machine, slot\)constraint and precedence is aBEFORE INSERTtrigger that raises on violation\. The planner is a deliberately noisy scheduler that perturbs a fractionε\\varepsilonof its assignments to random machine–slot pairs, standing in for an imperfect model\.

Table[III](https://arxiv.org/html/2608.20201#S5.T3)reports the result\. Regardless of the planner’s error rate—up to 30% of assignments perturbed—the persisted schedule remains feasible, because the storage constraints reject every violating proposal \(16, 33, and 45 rejections atε=0\.1\\varepsilon=0\.1,0\.20\.2, and0\.30\.3, respectively\)\. Enforcement costs about 1\.1 ms per 200 operations in SQLite\. The prototype is intentionally minimal—the “model” is simulated—but it demonstrates the thesis’s central mechanism:*correctness is guaranteed by the storage layer, independent of upstream reasoning quality*\.

TABLE III:Storage\-as\-arbiter: the persisted schedule stays feasible regardless of the planner’s error rateε\\varepsilon\.The second experiment replaces the placeholder with a production solver\. We model the combinatorial objective—minimizing makespan in a job shop, the kind of rule that is critical but not declaratively expressible—with OR\-Tools CP\-SAT, and run it on reproducible synthetic job\-shop instances \(fixed seeds\)\. Table[IV](https://arxiv.org/html/2608.20201#S5.T4)reports solve time and makespan\. The objective is solved to optimality in well under a second for most instances, but one hard12×1212\\times 12instance takes9\.679\.67s—illustrating that this tier carries real, variable computational cost, and is therefore correctly isolated as a residual tool rather than fused into model reasoning or storage constraints\.

TABLE IV:The residual tool \(OR\-Tools CP\-SAT\) on reproducible synthetic job\-shop instances\.
### V\-GA Live Model: The Storage Layer Catches Real Hallucinations

The preceding experiments simulated the model\. To test the arbiter against a*real*model, we asked a live LLM \(Qwen\-Plus, via a production API\) to schedule the three\-job, three\-machine instance of Table[V](https://arxiv.org/html/2608.20201#S5.T5)directly, without a solver tool, in twenty independent trials\. The model returned well\-formed schedules every time, yet*zero*of them were feasible: all twenty violated machine exclusion, and eighteen also violated precedence, with apparent makespans of77–1010\(mean8\.98\.9\) that are meaningless precisely because they ignore machine contention—the true optimum is99\. The storage layer rejected all twenty violating schedules, a 100% catch rate, so the persisted state remained feasible throughout\. This is the thesis’s central mechanism at work:*the model need not be reliable, because correctness is enforced by the storage layer\.*

TABLE V:A live model \(Qwen\-Plus\) scheduling a3×33\\times 3job shop directly: 0% feasible, 100% caught by storage constraints\.The contrast with a tool\-using agent completes the picture\. When the same model is instructed to delegate to the deterministic solver tool rather than reason directly, it requests the tool in all ten trials and reports the correct makespan \(99\) and feasibility every time \(Table[VI](https://arxiv.org/html/2608.20201#S5.T6)\)\. The two experiments together show that the model’s 0% feasibility is not a limitation of the model per se, but of entrusting combinatorial correctness to reasoning: correctness comes from*delegating to the deterministic tool*and is*enforced by the storage layer*, exactly as the thesis’s three\-way split prescribes\.

TABLE VI:Tool\-using agent \(Qwen\-Plus, 10 trials\): 100% correct via delegation to the solver tool\.
### V\-HHand\-Written vs\. Declarative Enforcement

The three\-way split places the critical, declarative rules in the storage layer\. To justify that placement, we compare two ways of expressing the same three scheduling constraints \(machine exclusion, precedence, capacity\): hand\-written checks inline in application code, versus declarative constraints in the storage layer\. The enforcement code is comparable in size, but the difference appears under fault injection: when a single check—the capacity rule—is forgotten in the hand\-written version, over\-capacity schedules*leak through*\(Table[VII](https://arxiv.org/html/2608.20201#S5.T7)\); the same rule declared as a storage constraint is enforced regardless of what the application code does\. This is not a claim that declarative constraints are novel—databases have long provided them—but that their role becomes*critical*when the upstream logic is an unreliable model \(Section[V\-G](https://arxiv.org/html/2608.20201#S5.SS7)\) rather than careful human code: centralized, unavoidable enforcement is the safety net that makes the converged form trustworthy\.

TABLE VII:Fault injection: a single forgotten check leaks in hand\-written code; declarative storage constraints always enforce\.

## VIConditions for the Thesis to Hold

The thesis does not hold unconditionally\. This section states four necessary conditions; in task domains that fail them, the thesis’s applicability sharply weakens \(Section[VII](https://arxiv.org/html/2608.20201#S7)\)\.

### VI\-AExpressibility and Verifiability of the Task

The model’s capability boundary is determined by two properties: whether the task can beclearly expressed in language\(otherwise the model cannot reason about it\), and whether the result can beobjectively verified\(otherwise the model’s errors cannot be detected and corrected\)\. When a task is both expressible and verifiable, model reasoning plus verification feedback forms a reliable feedback loop; otherwise the task reverts to traditional implementation\. This condition directly echoes Sutton’s “bitter lesson”—whatever can be solved by computation and data will eventually be solved by general methods\[[18](https://arxiv.org/html/2608.20201#bib.bib18)\]\.

### VI\-BExternalization of State

The thesis requires that all long\-term state beexternalizedinto the storage layer\. If the task’s state is naturally embedded in the model \(a one\-shot, side\-effect\-free question answering\), the storage\-plus\-agent loop is meaningless; only when software must maintain stateacross time, sessions, and subjectsdoes the elevation of the storage layer make sense\. The thesis therefore applies tostateful, long\-livedsoftware, not stateless one\-off computation\.

### VI\-CCompleteness of the Tool Boundary

An agent can act on the world only through tools\. The thesis therefore presupposes that the side effects required by the domain \(reading/writing external systems, operating devices, calling services\) can all be exposed to the agent ascontrolled toolswith clear permission boundaries\. But this condition contains an inherent dilemma:

1. 1\.Completeness and closedness cannot both hold\.If the toolset is written down in advance, it is safe but incomplete—any unforeseen side effect becomes inexpressible, and the thesis reverts to “still hand\-writing code\.” If the toolset is open \(letting the agent bootstrap new tools, as in Voyager’s skill library\[[8](https://arxiv.org/html/2608.20201#bib.bib8)\]\), it is complete but unbounded—“completeness” degenerates into unlimited trust in the model’s self\-bootstrapping, which is no condition at all\.
2. 2\.A single tool’s permission boundary cannot express multi\-step composed side effects\.Even when every tool is individually well\-scoped, the workflow\-level side effects produced by an agent*composing*multiple tools exceed the expressive power of a per\-tool permission model—just as individually safe queries can jointly infer private information through their sequence\.

Together these yield a constructive corollary: since authorization cannot be fully closed at the individual\-tool level,the final enforcement point of authorization can only be the storage layer—where every state change converges and can be constrained and audited \(cf\. Section[VIII\-D](https://arxiv.org/html/2608.20201#S8.SS4)\)\. The tool boundary is thus not a premise satisfiable once and for all, but an engineering constraint that the storage layer must continuously backstop\.

### VI\-DEconomic Threshold

Even if the first three conditions hold, the thesis’s realization depends oneconomics\. But the comparison needs clarifying: what actually faces off is not “the latency/cost of one inference” versus “one execution of compiled logic”—these aredifferently structured costs\. The cost of hand\-writingUUandLLis dominated bydevelopment and maintenance\(labor and requirement drift\), with near\-zero marginal runtime cost; the cost of the storage–model–agent form is dominated bymarginal runtime cost\(per\-inference latency and billing\), while its development and maintenance cost declines as model capability improves\.

The true dividing line is therefore not “call frequency” but thevalue density of a decision—the ratio of the cost of a single inference to the value of the decision it produces\. For low\-value, high\-concurrency decisions \(each request worth a fraction of a cent\), inference cost dominates and hand\-written logic is more economical; for high\-value, low\-concurrency decisions \(a single approval that averts a million\-dollar loss\), inference cost is a rounding error and the model form dominates\. This boundary is alsodynamic and engineerable: inference cost declines over the long run while maintenance cost does not, and caching, distillation, small models, and batching further compress runtime cost\. “Core high\-frequency transactions” is thus only a static snapshot; the true economic boundary is moving, over time, in the thesis’s favor\.

### VI\-ENon\-Triviality of the Thesis

The conditions above may invite a criticism: if the thesis holds only in the domain where model reasoning and storage constraints happen to work, is it nearly tautological? We argue not, for two reasons\. First, the conditions are not vacuous relaxations but arejointly satisfiable by a real, identifiable, and continuously expanding class of software—long\-tail, natural\-language\-interfaced, stateful business workflows; Sutton’s “bitter lesson” implies that, as model capability grows, this class only expands\[[18](https://arxiv.org/html/2608.20201#bib.bib18)\]\. Second, the thesis’s substance is not the truism that “models perform well in their home domain,” but a falsifiablearchitectural claim: after the collapse of traditional software, the only remaining durable artifact is*exactly*storage—not “storage plus a thin layer of business logic\.” It is this “exactly” that gives the thesis predictive content against future evidence, rather than rendering it a tautology\.

## VIICounterexamples and Boundaries: When the Thesis Fails

The greatest danger of a vision paper is overpromising\. This section enumerates four boundary classes where the thesis fails, and how they delimit its domain\.

### VII\-ADeterminism and Correctness

Relational databases have endured because they offer the deterministic guarantees oftransactions, types, and constraints\(ACID\)\. Model reasoning is fundamentally a*probabilistic*computation and cannot promise the same guarantees\. For scenarios where errors are unacceptable—funds settlement, aerospace, medical dosing—business logic must be guaranteed by formally verifiable code or database constraints, not by model reasoning\. This boundary means the thesis does not apply tostrongly deterministic, formally verifiedcore tasks; in such tasksLLdoes not vanish, but merely sinks into storage constraints or verified code\.

### VII\-BPerformance, Latency, and Cost

Model inference latency \(seconds\) and cost \(per\-call billing\) far exceed the direct execution of compiled logic \(nanoseconds, nearly free\)\. Inhigh\-frequency, low\-latency, large\-scalescenarios \(trade matching, real\-time recommendation, network forwarding\), freezing logic into dedicated implementations remains the only choice\. In these scenarios the thesis fails, or degrades to a compromise where “the model only generates code, but does not reason at runtime\.”

### VII\-CSecurity, Permissions, and Compliance

Handing execution authority to an agent that “decides its next move by reasoning” opens a new attack surface and new compliance risks: prompt injection can hijack the agent’s decisions; an ill\-designed tool\-permission boundary becomes a channel for privilege escalation \(the composed\-side\-effect problem of Section[VI\-C](https://arxiv.org/html/2608.20201#S6.SS3)\); and regulation \(in finance and healthcare, for instance\) often requires behavior to bepredictable, auditable, and attributable, which conflicts with the opacity of model reasoning\.

The hardest of these is theattribution problem, whose depth exceeds what “adding audit logs” can resolve: attribution demands an answer to “who is responsible for a wrong decision,” yet an agent’s decision is an*emergent*result of model reasoning, stored state, and historical tool feedback, with no single accountable subject to point to\. Audit logs can tell us*what happened*, not*who is to blame*\. Nor is “human\-in\-the\-loop” an easy fallback: theresponsibility paradoxis that the model amplifies the capacity to act while the human’s capacity to understand and to bear responsibility does not scale in kind—the human can neither grasp the model’s full decision trace nor vouch for every action at scale\.

This problem, in turn, reinforces one of the thesis’s conclusions: since attribution must anchor on somethingdeterministic and auditable, its only anchor can be the storage layer—who committed what state, when, and which constraint was violated; the model and the agent are not accountable, and the storage layer is the ultimate carrier of accountability\. But this also exposes astructural gapin strongly regulated domains: the pure converged form leaves storage as the*only*deterministic anchor, and the “human” component is absent\. In such domains the thesis must therefore degrade to “storage constraints \+ human\-in\-the\-loop”—and how an unintelligible, hard\-to\-scale “human” is to backstop a superlinearly growing agent is a question the thesis has not answered\.

### VII\-DVerifiability and Hallucination

Model hallucination means its output may be*superficially plausible yet factually wrong*\[[14](https://arxiv.org/html/2608.20201#bib.bib14)\]\. When a task’s result cannot be objectively verified, hallucination cannot be detected, and the thesis’s feedback loop collapses\. This again echoes Section[VI\-A](https://arxiv.org/html/2608.20201#S6.SS1): verifiability is the thesis’s lifeline\. A notable corollary:in the converged form, the database plays the role of an “arbiter of consistency” rather than an “arbiter of fact”—any model output that conflicts with already\-stored state can be vetoed by the storage layer \(a consistency constraint\); but the database cannot adjudicate*fabricated novel facts*that conflict with nothing already stored \(e\.g\., inventing an entity that does not exist in the database\), because such hallucinations violate no existing constraint\. Correctness assurance for novel outputs must therefore come from external oracles, cross\-checks, or humans\-in\-the\-loop; the storage layer can only confine hallucination’s harm to the “expressible but not yet persisted” segment\.

### VII\-ESoftware Categories That Will Not Be Replaced

Synthesizing the above boundaries, we can state precisely which software the thesis will not replace—which, counterintuitively, strengthens the thesis’s credibility:

TABLE VIII:Software categories not replaced by the convergence thesis, and the thesis’s applicable form for each\.

## VIIIDiscussion: Implications for Industry, Developers, and Governance

If the thesis holds within its domain, it carries several far\-reaching implications\.

### VIII\-AFor Developers: From “Writing Code” to “Defining State and Constraints”

The developer’s core work shifts from “writing control\-flow code that implements a specific behavior” to“defining the state model, designing constraints, encapsulating tools, and debugging the agent’s behavior\.”This is not “the disappearance of programmers” but an*upward shift*of the center of programming: from specifying “how to do it” line by line, to precisely describing “what is correct and what is forbidden\.” This shift is already foreshadowed by “vibe coding,” but its mature form isconstraint\-driven development—developers invest effort in verifiable constraints rather than perishable glue logic\[[19](https://arxiv.org/html/2608.20201#bib.bib19)\]\.

### VIII\-BFor the Database Industry: From Passive Storage to Active Infrastructure

The database rises from “passive storage beneath applications” to “active infrastructure above them\.” This elevation is not idle speculation—its first half is already observable: vector retrieval has spawned an independent database category\[[9](https://arxiv.org/html/2608.20201#bib.bib9)\], text\-to\-SQL has sharply lowered the barrier to structured\-data access, and DBOS argues for rebuilding the foundation of distributed applications on database primitives\[[4](https://arxiv.org/html/2608.20201#bib.bib4)\]\. What this paper further predicts is its second half—the database assuming the new responsibilities of“arbiter of consistency” and “governor of state”: the authoritative source and final adjudicator of agent behavior\.

This prediction is falsifiable: if, in a future “agent \+ database” form, state governance still requires a separate control plane outside the database, then this thesis’s claim that “storage is elevated into the sole foundation” is correspondingly weakened\. In other words, the value of the database industry will no longer be priced by “access performance” alone, but by “how many deterministic semantic anchors”—constraints, audit, rollback, adjudication—it can supply\.

### VIII\-CFor the Software\-Engineering Discipline: Repositioning Correctness Assurance

The foundation of traditional software engineering is “correctness by construction\.” Under the converged form, correctness assurancepolarizes into two poles:*probabilistic correctness*\(model reasoning, secured by a verification\-feedback loop\) and*deterministic correctness*\(storage constraints and formal verification, secured by mathematics\)\. The central question of software engineering thus partially shifts from “how to write correct code” to “how to design constraints and verification such that a probabilistic system is, on the whole, trustworthy\.”

### VIII\-DRisk and Governance

The converged form brings new governance challenges: agent behavior must beauditable\(fully recorded to the storage layer\),attributable\(clear responsibility for agent errors\), andlimitable\(least\-privilege tools and storage constraints\)\. We argue that the healthy evolution of the converged form depends on folding “governance” itself into the storage layer’s constraint and audit semantics—making governance part of the foundation rather than an after\-the\-fact patch\.

## IXConclusion

This paper proposes and argues for a convergence thesis about software form: within task domains that are expressible, verifiable, externally stateful, tool\-complete, and economically viable, the traditional three\-tier architecture will collapse into three elements—generalized database \+ large model \+ agent—with the UI regressing into model output, the business logic differentiating into model reasoning, storage constraints, and residual deterministic tools, the control flow reconstructed as the agent’s loop, and only the state surviving and being elevated into the foundation\.

We have also delineated the thesis’s boundaries: determinism and correctness, performance and cost, security and compliance, and verifiability and hallucination—these four constraint classes determine the thesis’s domain, and in doing so illuminatewhich software will not be replaced\. The value of this paper lies not in declaring a utopian “end of software,” but in offering atestable framework: one that points out the direction of software\-form convergence while also marking the endpoint and the limits of that convergence path\.

Future work can proceed in three directions: first, scale the experiments of Sections[V\-F](https://arxiv.org/html/2608.20201#S5.SS6)and[V\-G](https://arxiv.org/html/2608.20201#S5.SS7)to larger instances and a full tool\-using agent, and compare against a hand\-written baseline; second, formalize the mechanism of “storage constraints as the arbiter of consistency over model outputs,” and study whether it can provide a quantifiable correctness backstop for probabilistic reasoning; third, investigate the methodology and toolchain of “constraint\-driven development” from a software\-engineering perspective\. We believe that whether the thesis is ultimately confirmed or refuted, the very act of posing it will deepen our understanding of what software truly is\.

## Artifact Availability

The prototype and all experiment scripts are available athttps://github\.com/kyloTyn/software\-form\-convergence\. The two live\-model experiments call Qwen\-Plus through the Alibaba DashScope compatible\-mode API and require a key supplied via theDASHSCOPE\_API\_KEYenvironment variable; no key is stored in the repository\. All other experiments are deterministic and depend only on Python and OR\-Tools\.

## References

- \[1\]M\. Andreessen, “Why software is eating the world\.” The Wall Street Journal, 2011\.
- \[2\]A\. Karpathy, “Software 2\.0\.” Medium \(Andrej Karpathy blog\), 2017\.
- \[3\]A\. Karpathy, “LLM OS\.” X \(Twitter\) thread, 2023\.
- \[4\]Q\. Li, P\. Kraft, K\. Kaffes, A\. Skiadopoulos, D\. Kumar, J\. Li, M\. Cafarella, G\. Graefe, J\. Kepner, C\. Kozyrakis, M\. Stonebraker, L\. Suresh, and M\. Zaharia, “DBOS: A DBMS\-oriented operating system,”Proceedings of the VLDB Endowment, vol\. 15, no\. 12, pp\. 21–30, 2022\.
- \[5\]S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. Cao, “ReAct: Synergizing reasoning and acting in language models,” inInternational Conference on Learning Representations \(ICLR\), 2023\.
- \[6\]T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, E\. Hambro, L\. Zettlemoyer, N\. Cancedda, and T\. Scialom, “Toolformer: Language models can teach themselves to use tools,” inAdvances in Neural Information Processing Systems \(NeurIPS\), 2023\.
- \[7\]S\. Gravitas, “AutoGPT\.” GitHub repository, 2023\.
- \[8\]G\. Wang, Y\. Xie, Y\. Jiang, A\. Mandlekar, C\. Xiao, Y\. Zhu, L\. Fan, and A\. Anandkumar, “Voyager: An open\-ended embodied agent with large language models,” 2023\.
- \[9\]P\. Lewis, E\. Perez, A\. Piktus, F\. Petroni, V\. Karpukhin, N\. Goyal, H\. Küttler, M\. Lewis, W\. tau Yih, T\. Rocktäschel, S\. Riedel, and D\. Kiela, “Retrieval\-augmented generation for knowledge\-intensive NLP tasks,” inAdvances in Neural Information Processing Systems \(NeurIPS\), 2020\.
- \[10\]C\. Packer, S\. Wooders, K\. Lin, V\. Fang, S\. G\. Patil, I\. Stoica, and J\. E\. Gonzalez, “MemGPT: Towards LLMs as operating systems,” 2023\.
- \[11\]A\. Vaswani, N\. Shazeer, N\. Parmar, J\. Uszkoreit, L\. Jones, A\. N\. Gomez, Łukasz Kaiser, and I\. Polosukhin, “Attention is all you need,” inAdvances in Neural Information Processing Systems \(NeurIPS\), 2017\.
- \[12\]T\. B\. Brown, B\. Mann, N\. Ryder, M\. Subbiah, J\. Kaplan,et al\., “Language models are few\-shot learners,” inAdvances in Neural Information Processing Systems \(NeurIPS\), 2020\.
- \[13\]J\. Wei, X\. Wang, D\. Schuurmans, M\. Bosma, B\. Ichter, F\. Xia, E\. Chi, Q\. Le, and D\. Zhou, “Chain\-of\-thought prompting elicits reasoning in large language models,” inAdvances in Neural Information Processing Systems \(NeurIPS\), 2022\.
- \[14\]C\. Gaoet al\., “A systematic literature review of code hallucinations in LLMs,” 2025\.
- \[15\]H\. Yuet al\., “Aligning academia with industry: An empirical study of industrial needs and academic capabilities in AI\-driven software engineering,” 2025\.
- \[16\]J\. M\. Hellerstein, M\. Stonebraker, and J\. Hamilton, “Architecture of a database system,”Foundations and Trends in Databases, vol\. 1, no\. 2, pp\. 141–259, 2007\.
- \[17\]M\. Stonebraker and U\. Çetintemel, “”one size fits all”: An idea whose time has come and gone,” inProceedings of the 21st International Conference on Data Engineering \(ICDE\), 2005\.
- \[18\]R\. S\. Sutton, “The bitter lesson\.” incompleteideas\.net blog, 2019\.
- \[19\]Y\. Geet al\., “A survey of vibe coding with large language models,” 2025\.Author list and volume to be re\-verified before submission\.