VFMOS
VFMOS · Research initiative

Virtualize foundation models.

A self-evolving operating system layer that gives every agent the illusion of a dedicated, trustworthy foundation model — with effectively unbounded capabilities. A virtual FM is not a model router: it is a stateful entity whose data, models, and trust are optimized together and evolve together.

Explore the architecture Research & publications
Scroll
The missing layer

Agent stacks today look like computing before operating systems.

Frameworks proliferate. Protocols connect tools. Yet each harness still embeds its own runtime for state, memory, budgets, and guardrails — so behavior is non-portable and governance stays brittle.

FMOS — the Foundation Model Operating System — is the system layer we propose to fill this gap. It serves each application a VFM, a Virtual Foundation Model: the illusion of a dedicated, trustworthy foundation model, realized as one stateful bundle of data, models, and trust that the FMOS co-optimizes and co-evolves.

Without FMOS

  • Every agent stack reimplements basic services
  • Improvements do not propagate
  • Shared governance is nearly impossible

With FMOS

  • Stable contracts for memory, budgets, and trust
  • Learned policies that improve across workloads
  • One virtualization boundary under every agent
Where the gap sits

Between frameworks and inference.

MCP and A2A ease connectivity. They do not define portable execution semantics. In the gap sit many differently configured VFMs on one shared FMOS — click a layer to see what belongs where.

The approach

Virtual Foundation Models, enabled by an FMOS.

A VFM presents applications with a dedicated, trustworthy FM instance. Each VFM is a stateful entity spanning three planes: the data it knows, the models that back it, and the trust policies that govern it. The FMOS optimizes the three jointly at run time and evolves them together over time, under explicit cost, latency, and safety budgets.

Unified services

Context management, tool orchestration, and verification live at the system layer — so learned improvements co-evolve across dependent workloads.

Joint optimization

Retrieval depth, model routing, inference quotas, and verification are one optimization problem — not three fragmented knobs.

Cross-team reuse

Domain skills, knowledge augmentations, and reasoning policies are defined once and reused across applications and enterprises.

Architecture

One system layer, three cooperating subsystems.

Apps and agents reach Virtual Foundation Models through a standard execution API and a VFM control plane. Behind that interface, three subsystems — data, composition, and trust — coordinate knowledge, model choice, and verification above shared platforms. They are not independent services: a VFM's state spans all three, optimized jointly per call and co-evolved as one system. Click any pillar to explore what it does.

Runtime behavior

Keep the common case fast. Escalate only when needed.

By default, requests pass through the VFM interface with light accounting. When learned traps fire — uncertainty, policy sensitivity, budget pressure — FMOS activates just the services required, then returns to the fast path.

01

Virtualize behind stable semantics

Applications rely on invariants for state, budgets, and trust escalation — not on today’s routing implementation.

02

Demand-driven orchestration

Fast path by default; slow path only via explicit traps when quality, budget, or trust requires it.

03

Ecosystem compatibility

Integrate via OpenAI-compatible APIs, MCP endpoints, and framework hooks — without forcing application rewrites.

Self-evolution

Progressive quality gain — not mere fidelity.

Unlike classical virtualization that preserves hardware fidelity, FMOS learns from interaction traces: updating prompts, memories, and policies, usually without retraining underlying models — with versioning, canaries, and rollback.

Case studies

Where the abstraction earns its keep.

Two agentic settings, shown without and with VFMOS. Each “with” step is tagged with the subsystem doing the work — click a tag to jump to that part of the architecture.

Accelerating scientific discovery

Multimodal evidence spans tables, figures, microscopy, and time series — and findings must respect physical constraints.

Without VFMOS

  • Whole datasets and paper dumps flood the context window — cost explodes and signal drowns.
  • One general-purpose model serves microscopy, literature, and time series alike.
  • Outputs go unchecked against physics, and validated findings evaporate after each run.

With VFMOS

  • Data Hierarchy A knowledge trap retrieves only the critical microscopy region and related literature.
  • Composition Optimizer The call is routed to a domain-fit model bundle under cost and latency budgets.
  • Trust Hierarchy Verification enforces physical constraints before results are accepted.
  • Self-evolution Validated associations are stored and reused on the next run.

Technical support with adaptive context

Support agents must zoom into the current decision-tree node without losing the broader troubleshooting path.

Without VFMOS

  • Every turn re-sends the full troubleshooting history — or leans on hand-built memory glue.
  • The agent loses its place when the decision tree branches; context overflows or truncates.
  • Session state is bespoke to each team and does not transfer.

With VFMOS

  • Data Hierarchy Context is demand-paged: only the active decision-tree node enters the window.
  • Data Hierarchy The full troubleshooting path stays resident in an evolving hierarchy, recalled as the query moves.
  • Trust Hierarchy Uncertainty traps escalate ambiguous diagnoses to deeper deliberation before a fix is committed.
  • Self-evolution Resolved paths are consolidated, so the next session starts further ahead.
FAQ

Why not just wait for better models?

The questions we hear most often — and how VFMOS answers them.

FMs will become so good that augmentation is obsolete
Longer reasoning traces still cannot gather new evidence or adapt in dynamic environments. Capability remains a plan–act–learn loop with tools, feedback, and memory — so system-level augmentation stays fundamental.
Agent frameworks plus optimizers will cover everything
Frameworks help with wiring; they do not provide portable system-layer guarantees for state, memory, rollback, or trust. Optimizers inherit those gaps.
MCP and A2A already solve the hard problems
Protocols standardize connectivity. They intentionally stop short of execution semantics and governance. Without a shared substrate, those contracts get bolted on incompatibly.
The OS analogy is misleading
Classical OS abstractions are increasingly distant from FM instructions, knowledge, and reasoning. FMOS virtualizes those higher-level operations — above the host OS, using OS-inspired principles where they fit.
Why not a database instead of an OS?
Databases are powerful external services you must choose to call. FMOS is designed to decide when to intervene automatically, transparently beneath the model interface applications already use.
Research & publications

The thinking behind VFMOS.

VFMOS is being actively developed. Start with the position paper; more published and preprint work will be listed here as it appears.

More publications from the group are on the way.

Get involved

Help build the FM virtualization layer.

Principled FM virtualization will not emerge from isolated optimizations. It needs shared abstractions, open prototypes, system-level benchmarks, and governance contracts that treat FMOS controls as first-class.

Researchers

Converge on VFM lifecycle, isolation, and interfaces for context, reasoning, and trust — inspired by classical virtualizability results (Popek & Goldberg).

Builders

Ship open, modular FMOS prototypes that intercept via existing APIs and coexist with popular agent frameworks.

Evaluators

Benchmark beyond task accuracy: context efficiency, cost–quality trade-offs, auditability, and longitudinal self-evolution.