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:
- Agent vault (
vaultMode: "agent"): Each agent workspace gets its own wiki at ~/.openclaw/workspace-{agent}/wiki/, isolated from other agents
- 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
- 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
- Flat shared vault: One vault for all agents (current
isolated mode) — doesn't work for multi-company/multi-team setups
- Manual symlinks: Users manually create vault directories and switch — error-prone, no promotion flow
- All merged at query time (OmniMem approach): Simpler but loses hierarchy and provenance
This proposal maintains clean boundaries AND enables intentional sharing through promotion.
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-wikiarchitecture 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:
Problem to Solve
Different organizational levels have different knowledge needs:
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:
vaultMode: "agent"): Each agent workspace gets its own wiki at~/.openclaw/workspace-{agent}/wiki/, isolated from other agentsvaultMode: "project"): A shared project wiki at a configurable path (e.g.,~/.openclaw/projects/{project}/wiki/), accessible by all agents working on that projectvaultMode: "company"): A shared company wiki at a configurable path (e.g.,~/.openclaw/companies/{company}/wiki/), accessible by all agents belonging to that companyPromotion flow
Add a
wiki promotecommand orwiki_applyoperation that moves content up the hierarchy:Promotion should:
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 projectSearch across levels
wiki_searchshould support searching across levels:Results should indicate source vault level.
Wiki-wiki bridge
When a project wiki or company wiki is configured, bridge mode should:
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
isolatedmode) — doesn't work for multi-company/multi-team setupsThis proposal maintains clean boundaries AND enables intentional sharing through promotion.