One Context Surface, Three Kinds of Knowledge
OpenViking’s context model is the focus here: how one agent-facing system can hold shared project knowledge, personal learning, and callable capabilities without confusing their owners or lifecycles. The practical goal is to classify each kind of context and then use its Viking URI to predict who should see it, how it changes, and whether an agent should browse, search, or invoke it.
Three contexts, three lifecycles
A useful way to understand OpenViking is to ask two questions of every piece of information: what job does it perform for an agent, and who is responsible for changing it? The project’s three basic types—Resource, Memory, and Skill—answer those questions differently.
A Resource is knowledge brought into the system from outside. It might be an API manual, a code repository, a product specification, a research paper, or an FAQ collection. The user adds it because an agent needs a dependable reference that is not sufficient in the model’s general training. Resources are usually relatively static: a team may revise a manual or import a new version, but the content is not expected to change after every conversation.
A Memory is knowledge acquired through interaction or task execution. It can record a user’s preference, a decision about a project, knowledge about an entity, or an experience that may improve a later attempt. Memory is dynamic and personalized. The agent or its session machinery is responsible for deciding what is worth retaining, so memory is not simply a second name for an imported document.
A Skill is a definition of how an agent can perform a task or interact with an external system. It may describe a workflow, a tool configuration, or the conditions under which a capability should be called. Its definition is relatively stable and callable: the agent chooses when to use it. The fact that a skill was successful, awkward, or useful in a particular situation is a different kind of information and belongs in Memory as experience.
This division prevents three common category errors. First, a manual should not be treated as a personal preference merely because both can answer a question. Second, a remembered preference should not become shared project documentation simply because it is relevant to the same task. Third, an observation about using a skill should not silently rewrite the skill’s definition. OpenViking can make the three types searchable together, but it keeps their reasons for existing separate.
The distinction is about lifecycle as much as content. A resource normally moves from user import to later reference. A memory moves from interaction to extraction, comparison, and possible update. A skill moves from definition to invocation, while its usage history can accumulate elsewhere. If those transitions were all represented as undifferentiated documents, the agent would have to infer ownership and authority from prose. The explicit type gives the system a place to apply different storage and access rules.
Resource: supplied knowledge for a shared subject
Resources are the easiest type to picture because they resemble the documents teams already maintain. Suppose a team imports the documentation for a payment service into OpenViking. The content can be organized under a project directory and used by many tasks: explaining an endpoint, checking an authentication rule, or comparing the current implementation with the specification.
The important point is not that the document is “knowledge” in the abstract. It is that the document is external knowledge with a reference lifecycle. The user controls when it enters the system and when it is replaced. Its natural home is the account-level viking://resources scope, where resources can be shared inside an account and, when configured, restricted with resource access controls.
That shared default is useful for a project, but it is not a universal sharing rule. OpenViking also supports user-owned resources under a user’s private space. Moving a resource from a private user area into a shared resource area is therefore a meaningful change in visibility, not just a rename. The path tells the system which kind of sharing is intended, while identity and permissions determine whether a caller may actually read or modify it.
A resource can also be a repository rather than a prose document. In that case, directory structure is part of the reference value. A question about an API may lead to documentation; a question about implementation may lead to source code; an incident question may require both. Treating the repository as one flat text blob would discard the relationship between its parts. OpenViking’s URI tree keeps those parts addressable while leaving semantic retrieval available when the exact path is unknown.
Memory: learned state with a personal boundary
Memory serves a different purpose. It lets an agent carry forward knowledge that was not part of the original resource corpus: a user prefers concise explanations, a project has chosen one deployment pattern, or a prior task exposed a reliable recovery procedure. Such information can improve later work precisely because it is tied to an interaction history or a particular person.
OpenViking stores user memory in the current user’s namespace, with supported memory types such as profiles, preferences, entities, events, identity, soul, cases, trajectories, and experiences. The list is less important than the rule behind it: memory is organized around the user or a stable interaction peer, not put into a globally shared “agent memories” bucket. A peer-specific memory can describe someone the agent interacts with, while self memory describes the current user or assistant continuity.
This boundary changes what relevance means. A memory about one user’s coding habits may be highly relevant to a coding request, but it should not automatically be visible to every member of the project. Conversely, a shared resource may be relevant to many users but should not be mistaken for a personal instruction. OpenViking’s context type and URI scope allow the retrieval layer to combine these signals while authorization still decides whether the result may be read.
Memory is also not a verbatim record of every conversation. The session system can extract candidates, compare them with existing memories, and decide to skip, create, merge, or delete. That makes a memory an interpreted and maintained state. The interpretation can be valuable, but it also means that policies and model behavior matter; “the agent saw it once” is not the same as “OpenViking will retain it forever.”
Skill: a callable capability, not just code
A Skill answers a third question: how should the agent act? A skill definition may tell the agent how to search the web, create a document, analyze data, or interact with a service. In OpenViking, the definition is context because it changes what the agent can do and when it can do it. The agent can search for a skill by what it enables, then load its definition when a task calls for that capability.
The distinction from ordinary application code is operational. Code is often loaded because a program needs to execute it. A skill is loaded because an agent needs a description of a capability, its procedure, or its external interaction contract. That description can be stored, summarized, searched, and assigned a Viking URI like other context. It can also be personal, global, or otherwise scoped according to where it is written.
OpenViking’s default user skill area is distinct from the global viking://agent/skills area. A personal skill can encode one user’s workflow. A global skill can be shared as an account-level agent capability. In both cases, the definition remains relatively static compared with the memory of how it performed in real tasks. Separating the two lets a team improve a skill deliberately while still learning from its use.
This is why calling Skills a context type does not reduce them to a directory of scripts. Their value lies in the relationship between an agent, a capability definition, and the task that selects it. That relationship also explains why OpenViking presents Skills through the same retrieval environment as Resources and Memories: before an agent can act, it may need to discover both the relevant knowledge and the right way to use it.
One request can cross all three types
Consider a release manager asking an agent to prepare release notes for a payment service. The request has a factual part, a personal part, and an action part, even if the user expresses them in one sentence.
The factual part belongs to a Resource. The agent needs the project’s recent changes, the relevant API documentation, and perhaps a known incident report. Those materials should be anchored to the project’s resource area so that another member of the account can inspect the same source. If the agent finds a directory whose overview describes deployment changes, it can then read the specific files that support the release note instead of treating the entire repository as one undifferentiated reference.
The personal part belongs to Memory. “Use my usual style” may refer to a stable preference that was learned in an earlier interaction. That preference can influence tone or formatting for this user without becoming an instruction that every member of the project inherits. If the request also mentions a previous decision—such as which compatibility promise the team made—that decision may be represented as an event or entity memory with a different path and retention purpose.
The action part belongs to a Skill. Preparing the notes may require a document-generation workflow, a repository inspection capability, or a publishing procedure. The skill tells the agent how to perform that operation and what external interaction it entails. A successful release-note task might later yield an experience memory, but that experience should inform future use rather than silently alter the underlying skill definition.
A unified retrieval surface lets the agent discover these pieces in one interaction. It does not mean the service merges them into one authority. The Resource answers, “What changed?” The Memory answers, “How should this user prefer the answer, and what decisions should be remembered?” The Skill answers, “What procedure can turn those inputs into an artifact?” The agent still needs to keep those answers distinct when it acts.
This separation also makes updates easier to reason about. When the project documentation changes, the resource can be reimported or revised without rewriting a user’s preference. When the user changes their preferred style, the memory can be updated without changing the project source. When a workflow is deliberately improved, the skill definition can be versioned or replaced while the history of its use remains available as experience. The three objects may participate in the same task, but they do not share one undifferentiated update rule.
Viking URI is more than a path
The common address format is viking://{scope}/{path}. At first glance, this looks like a familiar filesystem path with a new prefix. Its deeper role is to connect location to operations. An agent can use a URI to list a directory, inspect a tree, read a file, obtain an abstract or overview, write content, or limit a semantic search. One addressing system supports both deliberate navigation and discovery.
The public scopes make the broad boundaries visible. resources contains account-level objective knowledge. user contains user data such as memories, sessions, private resources, peer content, and personal skills. agent contains global agent capabilities and configuration. Internal scopes used for temporary parsing or queues exist for the implementation but are not ordinary application destinations.
The home alias, viking://~, makes a user-relative path practical. It expands on the server according to the authenticated caller, so viking://~/memories means that caller’s memories rather than one universal directory. Responses use the canonical expanded URI. This is important because a path string alone does not identify whose memory is being addressed; the request identity participates in its meaning.
The URI is also a retrieval scope, but scope and permission are not identical. Asking to search a project subtree does not grant access to it. Account boundaries, user ownership, peer restrictions, and optional resource ACLs still apply. In some cases, a caller may discover a deeply shared file even when an intermediate directory is not readable. That behavior is a reminder that navigation, discovery, and authorization are related surfaces with different rules.
When one search surface should—and should not—unify them
OpenViking’s unified search is useful because an agent request often crosses the three types. “Help me prepare the release notes in my usual style” may require a project resource for factual changes, a memory for the user’s preferred style, and a skill for producing the document. For the agent, one retrieval interface is simpler than three unrelated databases.
But the result should remain typed and scoped. The project resource supplies subject matter; the preference supplies personalization; the skill supplies a way to act. A relevance score may rank all three, yet the score cannot decide whether a personal preference may be shared, whether a skill is authorized for the current environment, or whether a resource is current enough to cite. Those judgments belong to the context model and its access rules.
The right mental model is therefore not “one big context surface.” It is one surface over differentiated context. OpenViking unifies the operations that an agent needs—find, read, browse, and later reuse—while retaining the ownership and lifecycle distinctions that make the results trustworthy. Once that model is in place, the next question is how much of each context an agent should load. A type and a URI identify what the information is and where it belongs; they do not yet determine whether the agent needs a short clue, a directory map, or the full detail.