agent-memory

This repository is the rewrite staging ground for the higher-level memory system.

It is not the canonical home of the plugin supervision substrate. That substrate has been split out into its own product:

• /tank/development/plugin-kernel

Status

agent-memory is currently a transition repository. It contains:

• historical substrate code from the earlier mixed design
• rewrite planning documents for the higher-level memory service
• specifications for separating memory-service concerns from plugin-kernel concerns

Until the rewrite lands, do not treat this repository as a clean source of truth for either:

1. the plugin kernel, or
2. the finished memory service

It is the place where the split gets defined and staged.

What Belongs Here

The next phase of this repository should own the memory-service layer above the kernel:

• canonical note model
• provenance rules
• retrieval contracts
• memory plugin contracts built on the kernel
• storage and indexing rules
• service-level APIs and tests

What Does Not Belong Here

The following are kernel concerns and should live in plugin-kernel, not here:

• plugin executable supervision
• process lifecycle and restart semantics
• heartbeat supervision
• kernel-owned generation boundaries
• low-level auth handshake
• kernel admin RPC substrate

Current Problem

The old mixed design treated plugin substrate work and memory-service work as one problem. That was wrong. The rewrite exists to remove that ambiguity.

Rewrite Workflow

This repository uses a fixed promotion flow:

design-architecture -> feature/<name> -> development -> test -> main

See:

• rewrite/README.md
• rewrite/FEATURES.md
• rewrite/specs/
• rewrite/adrs/

Immediate Rewrite Priorities

1. repo identity split
2. kernel API boundary documentation
3. memory service charter
4. provider plugin contract
5. canonical note model

Rule

Do not casually re-mix kernel and memory-service scope in this repository. If a change is about supervision substrate, it probably belongs in plugin-kernel.