Feature: Cross-agent memory reads via link permissions

[EZotoff]

Feature Request: Cross-agent memory reads via link permissions

Problem

Spacebot's memory architecture is per-agent isolated: each agent has its own SQLite + LanceDB memory store. In multi-agent setups, there is no data path between agents' memories.

For example: an overseer agent records project decisions and domain knowledge, but a specialist agent sees an empty memory store. The specialist can't benefit from the overseer's accumulated knowledge without the human repeating it.

The existing send_agent_message tool proves the pattern for cross-agent operations: it uses the links system for permission validation. Memory reads needed the same capability.

Related

• Universal Memory Gap: Discord & Telegram conversations not committed to the agent's memory #363 (Universal Memory Gap) — memory persistence across platforms
• feat(memory): add participant context foundation #521, fix(memory): tighten persistence rules and add conversational events #522, feat(memory): expand conversational event semantics #524 — active memory system evolution (participant context, conversational events, persistence rules)
• The existing links system already provides the permission model this feature needs

Proposed Solution

Extend MemoryRecallTool with an optional target_agent_id parameter, using the existing links system for permission enforcement:

API

{
  "tool": "memory_recall",
  "args": {
    "query": "classification methodology",
    "target_agent_id": "overseer"
  }
}

When target_agent_id is specified:

1. Validate that a link exists between the calling agent and the target
2. Check link direction (only read if the link allows it)
3. Resolve the target's MemorySearch from a shared registry
4. Perform the search on the target's memory store
5. Return results without record_access() side effects (remote reads don't alter the target's access tracking)

Self-targeting (target_agent_id = own ID) falls through to the normal local path.

Implementation sketch

src/lib.rs:

• Add memory_search_registry: Arc<ArcSwap<HashMap<String, Arc<MemorySearch>>>> to AgentDeps

src/tools/memory_recall.rs:

• Add CrossAgentMemoryAccess struct (registry + links + self-agent-id)
• Add with_cross_agent() builder on MemoryRecallTool
• Add target_agent_id: Option<String> to args
• In call(): validate link → resolve target → remote search → skip record_access()

src/tools.rs:

• Both tool factories accept optional links + memory_search_registry params
• Conditionally call tool.with_cross_agent(...) when both are Some

src/main.rs:

• After agent initialization, build per-agent HashMap<String, Arc<MemorySearch>> registries
• Pass to tool factory calls

Why this approach

• Follows existing patterns — mirrors task_store_registry for cross-agent task access
• Links for permissions — no new permission model, reuses what's already there
• Read-only — agents can only read other agents' memories, never write. This preserves isolation guarantees
• No side effects — remote reads skip record_access() to avoid polluting the target's access tracking

Impact

• Multi-agent setups can share knowledge without duplication
• Specialists can leverage overseer/manager knowledge automatically
• Read-only by design — no risk of memory corruption across agents
• Zero impact on single-agent setups (no registry = no cross-agent capability)

Implementation Notes

We've been running this on v0.3.3. I noticed vsumner has active memory work in #521-#524 — I'd like to coordinate to make sure this aligns with the direction the memory system is heading. Happy to adapt the implementation to fit the evolving architecture.