A research paper says apps are collapsing into a database, an AI model, and an AI agent

A customer service chat that parses a photo of a damaged package, files the return, schedules the pickup, and confirms the refund in a single window is doing work that used to need a backend team. The interface is text, the state lives in a database, and the logic that connects them, the rules about return eligibility, the routing between systems, the error messages, was, until recently, hand-coded. A paper posted to arXiv on August 20, 2026 argues that logic layer is being absorbed. Three things remain, the authors claim: storage, a large AI model, and an agent.

The three-tier architecture is the default shape of nearly every web and mobile product a reader has used in the last twenty years. The first tier is the interface (the buttons, the pages, the chat window). The second is the business logic (the rules that decide what the system is allowed to do, the workflows, the validation). The third is the data layer (the database, the cache, the persistent state). Most of the cost of building software went into tier two: the engineers who wrote and maintained those rules.

The paper, written by Wei Lin, Tao Zhou, Zhaofei Xie, and Changgui Hong at Nanjing Liancheng Intelligent Technology Group, re-partitions each tier along a different axis. The interface splits into a deterministic projection (the part that must be exact, like a price or a date) and a generative decoration layer, where the model fills in the layout, the wording, the microcopy. The business-logic layer is re-divided along two questions: how expressible the rule is in natural language, and how critical it is that the rule never fails. Rules that score high on both go to the model. Rules that score low on criticality stay in code. Rules that depend on data move into the database as constraints, and the model is told not to violate them. The data layer, the authors argue, is the only thing that needs to persist: it is the memory. The agent, a planning loop that calls the model, queries the storage, and invokes whatever deterministic tools remain, becomes the new tier two.

The thesis does not hold everywhere. The authors name four conditions a task domain must satisfy for the collapse to apply. The task must be expressible, meaning it can be stated in language the model can read. It must be verifiable, meaning the system can check whether the answer is right. It must be externally stateful, meaning the truth of the work lives in some data the model can read, not in the model's own weights. And it must be tool-complete, meaning everything the task requires can be reached through an API or a query. Outside those four conditions, the three tiers stay separate.

A billing system, a medical dosing interface, or an aircraft controller does not fit the new pattern. These workloads fail the verifiability or cost conditions, because the model is not a reliable substitute for a checked rule. Tasks behind a security boundary fail because the agent cannot be allowed to read everything the model would need. Tasks whose ground truth lives inside the model's training distribution rather than in live data fail the external-statefulness condition. The authors frame this in a positioning line worth quoting directly: "We do not claim the model is reliable; we claim the model should not have to be." The reliability requirement moves to the storage layer, where constraints, transactions, and checks live.

The reader-as-user sees the result when a product they use starts generating its own screens, summaries, and onboarding. The reader-as-developer sees it when the work shifts from writing features to writing prompts, schemas, and tool definitions, and when the new hiring question is no longer "can you build the workflow" but "can you describe the constraint." For the database industry, the paper's argument is that storage stops being one of three tiers and becomes the only persistent one; vendors who sell a database without a retrieval layer or a model-aware planner will look incomplete, though the paper itself does not catalogue them. The software-engineering discipline is the slowest to absorb it, because the textbooks still teach tier two as the engineer's domain. Readers should weigh all of this against the fact that the paper's authors work for an AI vendor with a stake in the convergence sounding inevitable.

Products that look like the return-portal example above (chat-driven, content-heavy, externally stateful) fit the new pattern. Products that look like a trading system, a clinical record, or a control loop do not. The paper's own worked example is an intelligent production-scheduling system, laid out in a single table. A reader who wants to see the partition in action can start there.