Steve HutchinsonBig Pines
·2 min read·Scaling the Cognitive Substrate

Partitioning Memory Across Domains

When memory spans multiple services, teams, and environments, you need to split it up. The tradeoffs of partitioning by domain - and how to preserve cross-domain retrieval when you need it.

One of the most important decisions when scaling is deciding how to split up the data.

Why Partitioning Matters

A single memory pool works fine at small scale and single purpose. When you are ingesting from multiple services, multiple teams, or multiple customers, a single pool creates problems: retrieval becomes noisier as unrelated memories compete for relevance scores, access control becomes harder to enforce, and consolidation workers cannot distinguish between experiences that should never be clustered together.

The Partition Options

By service - each service has its own memory space. Clean and operationally simple, but creates silos that prevent cross-service pattern recognition - often the most valuable patterns in a distributed infrastructure context.

By team - each team owns their domain. Good for access control, but team boundaries do not always align with the knowledge boundaries that matter for retrieval.

By customer - full isolation for multi-tenant scenarios. Necessary for privacy and compliance, but makes platform-level insights impossible.

By time - hot/warm/cold separation. Optimizes for cost but complicates retrieval logic when a query needs to span time boundaries.

The Approach

Domain partitions with a shared abstraction layer.

Each domain - infrastructure, user behavior, content performance - has its own OpenSearch index with its own retrieval and consolidation pipelines. Experiences from one domain do not appear in another domain's retrieval results by default.

However, high-confidence patterns that generalize across domains get promoted to a shared layer during consolidation. This shared layer is available to any agent, regardless of which domain partition they are primarily operating against.

Cross-Domain Queries

Cross-domain queries route to both the relevant domain partition and the shared layer, then merge results in the arbitration step. The additional latency is acceptable because cross-domain queries are less frequent than within-domain ones - and the results from the shared layer are high-confidence abstractions rather than raw experiences, so the result set stays manageable.

Proper partitioning is what allows the system to scale horizontally while keeping memory relevant and manageable for each use case.

Next up from memory

Ranked from series and tags, warmed by what the substrate is keeping salient across readers.

Accept to save reading progress, unlock continue-where-you-left-off, and allow a hosting-support ad at the end of posts. Anonymous session signals still help the live memory panels; we never publish reader IDs.