Abstract

AI is moving from single-turn chat models to always-on networks: systems that run across tasks, call tools, and carry state from one application to another. Compute dominates that conversation. What the network still lacks is a layer that is easy to ignore, storage. Model weights, corpora, execution traces, and the state an agent must keep between sessions all have to be held, retrieved, and priced. If that storage is locked inside one vendor or one session, intelligence starts from zero every time, and the side that actually holds the data never enters settlement.

Linka Labs treats storage as a first-class resource beside compute, and schedules it inside the AI network. The protocol is not another hard drive. It asks which objects should stay available to the network, which context should persist across jobs, and which class of storage incentives should follow. By registering AI-relevant storage as schedulable objects and ranking them with public weighting signals, Linka gives the network a storage layer that can be allocated, incentivized, and audited, so intelligence can accumulate, not merely complete one inference.

1. Introduction: When AI Networks Need Storage

1.1 From a single Q&A to an always-on network

AI is leaving the pattern of “send one prompt to one model, close the window, done.” Systems now read many sources, call tools, stitch work across apps, and must still recognize the state they left last time.

That changes what infrastructure means. In training and early inference, compute and storage meant GPU scale, training throughput, and parameter count. In a network that stays up, continuity depends on whether state and data can be stored, fetched, and used again. One inference can finish on a chip. Whether the next inference still knows this network depends on storage.

The AI economy therefore needs more than more compute. It also needs more than files dropped on Arweave or IPFS, or vectors dropped into a single Web2 database. It needs storage scheduling for AI workloads: which objects stay available to the network, and which side incentives follow.

1.2 A larger window is not a storage layer

Stuffing all history into the prompt does not replace scheduled storage, for at least three reasons:

1. Cost and latency. Putting full history and background into every prompt makes compute and API cost grow with length. High-frequency jobs cannot bear it.
2. The window is not memory. Longer prompts weaken recall of what sits in the middle. That is not the same as “remembered.”
3. Silos. Preferences, domain knowledge, and process state piled up in App A never leave that wall. App B and other systems cannot inherit them.

External retrieval is not a scheduling layer either. Most RAG stacks pull from unverified sources, so good corpora, stale material, and crafted junk can enter the model side by side. What is missing is not another search pass. It is whether an object is registered, whether it has weight, and whether incentives land on storage the network actually uses.

1.3 Why storage scheduling has to be its own layer

First, it must be schedulable across systems. Future AI apps will stitch state across models, tools, and data sources. A single window or a closed database cannot give network-level mobility.

Second, storage must be priced. Compute already has a bill. The side that holds weights, corpora, and state has been treated as a free add-on. Without scheduling there is no public record that this storage worked for the network, and no basis for settlement.

Third, incentives must follow the resource. People who contribute reusable data and verifiable context should not be extracted by the platform for free. Register AI-relevant storage as network objects and rank them with public weight, and supply, support, and consumption can close.

Linka Labs therefore narrows the problem from “a private memory box for agents” to a lower line: schedule storage for the AI network.

2. Design Principles