When AI Agents Reinvent the File System: From "Everything Is a File" to "Everything Is Context"

Prologue: Who Manages the Agent's RAM?

In 2023, Andrej Karpathy proposed an elegant analogy: the LLM is the CPU, the context window is RAM, and the prompt is the program. This analogy quickly became industry consensus, but few pursued the next question: Who manages this RAM? Who decides what goes in and out? When the program finishes execution, where is the state saved?

In a real computer, the answer is the operating system. The OS manages process scheduling, memory allocation, file systems, and device drivers. The CPU and RAM are merely execution layers; the OS is the foundation that makes everything run in an orderly fashion.

So where is the Agent's "operating system"?

Starting in the second half of 2025, several signals indicated the industry was taking this question seriously.

Jerry Liu, founder of LlamaIndex, publicly stated that Agent architecture is shifting "from hundreds of tools toward a file system plus 5–10 tools." LlamaIndex's slogan was even more direct: "Files Are All You Need." Around the same time, LangChain was making a similar pivot: using the file system for context engineering instead of piling more and more abstractions onto the framework layer.

This is not the product strategy of two framework companies. It points to a deeper judgment: Agent working patterns are fundamentally rewriting the underlying assumptions of storage architecture. When Agents need to manage cross-session state, frequently read and write intermediate artifacts, and coordinate context across multi-step tasks, the design assumptions of traditional file systems (humans are the primary users, tree-structured directories are the natural organization method, 4KB blocks are the appropriate granularity) fail one by one.

The replacement is not a new file system; it is a new information management paradigm. From "everything is a file" to "everything is context."

This is not a prediction. In the official FMS 2026 (Future of Memory and Storage, August 4–7, Santa Clara) agenda, IBM is presenting Cognitive File System, NVIDIA is presenting Storage-Next architecture, and Anthropic's Managed Agents is already running a novel state persistence model in production. What these approaches share: redefining the interface between Agents and data.

---

I. Why POSIX File Systems Fall Short

1.1 Context Window ≠ Memory

Karpathy's CPU/RAM analogy hides a trap: RAM is volatile. Power off, and everything is lost.

An Agent's context window is the same. During a single session, an Agent processes 50 tool calls, reads 20 documents, writes 3 code segments—all within the context window. Session ends, window clears, everything disappears.

Agents therefore face a classic computer science problem: there is a chasm between working memory (context window) and persistent storage. Working memory is fast but small and volatile; persistent storage is slow but large and reliable. An intermediate management layer is needed to decide what goes where, when to move things, and when to discard them.

In traditional computing, this management layer is handled by the OS kernel—virtual memory, page scheduling, mmap, swap. In Agent computing, this management layer scarcely exists. Most Agent frameworks either stuff everything into the context window (until it overflows) or write a JSON file to disk (to read back on next launch). There is no middle layer.

1.2 Agents vs. Traditional File System Design Assumptions

The Unix "everything is a file" philosophy was born in 1969, designed for human users and batch-processing workloads. Core assumptions:

An Agent is not a human. Give an Agent a path like /home/user/documents/report.pdf and it doesn't "understand" the path. What it needs is the vector representation of file content, structured extraction of key information, and relational connections to other files.

1.3 IO Granularity Inversion: 4KB → 512B

Traditional AI inference has a monolithic IO pattern: load model weights at startup (large-block sequential read), occasionally read input during inference. The storage industry's optimization direction has consistently been bandwidth (GB/s).

Agents break this pattern. A single Agent loop (observe environment → reason and decide → call tool → get result → update state) generates different IO at every step:

When multiple Agents execute concurrently, these operations compound into massive volumes of fine-grained random IO.

At FMS 2026, Microchip Technology Fellow Peter Graumann provided a precise quantification:

Current SSDs operate on 4KB block boundaries, but AI workloads operate at 512B or 1KB granularity.

An SSD's FEC (Forward Error Correction) uses 4KB as the minimum unit—the physical page size of NAND flash and the baseline for error correction algorithm design. When an Agent writes a 512-byte state fragment, the SSD must actually read out the entire 4KB block, modify 512 bytes within it, re-encode the error correction code, and write it back. Write amplification deteriorates dramatically under Agent workloads.

Bridging this 8× granularity gap requires redesigning the SSD block structure.

---

II. Four Technical Paths

Path 1: POSIX File System Directly for Agents

Design philosophy: Don't reinvent the wheel. An Agent is a program; programs use file systems as a matter of course.

Representative implementations: Claude Code, Cursor, OpenClaw, most Agent development frameworks.

Currently the most mainstream approach. Agents run in standard OS environments and manipulate files through read/write/exec system calls. Agent frameworks layer their own abstractions on top of the file system, but the foundation relies entirely on POSIX.

Advantages: Zero infrastructure cost; ecosystem compatibility (git, grep, make all work); developer familiarity.

Disadvantages: State management depends entirely on the application layer, with every framework doing it differently and no standard; high-frequency small-file writes are unfriendly to SSD WAF (Write Amplification Factor); no isolation or consistency guarantees for multi-Agent collaboration.

Assessment: A pragmatic short-term solution, but pushes all complexity to the application layer. As Agents move from single-node to distributed and from short-lived to long-running, the POSIX ceiling arrives quickly.

Path 2: "Everything Is Context" File System

Design philosophy: The file system is not replaced; it is abstracted away. What the Agent sees is not files, but context.

Representative implementations: arXiv paper "Everything is Context"; LlamaIndex's practice direction.

The way Agents consume information is not "open file, read content" but "receive a piece of context, incorporate into reasoning." The Agent doesn't care whether information comes from a file, a database, or an API—it cares about the relevance of that information to the current task.

Technical key points: Content-addressed storage (data blocks identified by hash); automatic versioning (every Agent step is a commit); Context Assembler—retrieves relevant fragments from the storage pool based on inference needs and dynamically assembles them into context window content.

Advantages: Most closely aligned with Agent information consumption patterns.

Disadvantages: Purely an academic concept, lacking production-grade implementation; context assembly latency may be unacceptable; abandoning POSIX compatibility means existing toolchains become unusable.

Assessment: The most radical path. Correctly identifies that Agents need not "files" but "context." More likely outcome: core ideas get absorbed by other paths.

Path 3: Cognitive File System

Design philosophy: Transform the file system itself, giving it "cognitive" capabilities.

Representative implementation: IBM Cognitive File System (formally proposed at FMS 2026). Author Viacheslav Dubeyko, IBM employee and Linux kernel developer.

Dubeyko published the precursor work "File System in Data-Centric Computing" on arXiv in 2019. The FMS 2026 proposal is the extension of this thinking into the Agent era.

Key statements from IBM's FMS 2026 agenda:

"AI agents become a new customer of digital data."

"completely new technological foundation for computation offload in storage space, adopting ML models for data analysis/processing, and provide a flexible interface for more efficient interaction among AI agents and data."

Additional design points: Users can store raw data streams without needing to name files. The cognitive subsystem automatically detects duplicate patterns in data streams, builds relationship dictionaries, and correlates different data streams like a relational database. These capabilities are placed in the Computational Storage Track, indicating IBM sees cognitive file systems and computational storage as an integrated whole.

Core technical propositions:

1. Eliminate filename as a required addressing method. Agents can store data streams without assigning names. The system organizes and retrieves data through pattern recognition. This directly challenges fifty years of Unix file system fundamental assumption.

2. Cognitive subsystem automatically discovers repeating patterns. The system continuously analyzes incoming data, detects repeating patterns, and builds "relationship dictionaries." Patterns become keywords connecting different data streams. The file system performs its own feature engineering and correlation analysis.

3. Computational offload within the storage space. Not just storing data, but executing computation where the data resides—using ML models to analyze, extract features, and return results.

4. A new interface between AI Agents and data. Not POSIX's open/read/write, but an AI-native data access interface.

Advantages: Kernel-level solution, transparent to Agents; the file system performs its own data analysis, reducing data movement.

Disadvantages: Modifying the file system kernel is the slowest path—from proposal to production may take 3–5 years; whether the computational overhead of the cognitive subsystem itself is acceptable remains unclear; currently at the proof-of-concept stage.

Assessment: A long-term path. Its value lies in pointing in the right direction—file systems should understand the data they store. In the short term, it is more likely to inspire architectural design in other solutions.

Path 4: Bypassing the File System — Logs, Sandboxes, microVMs

Design philosophy: Don't modify the file system—bypass it. Agent state management needs event logs, snapshots, and isolation.

Representative implementation: Anthropic Managed Agents (running in production).

Consists of three layers:

Session as Append-Only Durable Log: Every Agent operation—every tool call, every reasoning result, every state change—is appended to a persistent event log. Not an in-memory JSON, but an append-only log on persistent storage.

The fundamental difference from traditional file systems: traditional FS supports random read/write; append-only log only supports tail appending. This sounds like a limitation, but is actually an advantage:

• Immutability: Written events cannot be modified, naturally supporting replay. On error, execution can resume from any position in the log.
• Causal ordering: Log order equals event occurrence order, naturally satisfying causal consistency.
• Simplified crash recovery: No need for fsync, journal, or fsck. After a crash, replay the log from the last checkpoint.

Harness — Stateless Executor: Completely stateless. Each execution: receive sessionId → replay log to most recent checkpoint → load into context window → execute → append result to log. Any Harness instance can execute any Agent session—no state affinity. Scheduling flexibility equals that of stateless microservices.

Sandbox — A Fresh microVM per Tool Call: Used and discarded. No state leakage, no cross-call file system contamination, no permission residue. The sandbox has only a read-only disk; tool call results are serialized and written back to the Session log.

Results: According to Anthropic's April 2026 Claude Managed Agents launch blog, compared to self-built Agent infrastructure (bare invocation mode without Session log or sandbox isolation), p50 first-token latency dropped 60%, p95 dropped 90%. The improvement primarily came from the runtime layer removing state management and tool call overhead, not from the model itself getting faster.

Assessment: The solution currently closest to a production-grade Agent storage architecture. The core insight is that Agent state is fundamentally an event stream, not a file—this may become the design baseline for future Agent Runtimes.

Comparison of the Four Paths

---

III. NVIDIA's Storage Ambition: Storage-Next and ICMS

The four paths above are explorations within the technical community. NVIDIA's moves indicate that GPU vendors are no longer just building GPUs—they are defining storage architecture.

3.1 Storage-Next: New Storage Layer Specification

In the FMS 2026 agenda, Phison's presentation title "Enabling Ultra-High-IOPS Storage-Next SSDs with AI-Enhanced LDPC" reveals a key signal: NVIDIA has officially defined the "Storage-Next" storage architecture specification.

GPU-initiated I/O: In traditional architectures, when a GPU needs data, the CPU initiates a read request, and data travels from SSD through PCIe to CPU memory and then to GPU memory—two hops. Storage-Next lets the GPU initiate I/O directly, with data flowing from SSD straight to GPU memory, bypassing the CPU.

SCADA™ software stack: NVIDIA has defined its own storage software stack for Storage-Next. A GPU vendor defining the storage software stack means NVIDIA is attempting to control the complete vertical stack from GPU to storage media.

3.2 CMX / ICMS: A Dedicated Storage Platform for KV Cache

Source: NVIDIA official page (nvidia.cn/data-center/ai-storage/cmx/) + NVIDIA press release 2026-03-16

ICMS (Inference Context Memory Storage Platform) was officially upgraded to the NVIDIA CMX™ Context Memory Storage brand at GTC 2026, an AI-native context layer for long-context, multi-turn, and agentic AI inference.

The core architecture consists of three components:

STX reference architecture (the productization of Storage-Next) performance targets: Token throughput up to 5×, energy efficiency up to 4×, data ingestion 2×. Early adopters: CoreWeave, Crusoe, Lambda, Mistral AI, Oracle Cloud, Vultr. Storage partners have expanded to 17+ companies.

Micron explicitly stated at FMS 2026: "sessions become multi-turn or agentic, KV cache size expands rapidly." KV Cache is now a persistent object with its own lifecycle—it may be retained after session ends for prefix reuse, multiple Agents may share the same KV Cache segment, and the read/write pattern is a mix of random and sequential.

The storage vendor coalition NVIDIA has assembled for ICMS:

AIC, Cloudian, DDN, Dell, HPE, Hitachi Vantara, IBM, Nutanix, Pure Storage, Supermicro, VAST Data, WEKA

More than 12 companies—virtually all tier-one enterprise storage companies.

3.3 Kioxia's Three Product Lines

What is XL-FLASH? Kioxia's Storage Class Memory (SCM) based on BiCS FLASH 3D technology, filling the performance gap between DRAM and traditional NAND. Key specs: 16-plane architecture (traditional NAND typically 4–8 planes), read latency <5μs, SLC/MLC mode, second generation already in mass production. Productized as the FL6 series SSD: 1.5M random read IOPS, read 29μs, write 8μs, 60 DWPD, 800GB–3.2TB (source: Kioxia official FL6 product specification page).

XL-FLASH Gen2's 10M IOPS @ <25W: an order-of-magnitude IOPS improvement per drive without significantly increasing power consumption. Emulator progress: Phase 1 (August 2025) generated 140M IOPS on GH200; Phase 3 runs on SCADA (requires GH/GB systems; x86 cannot reach 100M IOPS). Gen3's 100M IOPS directly targets the Storage-Next 200M IOPS/GPU goal (referring to aggregated IOPS of the storage subsystem connected per GPU, not a single-drive number—requires multiple NVMe SSDs in aggregate).

3.4 Assessment: GPU Vendors Are Defining the Storage Layer

For storage vendors: Not following NVIDIA's specification risks being excluded from AI inference infrastructure procurement lists.

For SSD controller vendors: The 512B granularity and 200M IOPS requirements demand controller redesign at the architectural level.

For users: Agent infrastructure procurement decisions may further align with the NVIDIA ecosystem.

At a deeper level: GPU vendors defining storage specifications means storage industry influence is shifting. Historically, SNIA defined standards and vendors followed. Now NVIDIA is using its GPU ecosystem leverage to bypass traditional standards organizations, bringing its own storage vendor coalition along. Traditional storage giants that don't join risk being marginalized.

---

IV. The SSD Controller's Agent Moment

The IO granularity shift from 4KB to 512B represents a fundamental change at the NAND physical architecture and error correction algorithm level for SSD controller vendors.

4.1 FEC Architecture Challenge

An SSD's FEC (Forward Error Correction) corrects bit errors during NAND read/write through redundant encoding (typically LDPC codes). Traditional FEC's minimum processing unit is 4KB, matching the NAND physical page size.

At FMS 2026, Microchip pointed out a fundamental contradiction between the 512B–1KB granularity of AI workloads and the 4KB FEC block. Microchip's proposed solution: novel block structure + multi-layer decoding:

1. Fast small block reads: High-SNR pages use lightweight hard-decision decoding, checking only parity bits—extremely low latency.
2. Hard-decision fallback: When hard-decision decoding fails, escalate to soft-decision decoding—multiple reads and iterations.
3. Multi-read soft decoding: In extreme cases, perform multiple reads + soft information fusion + LDPC iterative decoding.

Core idea: Not every 512B block needs full 4KB-level error correction. Layered decoding lets most small-block reads take the fast path, with only a small fraction triggering heavy-weight error correction.

4.2 Phison NN-LDPC: Neural Network-Assisted Error Correction

In its FMS 2026 presentation, Phison showcased a more aggressive solution: using neural networks to assist LDPC error correction.

Traditional LDPC decoding uses fixed iterative algorithms and fixed belief propagation rules. But these rules are optimized for "general error patterns," not for the specific error characteristics of a given NAND flash chip. Phison's approach: use a DNN to learn the specific error distribution of a particular NAND chip, dynamically adjust decoding strategy, and achieve ultra-low-latency error correction in 512-byte small-block scenarios.

This is an NVIDIA Storage-Next-ready controller solution. Phison explicitly positions it as a product targeting the Storage-Next architecture.

4.3 Kioxia DNN-based Read Flow

In another FMS 2026 presentation (Ballroom F, Flash Technology Track), Kioxia demonstrated DNN-based Read Flow: using deep neural networks to dynamically adjust NAND Flash read thresholds on a row-by-row basis.

Traditional approach: globally uniform read threshold voltage (reference voltage). But the optimal threshold varies across different regions, different wear levels, and different temperatures. Kioxia uses a DNN to learn optimal thresholds row by row, replacing globally uniform parameters.

Signal: AI is not just a "consumer" of storage—AI is transforming the firmware design of storage controllers themselves. The competitive differentiation dimension for SSD controllers is shifting from "who has the most capacity, who has the highest bandwidth" to "who delivers more stable IOPS, stronger error correction, and lower p99 in 512B small-block scenarios."

4.4 New SSD Constraints Under Agent Workloads

Agent scenarios impose several new optimization constraints on SSD controllers:

These cannot be solved by parameter tuning—they require controller architecture redesign.

Current maturity assessment: The three technologies above (Microchip 512B FEC, Phison NN-LDPC, Kioxia DNN Read Flow) are all in the engineering verification stage. Phison's NN-LDPC has silicon demonstrations (inferred from FMS presentation content); Microchip's layered FEC architecture has simulation data; Kioxia's DNN Read Flow is still in the experimental stage. Mass production may be 12–18 months away, but the direction is clear: SSD controllers are evolving from "general-purpose signal processors" to "AI-assisted specialized signal processors."

---

V. KV Cache: From Data Structure to Storage Object

The evolution of KV Cache is the best entry point for understanding Agent storage architecture变革. Its changing role mirrors the industry's fundamental shift in understanding "inference state management."

5.1 Three Stages

Stage 1: KV Cache = Inference Engine Internal Data Structure (2023–2024)

vLLM's PagedAttention managed KV Cache as "virtual memory within GPU memory"—eliminating fragmentation and improving concurrency. At this point, KV Cache was 100% in HBM; the storage industry couldn't have cared less. FMS 2024: zero mentions.

Stage 2: KV Cache Spillover Pressure (2024H2–2025H1)

Context windows expanded from 32K to 128K and even 1M tokens. Single-request KV Cache could reach tens of GB (1M context, 70B model ≈ 50GB+). GPU HBM capacity was no longer sufficient.

First response: quantization compression (FP8 KV Cache). Second response: CPU offload. Third response: push to SSD. These were still "engine-internal" solutions.

Stage 3: KV Cache Becomes a System-Level Storage Object (2025H2–2026), the Turning Point

When Prefix Cache appeared and systems discovered that multiple requests shared identical prefixes (system prompts, long documents), KV Cache became a reusable asset. This immediately raised three storage-system-level questions:

1. Naming: How to identify a prefix KV Cache block?
2. Addressing: Is it on HBM, DRAM, or SSD? How to move it before it's needed?
3. Lifecycle: When to evict? How to share across nodes?

At this moment, KV Cache transformed from a data structure into a storage object. FMS 2026 dedicating 7 keynotes to KV Cache is not empty talk.

5.2 SanDisk: The True Complexity of KV Cache Reuse

At FMS 2026, SanDisk's presentation revealed that KV Cache reuse is far more complex than "prefix matching." Existing systems support only longest prefix match, but real workloads contain extensive:

• Partial overlap: Two KV Cache segments share some content in the middle
• Shifted overlap: Identical content appears at different offset positions
• Suffix overlap: Ending portions are identical
• Mid-span overlap: A middle segment is identical, with different beginnings and endings

These scenarios are extremely common in conversational AI, RAG, and templated prompts.

SanDisk proposed a three-layer architecture: segment tree + composable rolling hashes + prefix/suffix tries + coarse block hash, enabling detection and verification of arbitrarily reusable token ranges. Results: 30% reduction in prefill latency, 2× KV reuse.

KV Cache's "storage system"属性 is stronger than imagined. It is not merely a cache—it is a persistent object requiring fine-grained indexing, efficient retrieval, and lifecycle management.

5.3 Micron: Measured Data

Micron shared measured KV Cache offload data at FMS 2026 (measured evidence, not PPT):

• KV Cache defined as "attention memory LLMs build during prefill"
• Explicitly mentioned "agentic sessions" causing KV Cache expansion
• KV Cache IO pattern is "mixed random and sequential"
• Tiered memory system + low-cost fast persistent storage layer can substantively improve performance and CapEx returns

This was one of the few presentations with measured data. Micron's wording is noteworthy—drive-level optimization targeting KV Cache's mixed access pattern indicates SSD vendors have already begun adapting firmware-level designs for Agent workloads.

5.4 SanDisk KV Cache Reuse Architecture

SanDisk's three-layer architecture deserves detailed expansion:

The three-layer filtering design ensures fast retrieval in large-scale KV Cache pools—coarse screening first, then precise matching—avoiding full comparison of every KV Cache segment.

---

VI. Five Architecture Patterns for Long-Running Agents

As Agents move from "single Q&A" to "long-running," state persistence becomes a core challenge. The following five patterns represent the current solution space.

Pattern 1: Checkpoint-and-Resume

Core idea: Periodically write Agent state to persistent storage; recover from the most recent checkpoint after a crash.

Practice: For example, persist state every 30 documents processed. When an Agent executes a 1000-step task, at most 30 steps of progress are lost.

State persistence strategy: Periodic full snapshots. Each checkpoint is a serialization of the Agent's complete state (context + plan + intermediate results).

Pros and cons: Simple and direct; but the checkpoint interval is a performance-vs-safety trade-off—too frequent hurts throughput, too sparse loses too much progress. Full snapshots generate heavy write volume in high-frequency scenarios.

Pattern 2: Delegated Approval (Human-in-the-Loop)

Core idea: The Agent pauses at critical decision points, waits for human approval, then continues.

State persistence strategy: Freeze state at the pause point, persist to external storage. Unfreeze after human approval.

Pros and cons: High security, suitable for high-risk scenarios (financial trading, code deployment); but human approval is a synchronous block that significantly extends Agent task execution time. Requires that state does not expire during the frozen period.

Pattern 3: Session-as-Event-Log

Core idea: See Path 4 (Anthropic pattern). Agent state is not a "current snapshot" but a "historical event sequence." Current state = the result of replaying all events from the starting point.

State persistence strategy: Append-only event log + periodic checkpoints (for fast recovery, not the sole source of truth).

Pros and cons: Simple crash recovery (replay the log); natural audit trail (the log is the record); but long sessions cause log volume to grow linearly, and replay time grows accordingly.

Pattern 4: Sandbox Isolation

Core idea: Each Agent tool call executes in an independent sandbox.

Representative implementations: E2B (open-source Agent sandbox platform), Tencent Agent Runtime (60ms cold-start sandbox), Anthropic Managed Agents (fresh microVM per tool call).

State persistence strategy: The sandbox itself has no persistence. Execution results are serialized and written back to external storage (typically an event log or checkpoint). The sandbox handles compute isolation only, not state retention.

Pros and cons: Extremely high security (sandbox is used and destroyed); good elasticity (stateless instances can be scheduled freely); but sandbox startup overhead is the key constraint. Tencent achieves 60ms cold start, E2B is also in the sub-100ms range, and Anthropic's microVM solution latency data is not publicly disclosed, but p50/p95 first-token latency improvements are significant.

Pattern 5: Google Agent Runtime (7-Day State Retention)

Core idea: Agent Runtime keeps Agent processes running server-side for up to 7 days, with state held in memory—no need to recover from scratch each time.

State persistence strategy: Runtime memory retention + background periodic persistence. Sits between pure-memory and pure-log approaches.

Pros and cons: Lowest latency (no checkpoint recovery needed). But 7 days of memory occupancy is a real cost. Google must have scheduling strategies for idle Agents (presumably background auto-persistence followed by memory release)—they would not let resources truly idle for 7 days. Suitable for high-value long-running Agents; not suitable for massive-scale, low-cost scenarios.

Comparison of Five Patterns

---

VII. AIOS: Academic Exploration of an Agent Operating System

If Agents need an operating system, what would that OS look like? The AIOS (Agent IO System) paper offers a conceptual architecture.

7.1 Core Architecture

AIOS's design directly analogizes traditional operating systems, but every component is redesigned for Agent working patterns:

Core components:

1. LLMCore: Manages scheduling and resource allocation for the underlying LLM inference engine. Similar to a traditional OS's CPU management—context switching, time-slicing, priority scheduling.
2. Agent Scheduler: Determines which Agent gets inference resources and when. During multi-Agent concurrency, the scheduler must balance latency, fairness, and throughput.
3. Context Manager: Manages the Agent's context window—what content is in-window, what is out-of-window, and when content enters or leaves. This is essentially virtual memory management.
4. Memory Manager: Manages the Agent's long-term memory—how historical information beyond the context window is stored, indexed, and retrieved.
5. Storage Manager: Manages the Agent's persistent state—checkpoints, event logs, tool call results.
6. Tool Manager: Manages the Agent's available tools—registration, discovery, permission control, call execution.

7.2 Fundamental Differences from Traditional OS

The AIOS analogy is inspiring, but there are several fundamental differences to note:

Different scheduling granularity: Traditional OS scheduling deals with instruction streams (microsecond-level time slices); AIOS scheduling deals with reasoning steps (seconds to minutes). Scheduling overhead itself may not be negligible: spending 100 milliseconds deciding who reasons first is a high overhead ratio if the reasoning itself only takes 500 milliseconds.

Different "memory" semantics: Traditional OS memory management is based on fixed-size pages (4KB); AIOS context management deals with variable-length semantic fragments. Page scheduling algorithms cannot be applied directly.

Different "file" lifecycles: Traditional files persist once created until deliberately deleted. Much of an Agent's state consists of intermediate artifacts—useful within their lifespan, garbage after expiration. AIOS needs built-in state lifecycle management; it cannot rely on users for manual cleanup.

7.3 Limitations

AIOS is currently at the proof-of-concept stage, open-sourced at github.com/agiresearch/AIOS. Its value lies not in product-grade implementation, but in providing a systematic framework for thinking about "what an Agent OS should look like." This framework serves as a reference for subsequent technical development, even if the eventual industrial implementation may differ entirely from the paper.

---

VIII. Industry Landscape: Who Is Doing What

The transformation of Agent storage architecture is reshaping the storage industry value chain. Different categories of players are entering from different angles, each with different motivations and capability boundaries.

8.1 Storage System Giants

Representatives: Dell, Pure Storage, NetApp, VAST Data, IBM

Core motivation: Upgrade from "training-era boxes" to "Agent workflow platforms."

Actions: Dell and Pure Storage have joined the NVIDIA ICMS coalition. VAST Data is building integrated data governance solutions—not just storing data, but managing its lifecycle, lineage, and permissions. IBM, in addition to joining ICMS, is pushing Cognitive File System.

Actual progress: Data governance integrated solutions have been delivered, but Agent scenario components are still early-stage. These giants' strengths are channel and customer relationships; their weakness is software iteration speed.

8.2 SSD / Controller Vendors

Representatives: Samsung, Kioxia, Phison, Micron, SanDisk, Microchip

Core motivation: Agent random IO = new IOPS selling point. Shift from bandwidth competition to latency and IOPS competition.

Action overview:

Assessment: The competitive differentiation dimension for SSD controller vendors is shifting. The old comparison of capacity and bandwidth is giving way to who delivers more stable IOPS, stronger error correction, and lower p99 in 512B small-block scenarios. This creates overtaking opportunities for controller specialists like Phison.

8.3 GPU Vendors

Representative: NVIDIA

Core motivation: Storage ecosystem dominance. Pull storage into their inference full-stack.

Actions: Storage-Next + ICMS + SCADA software stack. What NVIDIA is doing goes beyond defining storage specifications—they are defining "the data center architecture of the AI inference era." GPU, DPU, network, storage—the full stack.

8.4 Agent Platforms

Representatives: Anthropic, Google

Core motivation: Runtime-level state management. Agent state management should not be the application layer's responsibility—it should be a built-in capability of the Runtime.

Actions: Anthropic's Managed Agents (Session-as-Event-Log + microVM Sandbox) is running in production. Google's Agent Runtime supports 7-day state retention.

Assessment: Agent platform companies are doing what storage system companies should be doing: state management. Traditional storage companies neither have the capability nor should they be building Agent-level state management. The eventual form will likely be: Agent platforms build state management abstractions, with underlying infrastructure provided by storage system vendors.

8.5 China

Representative: Tencent Agent Runtime

Actions: 60ms cold-start sandbox. This number is noteworthy—if every Agent tool call requires a sandbox launch, 60ms cold start means the per-call sandbox overhead is acceptable (compared to Anthropic's microVM solution, latency improvement data indirectly confirms a similar order of magnitude).

Position of Chinese storage vendors: No Chinese storage vendors appear in the FMS 2026 ICMS coalition. This does not mean Chinese vendors lack opportunities in Agent storage—China has the world's largest inference workloads (based on deployment volumes of open-source model inference), and market demand is real. But at the standards-definition and ecosystem-dominance level, Chinese vendors are currently followers.

---

IX. Assessment and Risks

9.1 Already Happening

KV Cache has transformed from an engine-internal data structure to a cross-tier storage object. The emergence of Prefix Cache is the watershed. NVIDIA's ICMS, Micron's measured data, SanDisk's reuse indexing—these have all passed product-level validation. FMS 2026 dedicating 7 keynotes to KV Cache is not empty talk.

SSD IO granularity is changing. Microchip's 512B FEC proposal, Phison's NN-LDPC, Kioxia's DNN Read Flow—these are not PPT slides; they are chip- and firmware-level engineering implementations.

Agent Runtime state management patterns are converging. Anthropic's Session-as-Event-Log + Sandbox model is running in production. Google's 7-day state retention is also running. Tencent achieved 60ms cold-start sandbox. Patterns are converging, not diverging.

9.2 Being Narrated but Not Yet Fully Happening

Cognitive File System. IBM's proposal points in the right direction, but the distance from FMS agenda to production deployment is significant. Currently placed in the Computational Storage Track, indicating industry attention is still limited.

Full NVIDIA Storage-Next deployment. Specification defined, partners in place, but Kioxia's GP Series won't have evaluation samples until 2026. From specification to large-scale deployment typically takes 2–3 years.

Large-scale CXL deployment in Agent scenarios. Technical logic holds. CXL 2.0 protocol-level transaction latency is approximately 20–40ns (compared to PCIe 5.0 at ~100ns), end-to-end latency including root complex overhead approximately 170–250ns. Byte-addressable, load/store semantics. NVIDIA Vera CPU natively supports PCIe Gen6 / CXL 3.1 (88-core Olympus, 1.5TB LPDDR5X, NVLink-C2C 1.8TB/s)—the CPU-side maturity prerequisite is being met. However, CXL-aware data placement policies for Agent frameworks remain absent, requiring 1–2 more years of validation.

9.3 Risks

CapEx correction risk. Analyst Jim Handy's warning at FMS 2025 about unsustainable hyperscale data center capital expenditure remains valid. If AI infrastructure investment enters a correction period in the second half of 2026, the Agent storage narrative may experience an awkward window of "PPT first, deployment lagging."

Actual Agent deployment pace. Agent deployment scale in production is currently far smaller than inference (inference), with most Agents still in POC stage. The storage industry's Agent narrative heat may lead actual deployment demand by 1–2 years.

Standards fragmentation. NVIDIA is defining its own standards with Storage-Next + ICMS + SCADA. IBM is pushing Cognitive File System. SNIA is pushing Computational Storage standards. Without unified standards, storage vendors may face a "which camp to choose" dilemma, increasing market fragmentation.

NVIDIA ecosystem lock-in. If NVIDIA successfully defines the complete stack from GPU to storage media, users' options will be compressed. Choosing the NVIDIA storage ecosystem today may carry extremely high exit costs tomorrow.

---

X. Epilogue: From "Everything Is a File" to "Everything Is Context"

In 1969, Unix proposed "everything is a file." This design philosophy was extraordinarily successful—it provided a unified interface for accessing files, devices, networks, and process information. For half a century, nearly every operating system has adopted some form of "everything is a file."

But Agents are not Unix users.

Agents don't need paths; they need content. They don't need filenames; they need patterns. They don't need directories; they need relevance. Agent working patterns—continuous observation, multi-step reasoning, tool invocation, state tracking—are fundamentally different from how humans consume information.

From "everything is a file" to "everything is context"—this is not a name change; it is a migration of information management paradigms.

This migration is advancing simultaneously across multiple paths: Anthropic bypasses the file system with event logs and microVMs; IBM attempts to transform the file system from within the kernel; NVIDIA uses GPU ecosystem influence to define a new storage layer; academic researchers propose the theoretical framework of "everything is context."

These efforts share one direction: make storage systems understand the data they store; let Agents efficiently consume the information they need.

When Karpathy said the LLM is the CPU and the context window is RAM, he left something out: every CPU needs an operating system to manage its RAM. The Agent's operating system is being invented. It may not be called an "operating system," it may not look like Linux, and it may not be any existing company's product today. But it will appear.

Because the problem is right there. Who manages the Agent's RAM? Who decides what goes in and out? When the Agent stops running, where are its memories saved?

It will appear, and likely faster than expected—because GPU vendors, storage vendors, and Agent platforms are already building its different components independently.

---

Sources

Primary sources (FMS 2026 official agenda):

• Session: "Hierarchical Span Indexing for Generalized KV Cache Reuse" — SanDisk (Vishwas Saxena, Mukesh Kumar)
• Session: "Optimizing KV Cache Offload for Scalable, Cost-Efficient AI Inference" — Micron (Rohan Mehta)
• Session: "SSD Error Correction Optimization for AI Workloads" — Microchip (Peter Graumann)
• Session: "Enabling Ultra-High-IOPS Storage-Next SSDs with AI-Enhanced LDPC" — Phison (Sean Lin)
• Session: "Cognitive File System" — IBM (Viacheslav Dubeyko)
• Session: "DNN-based Read Flow for NAND Flash Controllers" — KIOXIA (Eyal Nitzan)
• Session: "Fixed Function Compute Standardization" — KIOXIA (Devesh Rai)
• Session: "Enhancing Enterprise Drive Reliability by Joint LDPC & XOR Decoding" — SanDisk (Alex Bazarsky)
• Session: "High-Density SSD Design in Supply-Constrained Deployments" — Solidigm (Tahmid Rahman)
• FMS 2026 official agenda: https://www.terrapinn.com/conference/future-memory-storage/agenda.stm

Company public information:

• NVIDIA Storage-Next / ICMS / SCADA: Kioxia FMS presentation materials
• Anthropic Managed Agents: Anthropic official technical documentation
• Kioxia GP Series / CM Series / LC Series: Kioxia product roadmap
• IBM Cognitive File System: Viacheslav Dubeyko, "File System in Data-Centric Computing," arXiv 2019; FMS 2026 proposal

Industry signals:

• LlamaIndex: "Files Are All You Need" (Jerry Liu public talk)
• LangChain Agent architecture pivot
• arXiv: "Everything is Context"
• AIOS: github.com/agiresearch/AIOS

Analytical references:

• Jim Handy (Objective Analysis), "11 Key Changes Coming," FMS 2025
• Kioxia, "Optimizing AI Infrastructure Investments with Flash Memory," FMS 2025
• deephub: "Long-Running Agent Architecture Patterns"

---

For the trend overview, see the companion piece: "When Storage Becomes Agent Working Memory: FMS Three-Year Shift."

Not investment advice. Data as of July 17, 2026. FMS 2026 has not yet convened (August 4–7); agenda analysis is based on official preview information. NVIDIA CMX/STX data from NVIDIA official pages and 2026-03-16 press release. Kioxia XL-FLASH/FL6 data from Kioxia official product specification pages. CXL latency data from CXL Consortium specifications and public technical analyses. Vera CPU data from NVIDIA developer blog (2026-01-05).