Volcengine releases OpenViking — a file-based context store for AI agents like OpenClaw

Volcengine has open-sourced OpenViking — a context database for AI agents, including systems like OpenClaw. The project proposes storing memory, resources, and skills not in scattered vector indices, but in a hierarchy similar to a regular file system.

Context as a file system

The main idea behind OpenViking is that it is awkward for an agent to work with context as a flat set of text chunks. In a typical RAG pipeline, documents live separately, user memory lives separately, and tools and skills live elsewhere altogether. Because of this, it is hard for a developer to understand exactly what the agent saw, why it chose one fragment or another, and where to look for an error if the answer turned out weak. OpenViking tries to bring all of this into one model — a virtual file system with `viking://` addresses.

• `viking://resources` — documentation, repositories, web pages, and other external knowledge
• `viking://user` — memory about the user, their habits, and preferences
• `viking://agent` — the agent’s own skills, instructions, and working memory
• `.abstract` — a short L0 layer for quickly checking relevance
• `.overview` — an L1 layer with an overview before reading the full content

Within this structure, different types of context are arranged into directories with clear URI, and the agent can access them almost like a developer accesses local files.

As a result, context stops being a black box. Instead of the abstract idea that something was found via embedding, you get understandable navigation: the agent can browse the tree, read specific files, search within a directory, trace the path to the needed fragment, and more precisely control what ends up in the prompt.

Less noise in the prompt

Another key mechanism in OpenViking is three-level context loading. When writing, the system does not just place a file into an index, but asynchronously prepares several representation levels. L0 is a one-sentence summary, L1 is an overview with a semantic distillation and usage scenarios, L2 is the original full material. The agent first sees the compact levels and only then, if needed, drills down into the details. This approach reduces token consumption and cuts noise in long tasks.

Under the hood, OpenViking separates parsing from semantic processing. Documents are first converted into a structured form, and then a separate queue handles overview generation and vectorization. This makes it possible to import not only Markdown or text, but also PDF, HTML, Word, PowerPoint, Excel, EPUB, images, audio, and video. For code, there is a separate tree-sitter mode: the system can extract the structural skeleton of files in Python, JavaScript, TypeScript, Rust, Go, Java, and C/C++, so it does not spend extra LLM calls where an AST skeleton is enough.

Search and memory

Search in OpenViking is not built as a single vector query across the entire database. The system first analyzes intent, then quickly finds the directory most likely to contain the right answer, after which it refines the search within that directory and, if necessary, descends deeper into subdirectories. The developers call this directory recursive retrieval. The point is that the agent is not only searching for a similar text fragment, but also understands the context in which that fragment exists. This improves accuracy and makes the output less random.

Observability is also important. OpenViking stores the search trajectory across directories, so you can see exactly where the agent went and at which step it took a wrong turn. For teams debugging agent systems, this is more useful than a standard RAG log with a few score values.

The project also includes long-term memory: after a session, the system can asynchronously extract facts from dialogues, tool calls, and task results, and then update the memory of both the user and the agent itself.

A practical scenario has already been shown using OpenClaw. There is a plugin for it that uses OpenViking as a long-term memory backend, imports resources and skills into the corresponding `viking://` spaces, and then gives the agent separate commands for search, saving memories, and opening archives. In other words, the project does not look like an abstract research idea, but like an infrastructure layer that can already be connected to real agents in working pipelines.

What it means

OpenViking shows that the agent infrastructure market is moving away from the primitive chat plus vector database scheme toward more manageable memory with hierarchy, tracing, and a long-lived mode. If the approach takes hold, developers will design agent memory as deliberately as they now design file structures, API, and databases.