FMOS: Giving Foundation Models a Self-Evolving Operating System Layer

From Single Models to Compound Agents: A Fragmented Stack

The shape of AI applications is undergoing a fundamental shift. In the past, a single, large foundation model (FM) handled everything in a given application. Today, more and more systems have evolved into compound agentic systems — where multiple models, tools, and agents work in concert. This architectural evolution has unlocked remarkable new capabilities, but it has also exposed a serious lag in the underlying infrastructure.

A position paper on arXiv, titled "Position: It is Time to Virtualize Foundation Models with a Self-evolving Operating System Layer," cuts straight to the heart of the problem: while protocols like MCP and A2A have simplified connections between tools and agents, every framework still bundles its own implicit runtime internally — each independently managing state, memory, budgets, and safety guardrails. The result is that system behavior can't be ported across platforms, and governance mechanisms become dangerously brittle.

The authors use a brilliant analogy to describe this situation: it closely resembles the era of computing before operating systems existed — when every program had to reimplement basic services from scratch, from memory management to device drivers. Without a unified system abstraction layer, redundant work and incompatibility were the norm.

MCP (Model Context Protocol) is an open standard proposed by Anthropic in 2024 to unify the communication interface between AI models and external tools or data sources — analogous to a USB standard in the programming world. The A2A (Agent-to-Agent) protocol focuses on direct communication and collaboration between agents, allowing agents built on different frameworks to delegate tasks to one another. While both have simplified the "connection" layer, as the paper points out, the runtime management that comes after the connection — how context windows are allocated, how memory is persisted, how budget overruns are circuit-broken, how outputs are filtered — is still embedded as a private implementation within each framework (such as LangChain, AutoGen, and CrewAI). This is the deep root cause of fragmentation.

FMOS: Virtualizing Foundation Model Interactions

The paper's central proposal is that this field now needs a Foundation Model Operating System (FMOS) — a system layer whose purpose is to virtualize interactions with foundation models, much the same way a virtual machine (VM) abstracts physical hardware.

This analogy is worth unpacking. The value of a VM is that it gives each application the illusion of having exclusive access to an entire machine, shielding it from the complexity of the underlying hardware and the conflicts that arise from sharing it. What FMOS aims to provide is the illusion of having exclusive access to a trusted, near-infinitely capable model instance. Application developers no longer need to care which model is actually being called, how context is managed, or whether a budget has been exceeded — all of that is handled uniformly by the system layer.

The significance of this abstraction lies in decoupling. Once model interactions are virtualized, application logic is separated from specific model implementations and runtime policies, fundamentally improving behavioral portability and governance stability.

Inside the System Layer: Orchestration, Selection, and Enforcement

So what does FMOS actually do internally? The paper outlines responsibilities across three dimensions:

Knowledge Orchestration Across Memory Tiers

FMOS needs to orchestrate knowledge flow across different memory tiers. This mirrors how traditional operating systems manage data across registers, caches, RAM, and disk — each tier involves tradeoffs in speed, capacity, and cost, and the system must intelligently decide what knowledge lives where.

Model Selection and Resource Allocation

In compound systems, tasks can often be completed by models of varying capabilities and costs. FMOS takes on the scheduling responsibilities of model selection and resource allocation, making tradeoffs between performance and expenditure rather than leaving each framework to fend for itself.

Verification and Policy Enforcement

Safety guardrails and governance rules should not be scattered across individual frameworks. FMOS consolidates verification and policy enforcement into the system layer, making governance centralized, controllable, and auditable — fundamentally addressing the "brittle governance" problem described earlier.

An Operating System That Evolves Itself

The most imaginative part of the paper is FMOS's "self-evolving" nature. The authors draw on the dual-process theory of the human brain as an analogy: the brain switches between fast intuition and slow deliberation. FMOS should likewise learn to judge — when it needs to intervene, and when it can let inference proceed directly.

More critically, this set of policies is not hard-coded but is designed to continuously adapt based on operational experience. This means FMOS is not just a static scheduling framework, but a dynamic system that continuously refines its decisions through use. This design philosophy elevates the operating system from a "rule enforcer" to an "experience learner."

The "fast and slow" dual-system theory originates from psychologist Daniel Kahneman's framework in Thinking, Fast and Slow: System 1 handles fast, automatic, intuitive responses, while System 2 handles slow, effortful, logical reasoning. Translated into the FMOS context, this means the system layer requires metacognitive capability — the ability to assess the complexity and risk level of a given request. Low-risk routine calls pass through directly (analogous to System 1), while high-risk or resource-intensive tasks trigger more complex scheduling and verification processes (analogous to System 2). This adaptive intervention mechanism is the core design concept that distinguishes FMOS from traditional static scheduling frameworks, and is the foundation of its "self-evolving" capability: the system continuously calibrates its intervention thresholds by observing which decisions have led to good outcomes.

A Directional Judgment

It's worth being clear: this is a position paper. Its value lies in proposing a direction and a framework, not in delivering a complete engineering implementation. The authors' central thesis — that AI infrastructure is at "the eve of the operating system" — carries considerable explanatory power, attributing the chaos in the current agentic ecosystem to one root cause: the absence of a unified system abstraction layer.

If the FMOS vision is realized, it could reshape the entire tech stack for agentic development: developers program against a stable system interface, while the underlying complexity of model selection, memory management, and safety governance is absorbed by the system layer. This closely parallels the historical moment when operating systems liberated application developers decades ago. Of course, there is still a long road from concept to usable system. How dual-process-style adaptive policies would be implemented, and how their trustworthiness would be guaranteed, are open questions left for future research to answer.