# Deep Dive into OpenHuman and OpenViking: How Should Agents Build Long-Term Memory?

Core question answered in this article: How can AI agents acquire long-term, stable, and maintainable context to finally break free from the curse of “amnesia”?

If we compare current AI applications to the dream-building process in the movie Inception, we’ve spent the last year doing exactly one thing: frantically training the logic of the dreamers (Large Language Models) while completely ignoring the physical architecture of the dreams themselves. The moment a conversation ends, the dream collapses, and all context instantly resets to zero.

OpenHuman and OpenViking, two projects recently lumped together in tech discussions, are attempting to answer this ultimate question: how do we build real, persistent physical memory for AI? But if you analyze them as direct competitors, you will entirely miss the evolutionary trajectory of their underlying technology.

OpenHuman is not building just another chatbox. Essentially, it is productizing the LLM Knowledge Base / Obsidian Wiki concept previously mentioned by Andrej Karpathy, leaning heavily toward a personal AI assistant experience. OpenViking, on the other hand, operates on a much lower level, dedicated to building context infrastructure for Agents—a pure Agent context database.

One is building a visible, tangible “dream palace” for ordinary people; the other is writing the “laws of physics” that keep the dream from collapsing.

Image Source: Unsplash

## Why Do We Need to Re-examine Agent “Memory”?

Core question answered in this section: Why do standard RAG pipelines and short-term conversation mechanisms fail to support the long-term operation of Agents?

Before diving into these two projects, we must face the pain points of current AI memory mechanisms head-on. The standard RAG (Retrieval-Augmented Generation) pipeline is familiar to everyone: chunk a document, create embeddings, perform a top-k search in the vector database, and stuff the results back into the prompt.

This pipeline works perfectly for “single-document Q&A,” but it exposes fatal flaws when facing an Agent with a continuous lifecycle: it is flat and disconnected.

Imagine you are managing a complex project spanning three months. Your emails contain changing client requirements, your Notion holds the architecture docs, your GitHub records code commits, your Slack logs team debates and compromises, and your Calendar is packed with meetings.

Under traditional chunking logic, this highly time-bound and logically interconnected data is sliced into countless equal, unrelated text blocks. When an Agent tries to answer, “How did this requirement originally come about?” it can only blindly pick up a few highly similar fragments, completely unable to reconstruct the big picture.

This is the first major conflict: Human memory is networked, three-dimensional, and timestamped. Machine memory is flat and isolated.

>

Reflection / Unique Insight:
In the past, we often complained that LLMs were “dumb.” But in reality, the model’s comprehension capability is often not the issue; the context we feed it is simply a tangled mess. Unstructured memory isn’t memory—it’s an information dump. Trying to find clues in a dump will drive even the smartest mind crazy.

## OpenHuman: Compressing Your Digital Life into an “External Brain”

Core question answered in this section: How does OpenHuman transform scattered personal data across various platforms into structured context that AI can directly utilize?

OpenHuman’s solution is productization. It doesn’t debate the complex algorithms of underlying indexing with you; it simply reaches out and pulls your digital life together.

### Data Aggregation and OAuth Ingestion

OpenHuman’s first step is to break down the walls of your various SaaS platforms. Through standard OAuth authorization, it automatically ingests data from your Gmail, Notion, GitHub, Slack, Calendar, Drive, and more.

The significance of this operation is “forced consolidation.” Previously, this data existed as isolated information silos. Now, OpenHuman acts as a super-pipeline, channeling scattered water flows into a single reservoir.

### The Generation Logic of Memory Tree and LLM Wiki

Once the data is ingested, OpenHuman doesn’t just throw it into a black box. It performs a full suite of compression and organization, ultimately writing it into a structure called the Memory Tree, which materializes as a local LLM Wiki—an Obsidian Vault-format knowledge base.

Application Scenario:
Suppose you are preparing for a critical review meeting with a client next week. In the OpenHuman ecosystem, the system won’t just give you a pile of raw emails. It will automatically trace a coherent line in the Memory Tree: the initial meeting record in last month’s Calendar -> the subsequent Slack context where you discussed the plan with your internal team -> the GitHub repository where code was submitted based on that plan -> and finally the deliverable emailed to the client via Gmail.

The core feature of this LLM Wiki is its “amphibious” nature: Humans can open and read it, and Agents can read it too. For humans, it is an incredibly powerful, auto-updating personal Wiki; for Agents, it is the perfect source of context.

### Closing the Loop from Wiki to Workstation

Possessing the LLM Wiki isn’t where OpenHuman stops. It builds on top of this knowledge base by layering on a desktop UI, voice interaction, a Meet agent (meeting assistant), a notification system, and tool-calling capabilities.

By doing so, it completely breaks away from the “chatbot” category and transforms into a true personal AI workstation. It knows what projects you are working on recently, who you have communicated with, what tasks remain unfinished, and what materials you will repeatedly need in the future.

>

Reflection / Lesson Learned:
The biggest inspiration OpenHuman gives me is this: sometimes the best technological iteration isn’t making the model parameters larger, but “warming up” the user’s cold data. Karpathy’s previous idea was treated by many as a geek toy, but OpenHuman proves that directly binding a personal knowledge base with an AI assistant is the true landing form for personal AI. It isn’t replacing your search; it is replacing your “memory.”

## OpenViking: Building a “Virtual File System” Foundation for Agents

Core question answered in this section: When Agents need to handle highly complex logic and massive concurrent calls, why must we introduce a structured context database instead of a simple knowledge base?

If OpenHuman is built for “human-machine collaboration,” OpenViking’s perspective flips entirely toward “machine-machine collaboration” or pure Agent execution. What OpenViking does is more foundational, pointing directly at the core pain points of an Agent context database.

### Farewell to Flat Chunks: The viking:// Virtual File System

OpenViking also does chunking and embedding, but after this step, it takes a completely different path. Instead of throwing vector results into a traditional index pool, it takes all resources, memories, skills, and sessions and uniformly organizes them into a viking:// virtual file system.

This design is incredibly elegant. It grants the Agent an OS-like file-browsing capability.

viking://
├── resources/        # Manages external data (e.g., documents, web pages)
├── user/memories/    # Manages user long-term preferences and historical memory
├── agent/skills/     # Manages the Agent's own tools and skill code
└── session/          # Manages real-time context history of the current session

Application Scenario:
Suppose you deploy a coding Agent based on Claude Code. When it receives an instruction to “refactor the payment module,” it won’t blindly search a massive vector database. Like a programmer opening an IDE, it will first go to viking://resources/ to find payment-related architecture docs, then check viking://agent/skills/ to confirm if it has the script to call the database, and finally check viking://session/ to verify if the user just said, “Don’t alter the order table structure.”

This directory-based separation elevates the Agent’s retrieval from “finding a needle in a haystack” to “following a map to a destination.”

### L0, L1, L2: Extreme Control of Context Budget

Inside the viking:// file system, every node is not a massive block of text. Instead, it is finely divided into three hierarchical levels:

• L0 is the Summary: Used to quickly determine relevance.
• L1 is the Overview: Used to determine structure and whether it’s worth digging deeper.
• L2 is the Raw Detail: Read only when needed.

Operation Example and Scenario Description:
Why do we need these three layers? Because no matter how large an LLM’s context window gets, there are ultimate limits to cost and attention span. This is the so-called “context budget.”

When an Agent needs to find information, OpenViking’s retrieval mechanism first performs embedding vector positioning exclusively at the L0 (Summary) level of all nodes. This is like walking into a library and first reading the covers and back-cover blurbs of every book.

If L0 determines a piece of data is irrelevant, the retrieval stops immediately, massively saving compute. If relevant, the Agent drills down to the L1 (Overview) level to check the specific chapter structure and logical flow. Only when it truly needs to cite specific database table names or raw conversational quotes is the most resource-intensive L2 (Raw Detail) level awakened on demand.

Combined with directory recursive retrieval, reranking, and filtering mechanisms, OpenViking delivers the most appropriate, most refined content to the Agent.

>

Reflection / Unique Insight:
OpenViking’s L0/L1/L2 design is essentially teaching an Agent “how to read.” We humans naturally skim, scan, and deep-read when processing information, but past RAG architectures forced AI to read the complete raw chunk every single time. OpenViking transforms “memory” from a pile of flat fragments into a set of file systems that Agents can actively browse, retrieve, compress, and update. This is exactly what Agent memory should look like.

Image Source: Unsplash

## Product Experience vs. Infrastructure Foundation: Which One Should You Choose?

Core question answered in this section: Faced with the same “context” pain point, what business scenarios do these two distinct routes respectively serve?

Once you understand their underlying logic, you won’t confuse them anymore. Both are solving the question of “how an Agent acquires long-term, stable, maintainable context,” but their execution styles are fundamentally different.

How to Choose?

If you are a product manager or indie developer looking to immediately solve the daily pain of being fragmented by various SaaS tools, and you want a desktop AI assistant that remembers the background of all your work, OpenHuman’s productized path is the direct solution. It is closer to the user experience—what you see is what you get.

However, if you are building a complex automated workflow—such as a super Agent that can autonomously investigate online alerts, read source code, and execute repair scripts (e.g., an advanced form based on Claude Code or Codex)—then OpenViking is the foundation you must watch. It is closer to the Agent base layer. It doesn’t provide a pretty UI, but it guarantees your Agent won’t collapse from context overflow after running 100 loops.

>

Reflection / Unique Insight:
Often, when making tech choices, we easily fall into the trap of “who has more features.” OpenHuman and OpenViking teach us a lesson: facing the same pain point, stepping forward yields a product; stepping downward yields infrastructure. Neither is inherently superior; it’s purely about which one better fits your current system architecture.

## Practical Summary / Action Checklist

• Clarify your core need: If you need an “AI assistant to remember your work trivia,” focus on productized Wiki solutions like OpenHuman. If you need a “backend that prevents your Agent from losing context during long-term tasks,” study context databases like OpenViking.
• Reshape your data organization concept: Stop mindlessly chunking all data. For personal knowledge, try building a Memory Tree and materializing it into a locally readable Markdown library; for Agent memory, try introducing the directory isolation concept of a virtual file system.
• Implement context budget management: When developing Agents, stop stuffing the entire original text into the Prompt at once. Reference the L0/L1/L2 logic of OpenViking: let the model read the summary first, load the original text on demand, and effectively control Token consumption and attention dilution.

## One-page Summary

Long-term memory for Agents cannot rely solely on “appending chat history” or “flat vector retrieval.” OpenHuman ingests a user’s full SaaS data via OAuth, compresses it into a local LLM Wiki, and creates a memory external brain shared by humans and machines, focusing heavily on product experience. OpenViking organizes resources, memories, skills, and sessions into a viking:// virtual file system. Through a three-layer architecture of L0 (Summary), L1 (Overview), and L2 (Raw), it achieves precise context budget control, serving as a pure Context Database for underlying Agent architectures. One reaches up to touch the user; the other roots downward into the infrastructure. Together, they point the way forward for AI memory evolution.

## Frequently Asked Questions (FAQ)

Q1: What is the difference between the LLM Wiki generated by OpenHuman and notes I manually write in Obsidian?
OpenHuman’s LLM Wiki is automatically generated by AI that ingests and compresses multi-source data (like your Gmail and Notion) via OAuth. It requires no manual maintenance, and its structure is specifically optimized for Agents to better read and cite.

Q2: Is the viking:// virtual file system in OpenViking a real folder existing on my hard drive?
No. It is a logical organization method used to separate and manage what would otherwise be flat, chaotic vector data blocks by directory—resources, user memories, Agent skills, and session history—making it easy for Agents to retrieve data as if they were browsing a file system.

Q3: In OpenViking’s retrieval, what happens if the L0 summary makes a wrong judgment?
OpenViking’s retrieval does not rely solely on L0. L0 is used to quickly filter out massive amounts of irrelevant data to save compute. Once L0 determines relevance, the system uses directory recursive retrieval, reranking, and filtering mechanisms to perform secondary validation at the L1 and L2 levels, ensuring the final context delivered to the Agent is accurate.

Q4: Can I use both of these approaches in my own project simultaneously?
Yes, and they do not conflict. You can borrow OpenHuman’s concept to display a visualized LLM Wiki on the frontend to enhance user experience; simultaneously, you can borrow OpenViking’s concept on the backend to build a dedicated Context Database for your Agent, achieving a dual upgrade in experience and foundation.

Q5: Which Agent frameworks does OpenViking support integrating with?
Because OpenViking is positioned as underlying context infrastructure, it is suitable to act as the backend for any Agent with long-term operational capabilities, such as OpenClaw, Hermes, Codex, Claude Code, or a custom Agent system you develop yourself.

Q6: What is the exact core difference between standard RAG and OpenViking?
Standard RAG is “chunk-embed-retrieve top-k,” where data is flat and isolated. OpenViking, before vectorization, structurally organizes data and controls budgets via a virtual file system and L0/L1/L2 layering, turning the retrieval process from “blind matching” into “precise, layer-by-layer positioning following a directory.”

Q7: What is the Meet agent feature inside OpenHuman?
It is a component of OpenHuman’s personal AI workstation. Leveraging its underlying Memory Tree, the Meet agent can provide highly targeted assistance during meetings based on your historical documents, emails, and calendar context, and it writes new data generated during the meeting back into your LLM Wiki.

Q8: Why is OpenViking considered more suitable for handling Agent skills?
Because under the viking://agent/skills directory, an Agent’s tool-calling code and API docs can be structurally managed. When an Agent encounters a complex task, it can precisely check the usage logic at the L1 level and extract specific code details at the L2 level, without this data getting mixed up with regular chat history or external resources.