"Donovan likes concise answers" is not the same kind of statement as "this repo uses Node 24."
One is relational context. The other is project canon. Store them in the same bucket and the system will mix them up, eventually and embarrassingly. A preference gets treated as a fact. A fact gets treated as a preference. Both of those failures look the same on the surface — the agent says something confident — and they fail in different directions.
Relationship memory deserves its own layer because the lifecycle, the scope, and the privacy posture are all different from canon (Canon is not memory) and different from semantic recall (semantic memory). It ages faster. It scopes tighter. It's more dangerous when it leaks the wrong way.
Preference and truth age differently
A repo fact like "uses Node 24" is true until somebody migrates the project. It changes through code, in a commit, with a diff. The audit trail is automatic.
A preference like "use direct language with me" is true until the same person says "wait, I want more context this week" — which they often do, depending on mood, project, and channel. The audit trail is a conversation, not a commit.
Treating them the same is the bug. A few concrete examples I've run into:
- "Use direct language with me." → relational, per-thread, can flip.
- "In this Discord, keep answers short." → relational, scoped to a venue.
- "Kyle owns the deploy pipeline." → social, slow-changing, but not repo canon.
- "For this repo, never edit generated files." → this one is canon, and it belongs in
AGENTS.md, not in a personal memory store.
Only the last one is durable enough and impersonal enough to live in the world-facts layer. The others belong in a layer that knows it's about a specific person, role, or venue, and that knows preferences expire.
Honcho is the named example for this layer. It's designed to track the person behind the conversation — identity, role, preference, social context — separately from anything claiming to be world truth. Hindsight's profile memories cover similar territory. The shape varies, but the move that matters is segregating this kind of state from the rest of memory, not just adding more rows to the same table.
The user is not a namespace
The naive design treats a user as a single namespace: store preferences under user_id, retrieve them on every turn. That falls apart the first time the same person has different preferences in different contexts. The same engineer might want terse one-liners in the deploy channel and a five-paragraph explainer in the architecture thread. Same person, different scope.
Relationship memory needs scope as a first-class dimension: person × workspace × server × repo × task × time. A preference recorded in the context of one repo shouldn't silently bleed into another. A role assignment in one Discord server doesn't transfer to another. A "keep it short" rule from one thread shouldn't override "explain in detail" from another.
This is what makes the layer hard. It's not really memory in the storage sense — it's scoped state with revision. The "memory system" framing undersells how much of this is governance: who can write, who can read, when does it expire, what does it apply to.
It also has a privacy posture that the other memory layers don't. Repo canon is impersonal. A vector store of repo experience is mostly impersonal. Relationship memory is data about a person, often inferred without that person explicitly endorsing the inference. The default for storing it should be more conservative than the default for storing a tool trace.
This should not write directly into canon
The boundary that matters most: relationship memory influences tone, defaults, and prioritization. It does not silently rewrite world facts. It also doesn't override repo instructions — a user's tone preference loses to build instructions, and it loses to safety constraints too.
Some scopes I've found load-bearing:
- Relationship layer: "Kyle wants adversarial pushback in code review." Affects how the agent responds. Doesn't change what the agent thinks is true.
- Canon layer: "relay-ide PRs target nightly." Same for everyone, lives in repo docs.
- Session layer: "For this thread, scaffold article drafts but don't publish." Scoped to one conversation, expires when the conversation does.
The failure mode the boundary prevents: someone says "I prefer brevity" in one DM and the assistant decides that's now a global rule, so it starts stripping detail out of code reviews where the detail was load-bearing. The preference was real. The promotion to global was wrong. Relationship memory should never silently get promoted to canon — that's the same mistake Who gets to write truth? talks about for the write path in general.
Assistant memory is different from coding-agent memory
Most "agent memory" pitches blur two very different agent profiles:
- An assistant is doing collaboration as the product. Personality, preferences, relationship state, conversational continuity — these matter because the product is the conversation.
- A coding agent is doing software work. The relationship layer should be thin. The repo, the task, the tools, the tests are what matter. Too much personality is contamination.
- An orchestrator sits between them. It needs just enough relationship state to route work — "Kyle is the one who'll review this PR, use the review template he prefers" — without contaminating the verification path with author intent. (More on this in the projections post.)
Same person interacting with all three. Different memory needs at each layer.
Limits
A few things this isn't:
- Not an anti-personalization argument. Personalization is the assistant layer doing its job. The problem is when the personal preference layer starts deciding what's true.
- Not a full Honcho endorsement past what I've verified. Naming it because it's the cleanest example of this layer being a separate concern, not because the implementation is settled.
- Not a claim that preferences are forever. The opposite — relationship memory should age, revise, and expire by default. The bug is treating it as durable canon.
- Not a privacy hand-wave. This layer needs explicit consent and explicit scope. The default should be conservative because the cost of getting it wrong is personal, not technical.
Outcomes
- Relationship memory is not world truth. It's scoped, revisable, and privacy-sensitive.
- Scope is a first-class dimension: person × workspace × repo × task × time. A preference in one context shouldn't leak into another.
- Assistants need this layer because collaboration is the product. Coding agents should keep it thin. Orchestrators need just enough to route, not enough to bias.
- The next post moves from the layer that's about people to the layer that's about what the agent did.