Memory for the next task: HaroCue’s design and tradeoffs

Keep the message that changed the plan

We call the original text evidence, and a reusable statement drawn from it a memory entry, or claim. The original meeting notice says ‘Thursday at 2 p.m., second floor.’ The room-update message says ‘Move to Bamboo on the third floor; keep the time.’ Keeping both messages lets a person check the source of both the old room and the updated room. The memory service is the HaroCue code that checks and stores these records. The model submits proposals to it.

Both original text and memory entries live in local SQLite. Evidence retains its source, observation time and citation spans. An entry cites that evidence and records validity times and relationships to other entries. Lexical and graph indexes help find the records, leaving the original available for review when memories are reorganized.

The audited inputs are authorized application observations and explicit user input. If extraction uses a cloud model, original text within the authorized ranges goes to that configured model. Local storage does not make extraction offline.

When can a proposal become a stored entry?

Given the room-update message, the model can propose a new memory: ‘The review moved to Bamboo on the third floor,’ citing the relevant passage. The memory service checks that the passage belongs to evidence authorized for this request. An out-of-bounds citation is rejected. The service assigns scope and record identities; source text is read as data.

A revision check handles another rejection case. If the evidence or expected state changes while the model generates a proposal, a stale snapshot cannot simply become the latest memory. The write commits only while the expected revision still matches. These checks establish a valid source trail; whether the statement interprets that source correctly still needs review.

The diagram assumes that the proposal is accepted, its transition relation is confirmed and its source remains available. A write receipt records what the service admitted, rather than certifying the meeting arrangement.

On Thursday, exclude the old room before answering

Lexical search matches specific terms such as ‘review’ and ‘Bamboo’; graph search adds entity connections. After the results are fused and ranked, the service checks the current records. Once the room change is confirmed, ‘second-floor review’ is the old arrangement and is excluded from a current reply even if retrieved. ‘Bamboo on the third floor’ needs support from the available room-update message before Cue can use it and show the source.

Time changes that decision. Seeing an update on Wednesday does not make the meeting take place on Wednesday. Observation, recording and validity times are separate; unknown validity stays unknown. If two updates name different rooms and the conflict is unresolved, a higher retrieval score is insufficient to use one as a certain answer.

The current default uses lexical and scoped graph candidates. Optional vector retrieval requires an explicitly configured local embedding service and is off by default. New wiring shared by the product UI, Assistant and Cue remains a development candidate; real retrieval quality and latency are still untested.

A changed room, a misread room and a forgotten room

If the source says third floor but the entry says second, the interpretation needs correction. If Monday really meant second floor and Wednesday moved the meeting to Bamboo, the world changed. The first uses a correction relation; the second preserves a transition and its timing. Users can inspect the source excerpt, application and times before deciding how to correct it.

Forgetting handles withdrawal: once evidence or an entry is removed, dependent memories must stop being used. Installed single-entry forgetting can also clear overlapping entries. A development candidate preserves other independently supported entries from shared evidence and suppresses re-extraction of forgotten content. That change is not publicly released.

Historical inspection also obeys source deletion and forgetting state. Stopping use and clearing records does not promise immediate erasure of old in-memory copies, database pages or external backups.

What two acceptances and one rejection tell us

Experiment note: the three requests totaled 10,898 tokens. Vendor benchmarks and differing protocols are not used as a speed or quality ranking here.

What changes when the memory object changes?

Systems can choose different objects to carry information into the next task. Mem0, Graphiti and Letta represent three publicly implemented routes. Here we compare their organization; configuration, migration and deployment details are in the notes below.

What to record in the next round

First, retain complete model outputs and rerun the revised extraction and consolidation prompts, recording why proposals are admitted or rejected. Then use one synthetic set to test recall after changes, conflicts, expiry and forgetting: Bamboo should return when applicable, and the old second floor should stay out of current replies. Record optional embedding quality and timing separately. Public release of the new backend still requires installation and upgrade acceptance.