Brain and Heart

The Real Problem

A factual memory system can answer questions like:

What is the path to my budget app?
Who is Paola?
When did I decide not to build the native iOS version yet?

Those are retrieval problems. The memory is either right or wrong.

A personal AI that is supposed to know the user has to handle requests closer to this:

Valeria wrote me.
You know who she is.
You know our history.
You know the current situation.
You know what I usually do when I feel cornered.
You know the hard data.
You know today's state.

Given all that, propose a reply I would still respect tomorrow.

That is the product I am actually interested in.

Not a chatbot that remembers a name. Not a generic writing assistant that can make an email more polite. A system that can take a live social situation and combine several kinds of context:

incoming message
relationship history
current factual situation
hard constraints
my normal behavioral pattern
my current state
audience and channel
the cost of getting the tone wrong

Then it should produce something like:

Here is the reply I would send.
Here is why it fits you.
Here is the risk.
Here is what I may be assuming incorrectly.

That can include decisions, but decisions are not the center. The center is knowing the user well enough to help with tone, correspondence, relationships, timing, interpretation, and the small adjustments that make an answer land like it came from someone who understands the whole situation.

Those are not retrieval problems. They require a model of the user.

The obvious move is to store user preferences. Many systems already do this. They remember that a user likes concise answers, prefers TypeScript, lives in a certain city, or usually chooses low-cost infrastructure. That helps, but it is still too flat. Preferences are local. Identity is compositional.

The assistant needs to know that a user can be budget-conscious and still spend money for control; that he can prefer fast execution but reject shortcuts in long-lived systems; that he can value directness and still need tone calibrated differently for a patient, a school committee, and a business partner. These are not isolated preferences. They are patterns across time, and they change how the assistant should answer before it decides what to answer.

That is where things become dangerous.

If an assistant stores a bad fact, it might answer one question wrong. If it stores a bad pattern about who the user is, it starts interpreting future evidence through that bad pattern. The error becomes a lens. The system does not merely remember something wrong; it begins to see the person wrong.

I think of this failure mode as identity contamination.

Brain And Heart

Brain and Heart are two markdown filetrees.

Brain holds the factual projection of my life and work:

clinic address
wife Michelle
Tesla Model Y
tarbut-becas project path
reBreast website notes
Claude daemon architecture
paper references

Heart holds the interpretive projection:

[OBSERVADO] values direct truth over social smoothing
[INFERIDO] prefers structural fixes over temporary workarounds
[HIPOTESIS] perfectionism is both a quality engine and a delay engine
[PREGUNTA] what is the stable prioritization rule across domains?

The distinction is not topic. The same event can project into both systems.

If I decide to delete broken LaunchAgents instead of disabling them temporarily, Brain stores the operational fact: which agents were deleted, why, and where the logs were. Heart stores the pattern: when operational junk is identified, I prefer root cleanup over reversible half-measures. Brain says what happened. Heart says what it reveals about how I work.

The two systems are siblings, not a hierarchy. Brain can point to Heart when a factual decision depends on a known heuristic. Heart can point to Brain when an inferred pattern needs evidence. Neither is the source of truth for the other.

The deeper point is that Brain and Heart make two different promises.

Brain promises correctness.

Heart promises epistemic discipline.

A Brain entry should be true. A Heart entry should say how true it is allowed to be, where the evidence came from, when it should be revisited, and how the user can dispute it.

That is the architecture in one page.

The Failure Mode

The first version of this system failed in a way that made the split unavoidable.

I had an LLM extract patterns from a WhatsApp dump with my wife. The dump covered a stressful window: work pressure, clinic pressure, normal life compressed into messages. The model produced a clean, confident summary of her communication style and of our dynamic.

The summary was plausible. That was the problem.

It treated a difficult window as a stable relationship model. Once those claims were committed to memory, the assistant started giving advice through that contaminated frame. Every new message was interpreted as confirmation of a pattern that should never have been promoted in the first place.

The mistake was not that the LLM hallucinated a random fact. The mistake was more serious: it overgeneralized from a narrow slice of behavior and stored the generalization as if it described a person.

Most personal-AI memory systems handle this poorly. They can store facts. They can retrieve facts. Some can summarize user preferences. But identity claims need a different protocol because they are:

• longitudinal;
• context-sensitive;
• partly self-reported;
• partly behaviorally inferred;
• often disputed by the subject;
• easy to overfit from a high-affect window.

In a normal memory system, the question is whether the memory is useful.

In an identity memory system, the first question is whether the claim had any right to become stable.

The Protocol

Heart treats every claim about a person as evidence plus confidence plus refutability.

Every entry carries one of four tags:

• [OBSERVADO]: directly observed in conversation, behavior, or a file, with a source.
• [INFERIDO]: inferred from multiple observations.
• [HIPOTESIS]: plausible but not yet corroborated.
• [PREGUNTA]: important unknown to ask about later.

If a claim cannot be tagged, it should not be stored.

The tag is not decoration. It changes how the assistant is allowed to use the claim. An [OBSERVADO] pattern can guide a recommendation. A [HIPOTESIS] can only be offered with uncertainty. A [PREGUNTA] should not quietly become an assumption because the model needs an answer.

Heart entries also carry audit metadata:

---
captured: 2026-05-13
confidence: HIPOTESIS
observations: 1
last_seen: 2026-05-13
revisit: 2026-07-13
tier: 4
sources:
  - session: codx14
---

This makes the claim inspectable. The user can ask where it came from. The assistant can cite the evidence. If the evidence is weak, the entry should look weak on disk.

Three Storage Layers

Heart does not promote identity claims directly to stable memory.

It uses three layers.

Quarantine is for single-source observations. A name mentioned once, a mood observed once, or a behavior extracted from one chat dump belongs here. It is not a stable model of the user.

Project-scoped memory is for patterns that matter inside a bounded context. A temporary work style during a launch, a negotiation posture for one deal, or a tone preference for one committee can live here without pretending to be global identity.

Stable Heart is for claims that survive corroboration. The default threshold is N>=3 independent sources, or explicit user confirmation for claims that are eligible to be confirmed that way.

The layers exist to prevent a common personal-AI disease: a single source becomes a biography.

Confidence Cap By Modality

Not all evidence can support the same confidence.

Self-report is useful, but it is capped. If I say I value honesty ten times, the system has evidence that I present honesty as a value. It does not yet have evidence that I enact it under pressure.

The protocol treats sources differently:

• Self-declared claims are capped below direct observation. They can seed hypotheses but should not become [OBSERVADO] on self-report alone.
• Behavioral evidence can reach [OBSERVADO] when it appears across contexts.
• External corroboration is strongest when it comes from independent records: calendars, emails, documents, chat history, or observed decisions.

This matters because people are unreliable narrators of themselves. Not because they are lying. Because self-knowledge is uneven. Some things are visible from the inside. Some are visible only across behavior.

Heart's job is to hold both perspectives without pretending either one is final.

Refutation Does Not Mean Erasure

The early version of the protocol had a naive rule: if the user refutes a Heart entry, delete or archive it.

That is too clean.

If a claim was promoted because three independent observations supported it, a later user objection does not make those observations disappear. At the same time, the user may be right. The system may have overread the evidence, missed a context shift, or confused a temporary state for a stable pattern.

The better mechanic is append-only dispute.

When the user rejects a claim, the entry receives a disputed-by-user flag with timestamp and counter-evidence. The original observations remain. The disagreement becomes part of the record.

From there, three things can happen.

If future observations support the original claim, the dispute remains as history.

If future observations support the user's objection, the entry can be archived with the dispute trail intact.

If no new evidence appears, the entry remains unresolved: a contested claim with evidence on both sides.

That state is uncomfortable, but it is honest. A personal AI should not resolve ambiguity by flattering the user, and it should not resolve ambiguity by treating its own prior as privileged. It should keep the evidence visible.

Tiered Claims

Heart also ranks claims by stability and scope.

Tier 1: Identity, traits, values
Tier 2: Philosophy, epistemic map, biases, pitfalls
Tier 3: Heuristics, aesthetics, growth, metacognition
Tier 4: Opinions, communication, social graph
Tier 5: Current state

The tiers prevent recency from overruling identity.

A bad week should not rewrite values. A tired mood should not invalidate a long-standing heuristic. A new opinion can be volatile without contaminating the model of the person.

Lower tiers can challenge higher tiers, but they do it by creating a hypothesis of change. They do not silently overwrite.

Retrieval Salience, Not Memory Decay

Older versions of this architecture used the word decay. That was wrong.

The stored memory is append-only. Nothing is erased just because it is old. What changes is retrieval salience: how likely an entry is to surface in the current context.

An old identity claim may remain important. A recent mood may matter for tone but not for long-term decisions. A project-specific heuristic may be highly relevant in one context and noise in another.

Retrieval should consider:

• the tier of the claim;
• how recently it was seen;
• how often it has been used;
• whether the current context matches the capture context;
• whether the entry is overdue for revisit;
• whether it was captured during a high-affect window.

The storage layer is stable. The interpretation layer is dynamic.

That distinction is important because it lets better future models reinterpret old evidence without rewriting it. The files remain intact. The lens improves.

Architecture

The cleanest way to describe the system is as materialized views over a raw source.

The raw source is the future Dumpster: an append-only store of unmodified inputs. Chats, transcripts, emails, notes, PDFs, code, voice memos, screenshots, and whatever else the user chooses to include.

Brain and Heart are curated views over that source.

Brain extracts facts.

Heart extracts identity-relevant patterns.

Neither view should be treated as the primary source. If a view is corrupted, the answer should be to rebuild from raw evidence, not to hand-patch a poisoned profile forever.

The intended pipeline looks like this:

raw input -> quarantine extraction -> candidate claims -> user review -> Brain/Heart

The pipeline does not get to write stable identity claims by itself. It proposes. The user approves, edits, rejects, or disputes. Human-in-the-loop is not a product nicety here. It is the governance mechanism.

Hybrid Encoding

Each Heart entry needs more than a text blob.

It should have:

• discrete tags for people, projects, themes, and affect;
• narrative context explaining what was happening when the entry was captured;
• embeddings for semantic retrieval;
• audit metadata for source, confidence, and revisit.

Each encoding answers a different question.

Tags answer whether an entry is about a known thing.

Embeddings answer whether it is semantically near the current question.

Narrative context answers whether the old situation is genuinely analogous to the current one.

Without narrative context, retrieval can become keyword astrology. Two situations can share vocabulary and mean different things. Two situations can use different words and be the same pattern.

The Digest

Heart will eventually become too large to load in full every session.

The assistant should not have to guess which file matters. Heart needs a digest: a bounded synthesis generated from all dimensions on a schedule.

The digest gives the assistant the whole-person sketch at session start:

• who the user is;
• dominant traits;
• value hierarchy;
• current tensions;
• active heuristics;
• recent pulse;
• open hypotheses;
• changes since the last digest.

The digest is not the canon. It is an index into the canon. If a substantive decision depends on a claim, the assistant still has to open the underlying Heart entry and cite it.

The digest also needs mandatory evidence pointers. A summary that cannot be refuted is just a new opaque profile. Every synthesis should point back to the observations that produced it.

What Existing Work Gets Right

A lot of current work is close to this architecture, just aimed at a different part of the problem.

CoALA imports classical cognitive memory categories into LLM agent design: working, episodic, semantic, and procedural memory. MemGPT treats context like an operating-system memory hierarchy. Mem0 builds production memory around scopes such as session, user, agent, and organization. Letta's sleep-time agents, LightMem, CraniMem, and FadeMem all explore asynchronous consolidation and memory maintenance. TierMem gives the provenance-aware pattern: summary layers linked back to immutable raw logs. Graphiti/Zep brings bi-temporal fact handling, where a fact has both a record time and a valid time.

These are useful. They mostly answer the question of how an agent should store, retrieve, consolidate, and update memory.

Heart asks a narrower question:

What extra governance is required when the memory is not a fact about the user, but a claim about who the user is?

That is where confidence tags, modality caps, refutability, user-audited markdown, and dispute flags become load-bearing.

PersonaMem-v2, Second Me, O-Mem, Hindsight, Memobase, HumanLLM, and SemaClaw are closer because they explicitly model the user. The difference is not that they lack user models. The difference is who audits the model.

In most systems, the user model is something the product owns: a tensor, a profile, a dashboard, a database row, a reinforcement signal, a personalization layer. The user may benefit from it, but they do not normally read it line by line and edit it with the same tools the engineer uses.

Heart makes a different bet.

The modeled person is the auditor.

That one choice changes the substrate. Markdown files and git are not nostalgia. They are an audit interface. The user can open the file, inspect the claim, challenge the source, edit the wording, and preserve the diff.

For identity modeling, that matters more than elegance.

What Benchmarks Miss

Long-horizon memory benchmarks are usually about factual recall. LoCoMo and LongMemEval ask whether an assistant can remember and reason over information across long conversations. That is necessary work.

It does not test the central failure mode of Heart.

The harder question is whether the assistant knows when a remembered preference was weak evidence, when it was superseded, when it was a mood, when it was aspirational, and when it should never have been promoted beyond quarantine.

Three failure modes matter.

Shared-context contamination. In real conversations, people do not reintroduce people they both know. A chat might say Matthew said no. The local text does not tell you whether Matthew is a brother, supplier, patient, friend, or school parent. A system that guesses the role has already lost. The correct capture is name plus literal context, marked identity-unverified until corroborated.

Aspirational capture. A person reading stoicism for two weeks has not necessarily become stoic. A value becomes interesting when it appears in behavior, especially under cost. Until then it is exploration.

Pressure capitulation. LLMs often change their answer when pushed. That is dangerous in a personal model because the user can also be wrong about themselves. Heart's rule is uncomfortable but necessary: user pushback triggers evidence review, not automatic surrender.

These are not memory-storage bugs. They are epistemic-governance bugs.

What Changes In Practice

Before Brain and Heart, an assistant asked to answer a message can read the message and produce competent prose.

After Brain and Heart, the assistant can do something different.

A message arrives from Valeria. Brain knows who Valeria is, what has happened, what was promised, what dates and documents matter, and what the current situation is. Heart knows the relational pattern, my usual failure modes, the kind of directness I respect, the kind of performance I later regret, and whether today's state should lower confidence in the first draft.

The assistant is not just rewriting text. It is composing over context.

incoming message
+ shared history
+ hard data
+ normal behavior
+ current state
+ audience risk
= proposed response

That response might be warmer than my first instinct, shorter than my explanation, firmer than my avoidance, or slower than my anxiety wants. The point is not that the AI knows better than me. The point is that it can place the draft inside the whole pattern and show its work.

That is the useful part.

The assistant is no longer only answering from facts. It is answering from a sourced model of how I communicate, what I am likely protecting, and what kind of response would still feel like mine after the first emotional draft has passed.

This does not make the assistant a decision authority. Heart can support decisions by surfacing relevant patterns, contradictions, and past evidence. It can help with harder questions: whether a deal violates a known constraint, whether a project still fits, whether discomfort is being disguised as principle. But its more common job is smaller and more personal: help me answer the person in front of me from the right version of myself.

This only works if the model is inspectable. If the assistant says I usually choose structural fixes, it should be able to show the cases. If I disagree, I should be able to dispute the entry. If the evidence is weak, the claim should be demoted. Otherwise the system becomes a confident mirror with bad memory.

The gain is largest when no rule exists.

A table of preferences can handle known cases. A model of the person can generalize to new cases. That is also why it is risky. A bad preference fails locally. A bad model fails everywhere.

The protocol is what makes that generalization tolerable.

Bootstrapping

The hardest product objection is cold start.

This architecture works best after months of evidence. A new user does not have that. If the system refuses to promote claims until it has corroboration, early answers will feel thin.

That is not a bug. It is the honest state of the relationship.

A human assistant on day one also asks too many questions. A long-tenured assistant does not. The difference is not magic. It is accumulated evidence.

The product problem is to make the early phase useful without faking intimacy.

The right move is quarantine-first onboarding.

The user can import sources:

• chats;
• email;
• calendars;
• notes;
• writing samples;
• voice memos;
• personality inventories;
• previous AI conversations.

The system extracts candidate claims but does not promote them. It then starts the first negotiation:

Here is what I think I see.
Here is the evidence.
Tell me what is wrong.
Confirm what fits.
What survives stays provisional until corroborated.

That first interaction beats a cheerful assistant introduction. It demonstrates the product's core property immediately: the model is not hidden from the subject.

Cold start still has failure modes.

A six-month chat dump during a divorce, illness, business crisis, or launch will distort the model. Sources need time windows. High-affect windows need tags. Claims should appear across time and source type before promotion.

Public data needs extra care. A user's community, profession, religion, or city can provide context. It cannot provide identity claims. External research belongs in Brain as context, not in Heart as a claim about the person. Otherwise the system is just stereotyping with citations.

Self-report also needs care. The onboarding interview should ask behaviorally, not abstractly. Not what do you value, but when did you pay a cost to protect that value? Not are you direct, but show me the last hard message you sent and why you chose those words.

The early system should be modest. That modesty is a feature. A personal AI that claims deep knowledge on day one is either lying or selling companionship theater.

What I Plan To Build Next

The system is not finished. It is a working architecture under active construction.

Implement the Dumpster. Brain and Heart are still maintained mostly by manual capture. The next step is an append-only raw store that ingests chats, transcripts, notes, code, and documents without modifying them.

Build the extraction pipeline. The pipeline should propose candidate Brain and Heart entries from the Dumpster, with source links and confidence tags, but not write stable memory without review.

Enforce evidence pointers in the Heart Digest. Every digest claim should cite the underlying observations. A synthesis without pointers is just another opaque profile.

Measure against evolving-preference benchmarks. The architecture should be tested against long-horizon belief and preference changes. Until then, claims about improved reliability are design intent, not evidence.

Run Heart inside the always-on agent. Today Heart is consulted manually or through session bootstrap. The target is a persistent cognitive partner that checks Heart before substantive responses and updates candidate memory after meaningful interactions.

Add affective instrumentation. Pulso, the tier for current state, should not depend entirely on manual capture. Tools like VADER, LIWC, and GoEmotions can help identify high-affect windows and audience-shift across channels. Those signals should feed quarantine, not bypass the protocol.

Use cross-agent audit. Different model runtimes have different blind spots. A second agent can audit captures, challenge inferences, and produce disagreements that become explicit dispute flags instead of hidden divergence.

Test whether this scales beyond me. Right now this is N=1. I built it for myself, with markdown and git, because those are tools I can inspect. The open question is whether a person who does not live in files can still meaningfully audit their own model.

Conclusion

Personal AI memory is not just a recall problem. For agents that write, answer, mediate, prioritize, and sometimes help think through decisions, it becomes an identity-modeling problem.

The point is not that the AI should make bigger choices. The point is that it should know the person well enough not to flatten every response into generic competence.

That changes the design requirements.

Facts can live in a knowledge base. Claims about a person need confidence, provenance, corroboration, revisit windows, and a way for the person to dispute the model without destroying the evidence trail.

Brain and Heart are my attempt to make that distinction operational.

Brain stores what the system knows.

Heart stores what the system thinks it understands about the person, with enough humility to say how it knows, how confident it is, when it should check again, and what happens when the person disagrees.

The most important design choice is not markdown, git, tiers, or even the Brain/Heart split. It is who gets to audit the model.

If the user is modeled but cannot inspect the model, personalization becomes an opaque influence layer. If the user can read, refute, edit, and version the model, personalization becomes a negotiation.

That negotiation is the point.