What Are `_slots/` Pages in ai-memory? A Complete Guide to Contextual Wiki Slots

Slots in ai-memory are mutable wiki pages stored under the _slots/ path prefix that hold per-session contextual data, such as "what I am currently working on," which the engine injects into every session brief for a project.

The ai-memory project implements a lightweight wiki system where special _slots/ pages serve as dynamic, context-aware notes. Unlike static documentation, slots adapt to who is viewing them and can be either shared across all users or restricted to personal namespaces. Understanding this mechanism is essential for configuring multi-user deployments or building integrations that leverage session context.

What Defines a Slot Page?

A slot is recognized solely by its path prefix. According to the source code in crates/ai-memory-core/src/slots.rs, any page whose path starts with _slots/ is treated as a slot:

// From crates/ai-memory-core/src/slots.rs (lines 35-36)
pub const SLOT_PREFIX: &str = "_slots/";

The is_slot_path function performs this detection:

use ai_memory_core::slots::is_slot_path;

assert!(is_slot_path("_slots/current-focus.md"));
assert!(!is_slot_path("_rules/style.md"));

This prefix-based design makes slots visually distinct in the wiki hierarchy while remaining ordinary files on disk.

Shared vs. Personal Slots

Slots operate in two visibility modes, controlled by path structure and configuration:

• Shared slots — No namespace segment (e.g., _slots/current-focus.md). Visible to all users.
• Personal slots — Namespaced by an operator's identity key (e.g., _slots/u-alice/current-focus.md). Restricted to that user when per-user isolation is enabled.

The slot_owner function extracts the namespace from a slot path:

use ai_memory_core::slots::slot_owner;

assert_eq!(slot_owner("_slots/current-focus.md"), None);           // shared
assert_eq!(slot_owner("_slots/u-alice/current-focus.md"), Some("u-alice")); // personal

The namespace segment is derived from IdentityKey::path_segment, which guarantees safe, filesystem-friendly identifiers matching the pattern [A-Za-z0-9._-] (see lines 15-22 in slots.rs).

Visibility and Access Control

The SlotVisibility enum in crates/ai-memory-core/src/slots.rs (lines 94-101) determines which slots a viewer can see:

// Determining visibility for a logged-in user with per-user slots enabled
use ai_memory_core::{slots::SlotVisibility, IdentityKey};

let alice_key = IdentityKey::User("alice".into());
let vis = SlotVisibility::for_viewer(true, Some(&alice_key));

assert!(vis.allows("_slots/current-focus.md"));          // shared: visible
assert!(vis.allows("_slots/u-alice/current-focus.md")); // own: visible
assert!(!vis.allows("_slots/u-bob/current-focus.md"));  // other's: hidden

When the [slots] per_user configuration is off, all slots use SlotVisibility::All — every _slots/ page is visible to everyone. When enabled, the viewer sees only shared slots plus their own personal namespace.

Write Placement Logic

Writing to a slot requires determining where the data should actually be stored. The slot_placement function (lines 71-91 in slots.rs) handles three cases:

use ai_memory_core::{slots, slots::slot_placement, IdentityKey};

let path = "_slots/current-focus.md";
let alice_key = IdentityKey::User("alice".into());
let placement = slot_placement(path, Some(&alice_key));

match placement {
    slots::SlotPlacement::Personal(p) => println!("Rewrite to personal path: {}", p),
    slots::SlotPlacement::AsGiven => println!("Write exactly as specified"),
    slots::SlotPlacement::ForeignNamespace => println!("Reject: cannot write to another user's slot"),
}

This prevents users from accidentally or maliciously overwriting another operator's personal context.

Configuration Options

The slot behavior is controlled through the [slots] TOML table. Key configuration files include:

• docker/multiuser-test/config.toml (line 18) — Example multi-user setup:

[slots]
per_user = true

• crates/ai-memory-cli/templates/config.default.toml (line 165) — Default CLI template with the [slots] table for fresh installations.

The per_user flag toggles whether personal namespaces are enforced or ignored.

How Slots Integrate with Sessions

During session initialization, the engine:

1. Collects all pages matching is_slot_path.
2. Filters them through SlotVisibility::allows based on the viewer's identity and per_user setting.
3. Injects the surviving slot contents into the session brief as contextual data.

This allows an AI assistant to reference "what we discussed last time" or "my current priorities" without requiring explicit prompting.

Core Source Files for Slots

File	Purpose
crates/ai-memory-core/src/slots.rs	All slot logic: prefix constants, path detection (is_slot_path), ownership extraction (slot_owner), visibility rules (SlotVisibility), and write placement (slot_placement)
docker/multiuser-test/config.toml	Working example of [slots] per_user = true for testing multi-user scenarios
crates/ai-memory-cli/templates/config.default.toml	Template configuration including the [slots] table for new installations

Summary

• _slots/ is the mandatory prefix — All slot pages must start with this path segment, enforced by SLOT_PREFIX in slots.rs.
• Personal namespaces use identity-based encoding — Format is _slots/u-<identity>/... with safe character constraints.
• Visibility is runtime-configurable — The per_user setting switches between open access (SlotVisibility::All) and restricted access (SlotVisibility::Owner).
• Writes are validated by slot_placement — Protects against cross-user overwrites by rewriting paths or rejecting foreign namespaces.

Frequently Asked Questions

How do I create a personal slot in ai-memory?

Write to a path under _slots/u-<your-identity>/ when per_user is enabled. The engine will automatically route it to your namespace. If you write to _slots/shared-topic.md without a namespace, it becomes a shared slot visible to all users.

Can I disable user isolation for slots entirely?

Yes. Set per_user = false in the [slots] section of your configuration file. All _slots/ pages will then be treated as shared regardless of namespace prefixes. The default template in crates/ai-memory-cli/templates/config.default.toml includes this option.

What happens if I try to write to another user's personal slot?

The slot_placement function returns SlotPlacement::ForeignNamespace, causing the write to be rejected. This protection is active whenever a writer identity is provided to the operation.

Are slot pages stored differently from regular wiki pages?

No. Slots are ordinary files on disk. The _slots/ prefix is purely a convention recognized by the engine for filtering and access control. The actual storage mechanism is identical to any other page in the ai-memory wiki.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}