OpenViking

OpenViking is Volcengine’s open-source context database for AI agents. Knowledge, memory and skills go into one virtual filesystem under viking:// URIs, which an agent walks the way it walks a disk.

Two properties stand out: everything retrievable can be opened and edited, so it is not a black box, and content loads in layers, so the agent reads a directory summary before opening the full source.

What it actually is

Three types, each on its own path:

• Resources (viking://resources/): documents, repositories, web pages.
• Memories (viking://user/{user_id}/memories/): preferences, entities, events and experience extracted from sessions; peer-specific context sits under peers/{peer_id}/.
• Skills: reusable workflow instructions, shared ones under viking://agent/skills/.

Each item gets a viking://{scope}/{path} URI; viking://~/ is the caller’s own space.

Layers: L0 is the directory abstract (.abstract.md), L1 the overview (.overview.md), L2 the original content. L0 and L1 are directory sidecars rather than a summary per file, and they appear neither instantly nor for every directory.

Storage is two-layer: content in the RAGFS filesystem, vectors and metadata in the index. Parsing makes no LLM calls; semantic generation is asynchronous.

Retrieval and memory

find runs a single query without session context; search starts from the conversation, analyses intent, generates typed queries, walks the directory tree with a priority queue and then reranks. A search can be scoped to a subtree. The rerank step needs a Volcengine backend; without one the system falls back to vector scores.

Memory is built from sessions: messages go into a session and commit() archives the conversation synchronously, then generates summaries and extracts memories in the background. Types include profile, preferences, entities, events, identity, cases and experiences, and each commit writes a memory_diff.json with the added, updated and deleted memories.

The API is HTTP-based, with Python, Go and TypeScript SDKs and an MCP endpoint on the same port (/mcp).

Running it

• openviking-server init writes ~/.openviking/ov.conf, and doctor checks configuration and connectivity. Providers include Volcengine, OpenAI, Codex OAuth, Kimi, GLM and local Ollama.
• The server listens on 127.0.0.1:1933, reports liveness on GET /health and readiness on GET /ready, which also verifies the filesystem, vector database and embedding.
• The official image ghcr.io/volcengine/openviking needs one mount (~/.openviking:/app/.openviking), serves the API and the studio UI on the same port, and starts the VikingBot gateway unless --without-bot is passed.
• Bound to 0.0.0.0, it requires root_api_key and refuses to start without it; the repo ships a systemd unit, compose file and Helm chart.
• The main project is AGPLv3; the CLI crate and examples are Apache 2.0.

Where it fits, and what to watch

OpenViking keeps our retrievable context and long-term memory. The agent is Hermes Agent, tools come through MCPHub, and time-aware graph memory is kept by Graphiti.

The docs name limits:

• Embedding is required, memory extraction needs a VLM, so processing depends on external model providers.
• Python 3.10 or newer, and the RAGFS binding has to be built with a Rust toolchain when it is not in the wheel.
• Behind a reverse proxy, OPENVIKING_PUBLIC_BASE_URL must be set, or upload URLs point at the internal address.
• The docs flag parent summary refresh bubbling upward after every successful task, which can cause write amplification in deep, busy trees.

Further reading

• OpenViking on GitHub: the README, the quick start and the integration list.
• Introduction: context types, the layer model and session-based memory.
• Architecture Overview: the service layer, two-stage retrieval and storage.

CyberElectro keeps recurring project context and the background of past decisions in OpenViking, so a new session does not start from zero.