Volcengine releases OpenViking, a file-based context database for AI agents like OpenClaw

Volcengine has released OpenViking as open source: a context database for AI agents, including systems like OpenClaw. The project stores memory, resources and skills not in scattered vector indexes but in a hierarchy that resembles an ordinary file system.

Context as a file system

OpenViking's core idea is that working with context as a flat set of text chunks is awkward for an agent. In a typical RAG pipeline, documents sit in one place, user memory in another, and tools and skills live somewhere else entirely. That makes it hard for a developer to see what exactly the agent saw, why it picked a particular fragment, and where to look for the error when an answer turns out weak. OpenViking tries to reduce all of this to a single 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 a quick relevance check
• .overview — an L1 layer with an overview before reading the full content

Within this structure, different types of context are sorted into directories with readable URIs, and the agent can access them almost the way a developer works with local files. This stops context from being a black box. Instead of a vague "something matched by embeddings," there is clear navigation: the agent can browse the tree, read specific files, search within a directory, track the path to the right fragment and control more precisely what goes into the prompt.

Less noise in the prompt

Another key mechanism in OpenViking is three-tier context loading. On write, the system does not simply drop a file into an index; it asynchronously prepares several levels of representation. L0 is a one-sentence summary, L1 is an overview with a distilled summary and usage scenarios, and L2 is the original full material. The agent first sees the compact levels and drops into the details only if needed. This approach reduces token use and cuts noise in long tasks.

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

Search and memory

Search in OpenViking is not a single vector query across the whole database. The system first analyzes intent, then quickly finds the directory most likely to hold the answer, refines the search inside that directory and, if necessary, descends deeper into subdirectories. The developers call this directory recursive retrieval. The point is that the agent looks not only for a similar piece of text but also understands the context that piece sits in. This improves accuracy and makes results less random.

Observability matters separately. OpenViking saves the search trajectory through directories, so you can see where the agent went and at which step it took a wrong turn. For teams debugging agent systems, this is more useful than a typical 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, then update the memory of the user and of the agent itself.

A practical scenario is already demonstrated with OpenClaw. A plugin 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 searching, saving memories and expanding archives. So the project looks less like an abstract research idea and more like an infrastructure layer that can already be connected to real agents in working pipelines.

What this 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 catches on, developers will design agent memory as deliberately as they design file structures, APIs and databases today.