OVOpenViking / context database
GitHub ↗
A field guide for curious humans

Context,
with a filesystem
attached.

OpenViking is an open-source context database for AI agents. It brings memory, knowledge and skills together under one navigable viking:// namespace.

Imagine giving an agent a well-organised archive it can browse, inspect and learn from — instead of handing it a bag of retrieved chunks.
Based on the OpenViking repository and official docsgithub.com/volcengine/OpenViking ↗
01 / 13
TL;DR

It gives an agent a place to remember, browse and improve.

OpenViking unifies three kinds of context — user memory, project resources and reusable skills — into a virtual filesystem. The agent can navigate that context with familiar operations such as ls, tree and find.

Before
Context is scattered
One context home
Before
Retrieve a chunk
Navigate a subtree
Before
Load everything
Load detail on demand
Before
Debug the answer
Inspect the path taken
Benefit 01

Less context waste

Three information layers let an agent check relevance before loading full detail.

Benefit 02

Better context shape

Directory-level summaries preserve where information belongs, not just what it says.

Benefit 03

More observable recall

Retrieval trajectories show how the system arrived at a result.

02 / 13
The problem it addresses

Agents don’t just need answers.
They need context operations.

A long-running agent has to locate the right knowledge, decide how much to load, reuse skills, retain useful experience and explain its path. OpenViking treats those as one context system.

01
LocateFind the right branch of context.
02
OrientUnderstand what a branch contains.
03
LoadRead detail only when useful.
04
ActUse a resource or skill in the task.
05
CommitTurn useful session experience into memory.
03 / 13
Mental model

One namespace.
Three context types.

OpenViking presents context as a virtual filesystem. The important shift is structural: memory, resources and skills can live alongside one another, with stable viking:// URIs.

Project docs, repositories, web pages and other source material the agent may need.

viking://resources/filesystem view
├── my_project/
├── docs/
└── api/
└── tutorials/
└── src/
# directories carry semantic summaries
04 / 13
Progressive disclosure

Don’t pour the whole archive into the prompt.

OpenViking creates a three-layer information model. An agent can start with a short abstract, orient itself with an overview, then open the original detail only when the task warrants it.

L0 · Abstract
256 characters

A quick relevance check. Enough to decide whether this directory is worth opening.

L0

Short semantic signal for vector retrieval and quick filtering.

L1

Broader directory summary for reranking and navigation.

L2

Original files and subdirectories, loaded on demand.

05 / 13
Retrieval

Search becomes a path.

OpenViking uses two retrieval modes. find() is the low-latency option for a simple query. search() can analyse a complex task, create typed queries and retrieve across context types.

Use when you already know the kind of thing you want and need a lower-latency query.

OAuth authentication
MatchedContext
A ranked context with its URI, type, abstract and score — ready to inspect.
low latencysession not required
global recall
directory drill-down
rerank
06 / 13
Architecture

A context database with a clean centre.

The client delegates to services for filesystem operations, retrieval, sessions, resource import and debugging. Content lives in AGFS; the vector index stores references, vectors and metadata rather than the file content.

Inputs
ClientSDK · CLI · HTTP
Agenttask + session
ResourcesPDF · MD · HTML · media
Service layerClick a module to inspect its role.
Retrieveintent · recursion · rerank
Sessionrecord · compress · commit
Parseextract · tree-build · semantics
Storage
AGFScontent + L0/L1/L2
Vector indexURIs · vectors · metadata
Observertrace the path
07 / 13
The self-evolving loop

A good session doesn’t have to disappear.

When a session commits, OpenViking can compress the conversation, archive older history, extract memories according to policy and write them back into storage.

That makes memory a write path, not a separate afterthought.

01 · messages
Accumulate conversation messages and usage records.
02 · compress
Keep recent rounds and archive older messages.
03 · archive
Generate L0/L1 for history segments.
04 · extract
Identify memories using policy and memory schemas.
05 · store
Write to AGFS + vector index.
08 / 13
Evidence, with caveats

The repository reports measurable gains in its own evaluations.

The README describes OpenViking 0.3.22 evaluations on long-conversation memory and multi-turn agent tasks. Read these as reported benchmark results, not universal guarantees.

LoCoMo / OpenClaw
24.20 → 82.08%

Reported memory accuracy with OpenViking versus native memory.

Input tokens
−34.3–91.0%

Reported reduction across the three agent integrations.

tau2-bench / airline
+11.87 pp

Reported task-success lift from experience memory.

The README also reports query-latency reductions of 58.45–66.10% and other integration-specific results. Models, datasets and setup details are part of the benchmark context.

09 / 13
Use cases
01 · Research notebook
“Remember the work. Show me the path.”

Keep papers, notes, experiments and reusable analysis skills in one browseable context space — then retrieve the right level of detail for the next question.

These are design patterns inferred from the repository’s context types, retrieval, session and multimodal capabilities. They are examples, not product claims.

10 / 13
How-to guide

A practical first run, from zero to first retrieval.

The simplest route is a local Python installation. The official quick start also documents Docker for running OpenViking as an independent service.

01Prerequisite

Prepare Python

Use Python 3.10 or higher. A stable network connection is needed for dependencies and model services.

python --version
02Install

Install the package

Choose a package manager. The docs recommend uv; pip and pipx are also documented.

uv tool install openviking --upgrade
03Configure

Initialise and diagnose

The wizard writes the config and helps choose provider/model settings. Doctor checks setup before the server runs.

openviking-server init
openviking-server doctor
04Start

Run the local server

Start OpenViking, then use a second terminal for the client or CLI.

openviking-server
curl http://localhost:1933/health
05Ingest

Add a resource

Import a URL, file or directory, and wait for semantic processing before inspecting it.

ov add-resource \
  https://github.com/volcengine/OpenViking --wait
06Explore

Browse and search

Use the filesystem view to learn the shape of the context, then run a semantic query.

ov tree viking://resources/volcengine -L 2
ov find "what is openviking"
11 / 13
After the first run

Start with a context service.
Then give your agent a memory contract.

OpenViking documents integrations for developer tools and agent frameworks including Claude Code, Codex, Cursor, OpenCode, Hermes, LangChain / LangGraph, MCP clients and more.

Read integrations ↗

from openviking_sdk import SyncHTTPClient

client = SyncHTTPClient(
    url="http://localhost:1933"
)
client.initialize()

results = client.find(
    query="how to use openviking",
    target_uri="viking://resources/"
)

client.close()
Make it useful

Decide what belongs in memory, resources and skills before you ingest everything.

Make it testable

Evaluate retrieval quality, token usage, latency and the paths that produced results.

Make it safe

Set provider, access, storage and privacy boundaries before a shared deployment.

12 / 13
Use judgement

Useful infrastructure still needs boundaries.

OpenViking makes context more navigable and observable. It does not remove the need for good ingestion, model selection, access control, evaluation or data governance.

  • Model services
    Semantic processing and retrieval quality depend on configured VLM, embedding and optional rerank services.
  • Async processing
    After ingestion, semantic processing may need to finish before the context is ready to inspect.
  • Deployment shape
    Local, standalone HTTP and Docker paths have different operational and network considerations.
  • Licensing
    The repository states that its main project is AGPLv3, with different licences for some components.
Check before shipping
Context is an operating surface.

Treat provenance, permissions, retention, prompt injection and benchmark design as first-class product work.

13 / 13