Editors’ note: “AI-native systems” is one of today’s most prominent tech buzzwords, yet its meaning remains ambiguous and often inconsistently defined. In this article, Professor Cheng Tan offers a technical perspective on what constitutes an AI-native system, providing both a clear definition and a systematic framework to help understand the technical evolution of AI for systems. This article is the 8th installment in The Next Horizon of System Intelligence blog series.
AI has started writing systems code. Not autocompleting it—writing it: agentic frameworks now discover scheduling and load-balancing algorithms that beat expert baselines, and coding agents synthesize, benchmark, and verify implementations against real workloads [Barbarians at the Gate, AlphaEvolve]. Meanwhile, seemingly every product announcement declares something “AI-native”: AI-native databases, AI-native clouds, AI-native operating systems, AI-native developer tools. Ask five people what the term means and you will get five answers, most of them involving the word “LLM” and a diagram with sparkles.
I want to argue that “AI-native” deserves—and can be given—a precise technical definition. And I want to argue for a perhaps surprising claim about what that definition should say: AI-nativeness is not about how much AI a system contains. It is about who is allowed to change the system.
Why bother defining a buzzword?
A good definition is a coordination device. “Self-driving” was for years a marketing term, stretched from lane-keeping to robotaxis, at real cost: drivers over-trusted systems that could not own failure, and engineers could not say what they were building toward. The SAE J3016 levels changed that by pinning down which decisions the machine holds, within what bounds, and who owns failure—a contract that let regulators regulate and engineers know what the next milestone was.
“AI-native systems” is at the pre-definition stage, and the field is feeling the costs. We cannot measure progress, cannot distinguish a milestone from a press release, and—above all—cannot say where the guardrails must go: when an AI can rewrite your eviction policy and deploy it, “what may it touch, and what must it never touch?” stops being abstract. A definition is where the answer has to live.
People have made progress on a closely related but complementary problem: grading AI capability for systems. Consider two recent efforts in this very series. Maas et al. ask how much intelligence a systems problem demands, arguing in their ACM SIGOPS Operating Systems Review paper that fully solving classic system policies is “AGI-complete.” Feng et al. ask how capable an AI is at systems research, grading it against PhD-student personas along the SOAR dimensions [Defining System Intelligence]. Both are valuable, and both are about the AI. But “native” is a claim about the system. A one-off superhuman result from an algorithm-discovery run does not make any deployed system AI-native: the discovered algorithm holds no standing authority, and no loop closes when the workload drifts next month. Conversely—and this is the interesting direction—a system built entirely from narrow, unglamorous ML can be deeply AI-native, if an agent holds bounded, verified authority to keep rewriting its heuristics as the world changes. Capability and authority are orthogonal axes. The capability taxonomies grade what an AI can do; a definition of AI-native must grade what a system permits.
A decade of ML for systems, and the cost it kept paying
To motivate the definition’s shape, start with a puzzle. Machine learning for systems works, and it ships: learned index structures, learning-based memory allocation in production server workloads, admission optimization for Google’s datacenter flash caches, learned eviction for YouTube’s CDN, learned VM placement at scale. These are real deployments with real wins.
Yet after a decade, ML for systems remains a collection of point solutions—each one an expensive, component-scoped effort, hand-built and hand-maintained by a team that understood both the model and the subsystem. It never became a pervasive property of how systems are built and evolved. Why not?
The reason is not that the models were bad. It is that a resident learned component—a model that executes on the live path—carries operational costs a fifty-line heuristic does not. Five of them, briefly. Runtime overhead: inference plus feature collection, charged on the critical path at decision frequency, often costs more than the operation it optimizes. Distribution shift: workloads are nonstationary; the drift-detect-retrain-redeploy tax never ends. Tail behavior: training objectives happily trade away the p99 engineers care about, and resident models lack classical heuristics’ worst-case bounds. Maintainability: a heuristic becomes an ML pipeline attached to software with a decades-long lifespan. Expertise: doing this well requires deep skill in ML and systems simultaneously.
Production teams understood this long before it was written down; the deployments that succeeded share a pattern: Azure shipped offline-trained decision trees with explicit fallbacks; Google’s flash cache used a knapsack solver rather than a neural network. Learning happened—and then something either took the model out before deployment or pinned it down until it behaved like code.
Here is the observation everything else builds on: every one of the five costs is a cost of residency, not of learning—what you pay for making a model execute on the hot path. None applies to letting a model shape the system from off it.
What changed
What changed in the last two years is the mode of use: agents now author systems code rather than reside inside it—reading traces, proposing implementations, benchmarking and verifying them in a control plane far off the critical path. The AGI-complete paper names the resulting architecture: a slow control plane where models reason and generate code, and a fast data plane where that code executes. The AI moves from occupying a decision to authoring the code that decides, and this mitigates all five costs: authored code pays no inference cost per event; it is re-authorable when the workload shifts; it can be verified for tail behavior before it ships; it is as maintainable as the code a good engineer would have written—because it is that kind of code; and the expertise burden shifts onto the agent. Notice that the costs do not disappear, they shift: off the per-event hot path and into the control plane, where there is time to make better decisions.
For the first time, an AI can continuously revise a system’s own implementation—not merely retune its knobs—under human-set goals. That capability is as consequential as it is hazardous, and the system property it creates is what “AI-native” should name.
Who decides—and who may change the decider?
To say precisely what authority an AI holds, index a system’s decisions by binding time—the point at which a decision’s outcome becomes fixed. Top-down, a system is a stack of decisions, each level defining the space the next chooses from: L0—purpose (what the system is for); L1—design (components, interfaces, invariants); L2—implementation (the program behind a fixed interface); L3—policy (thresholds, timeouts—and, notably, the trained weights of a runtime ML model); L4—runtime (evict this line, schedule this task).
Two gradients run through the stack in opposite directions. Stakes grow upward: an L4 eviction is nearly worthless individually; an L1 interface choice can be worth the whole system. Frequency grows downward: L1 binds once in months; L4 fires millions of times a second. This is why “put the smart thing on the hot path” was always structurally doomed—the level whose decisions matter least per event admits only the cheapest decider.
Now the pivotal distinction, the one the field routinely blurs: who executes the decision (occupancy) versus who may change the decider when the workload demands it (revision authority). A learned eviction policy occupies L4—its forward pass fires on every miss—but holds revision authority over nothing: it cannot retune its weights, rewrite its serving code, or question its design. A human installed it; a human watches it drift; a human retrains it. Occupancy without revision authority is not autonomy—it is an expensive resident.
Grade systems by how high an AI’s revision authority reaches, and a ladder appears:
Self-tuning (S3). An AI revises the policy within the family the implementation exposes: knob tuners, autoscalers, self-tuning databases—and, as a degenerate case, every retraining loop around a runtime model. This is the classical ceiling, and its failure mode is saturation: when the workload drifts beyond what the policy family can express, no tuning recovers, and the degradation is silent—”is this the right policy family?” lies one level above the system’s authority.
Self-rewriting (S2). An AI synthesizes a new implementation behind the same interfaces—exactly what agentic synthesis now does. Two things become constitutive. First, an escalation detector: something must convert “my tuning has stopped working” from an incident into a signal that triggers regeneration. Second, verified admission: every candidate revision must pass some form of verification, and the system must retain a non-AI fallback, so the deployed worst case is the fallback’s by construction (the classic Simplex pattern). Self-rewriting without verification is not a maturity grade; it is an incident generator.
Self-architecting (S1). An AI revises the design itself, subject only to human-owned purpose. This grade is aspirational, and qualitatively harder: revising the design changes what the verifier is—who checks the checker after the checker is rewritten? Any honest account caps a redesign’s complexity at what a human can still audit.
One more cut matters. Each grade has a weak form—a human or a schedule pulls the trigger—and a strong form, where the system detects its own drift and triggers its own regeneration. A coding agent that rewrites heuristics on request is weak-S2: real progress, but drift detection is still a human staring at dashboards. The step from weak to strong automates the trigger, not the synthesis—and that is where most of the drift-robustness value sits.
AI-native systems: the definition
With the vocabulary in place, the definition states itself. A system is AI-native if and only if:
- Strong self-rewriting. An AI autonomously revises the system’s implementations, and—via an escalation detector—autonomously determines when revision is needed.
- Allocation authority. The AI decides which decider occupies each decision point (compiled code, a lookup table, a small model), and may reassign deciders as costs and workloads change—which, given the frequency gradient, keeps cheap compiled code on the hot path.
- Verified admission. Every AI-generated change passes a verification procedure before deployment, and a non-AI fallback is retained, so the composite’s worst case is the fallback’s. Depending on the system’s duty, this procedure may sit anywhere on a spectrum trading cost against rigor, from comprehensive testing to formal verification.
- A human-owned envelope. Purpose, objectives, and correctness invariants remain under human ownership and bound all AI authority below them.
Compactly: AI-native = autonomous rewriting × allocation authority × verified admission, under a human-owned envelope.
By this definition, a system full of AI can fail to be AI-native, and a system with no neural network on any hot path can qualify. The learned index bolted into a production database—the emblematic “AI system” of the last decade—is not AI-native; it is model-resident, occupying a decision point while a human maintains it. A storage engine whose eviction code is plain C, continuously re-derived by an agent under trace-replay verification with a retained fallback, is AI-native. The grade tracks authority, not model count.
The bigger vision
Until now, a computer system has been an artifact written and then frozen: humans pour design intelligence in at development time, and when the world drifts, humans pay the revision cost. Now within reach is an artifact grown and governed instead—its implementations standing hypotheses, continuously re-derived as evidence accumulates, by an intelligence inside the system’s own life cycle: this series’ “self-evolving artifacts” made concrete. The work this demands is not primarily better models but guardrails—escalation detectors that know when a policy family has failed, verification-and-fallback disciplines that make autonomous rewriting survivable, threat models for an agent holding deploy authority—and building them is what this community has always done. Systems research is, at its core, the discipline of wrapping powerful-but-unruly mechanisms in abstractions with guarantees: virtual memory around raw DRAM, transactions around concurrent chaos, TCP around a lossy network. An AI that rewrites code is the most powerful unruly mechanism we have been handed yet; wrapping it in a verified envelope, with authority delineated and purpose pinned to humans, is the next instance.
“AI-native” has been a slogan in search of a referent. I have proposed one: bounded, audited authority for an AI to revise a system’s own decisions, under a human-owned purpose. I would rather the community sharpen this definition than each of us ship our own—so: What would falsify it? Which clause would you drop, and what incident would you expect afterward? And what is the first system you would grade with it?
This post is based on the paper “Defining AI-Native Systems: Autonomy as Revision Authority.” An earlier, informal version of some of these arguments appeared on my blog.
About the author: Cheng Tan is an assistant professor at Northeastern University. His research sits at the intersection of systems and machine learning, including verified neural networks for computer systems and the question of when learned components can—and cannot—replace time-tested system policies.
Editors: Mike Chieh-Jan Liang, Francis Yan, Haoran Qiu, and Tianyin Xu