Skip to content

[Feature]: Hierarchical wiki vaults with promotion flow #64097

@ttomiczek

Description

@ttomiczek

Summary

Add support for a hierarchical wiki vault system where content can be promoted up through organizational levels (agent → project → company), with manual import capability at each level.

Motivation

Current memory-wiki architecture supports exactly one global vault. This is insufficient for multi-agent, multi-company setups where different teams need isolated knowledge domains with intentional sharing boundaries.

Real-world hierarchy:

Company (Knahl GmbH standards, policies)
  └── Project (Paperclip: stack, goals, decisions)
        └── Agent (personal memory, preferences, discoveries)

Problem to Solve

Different organizational levels have different knowledge needs:

  • Company level: coding standards, compliance policies, people directory, company-wide decisions
  • Project level: stack choices, project goals, architecture decisions, client context
  • Agent level: personal context, session history, preferences, discovery notes

Users (operators) also want to manually import content at any level — e.g., inject coding standards from a file, paste company policies, add third-party documentation.

Proposed Solution

Hierarchical vault structure

Support three-tier vault hierarchy:

  1. Agent vault (vaultMode: "agent"): Each agent workspace gets its own wiki at ~/.openclaw/workspace-{agent}/wiki/, isolated from other agents
  2. Project vault (vaultMode: "project"): A shared project wiki at a configurable path (e.g., ~/.openclaw/projects/{project}/wiki/), accessible by all agents working on that project
  3. Company vault (vaultMode: "company"): A shared company wiki at a configurable path (e.g., ~/.openclaw/companies/{company}/wiki/), accessible by all agents belonging to that company

Promotion flow

Add a wiki promote command or wiki_apply operation that moves content up the hierarchy:

# Agent promotes a pattern to project wiki
openclaw wiki promote --from agent --to project --id pattern.tls-approach --message "This approach solved TLS issue for 3 agents, should be project standard"

# Project promotes to company wiki
openclaw wiki promote --from project --to company --id standard.http-headers --message "HTTP header handling standard, approved for company-wide use"

Promotion should:

  • Copy content to target vault (not move — source stays)
  • Add provenance metadata pointing to original source
  • Track promotion chain (agent → project → company)
  • Require confirmation or allow auto-promote for trusted sources

Manual import

Allow users to import content at any level:

openclaw wiki ingest ./company-standards/coding-guidelines.md --vault company --title "Coding Standards v2"
openclaw wiki ingest https://example.com/architecture.md --vault project

Search across levels

wiki_search should support searching across levels:

openclaw wiki search "TLS configuration" --scope all    # search all vaults
openclaw wiki search "TLS configuration" --scope project  # project + company
openclaw wiki search "TLS configuration" --scope agent    # agent only

Results should indicate source vault level.

Wiki-wiki bridge

When a project wiki or company wiki is configured, bridge mode should:

  • Pull in relevant artifacts from member agent vaults
  • Track provenance through the hierarchy
  • Allow cross-vault citation

Additional Context

Reference: OmniMem three namespace concept (omnimem.org/#features) — OmniMem uses three flat namespaces (episodic, project, knowledge) that merge at query time. Our proposal is hierarchical (content bubbles up, not all merged at once) with explicit promotion rules.

See also: Issue #63829 (per-agent vault config) — this feature builds on that foundation.

Alternatives Considered

  1. Flat shared vault: One vault for all agents (current isolated mode) — doesn't work for multi-company/multi-team setups
  2. Manual symlinks: Users manually create vault directories and switch — error-prone, no promotion flow
  3. All merged at query time (OmniMem approach): Simpler but loses hierarchy and provenance

This proposal maintains clean boundaries AND enables intentional sharing through promotion.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions