Agent Memory Is Not a Garbage Bin: Before Writing to Long-Term Memory, Let Jev Judge

The travel assistant hears "I want a window seat this time" and stores it as a user preference, so the next booking may automatically choose a window seat. This error does not come from memory system capacity; it comes from missing a decision step before writing.

Akshay lays out the common agent memory pipeline clearly in the tweet: conversations, tool results, and task results are first sent to an extractor, which proposes candidate memories, including user preferences, facts, and procedures. The problem is that candidate memories cannot be treated equally. In a travel scenario, three sentences look very similar: I usually prefer an aisle seat; book a window seat for this flight; the flight is delayed by 25 minutes. The first may serve future bookings, the second belongs only to this trip, and the third is useless once the flight is over.

Strong memory systems can already record provenance, reconcile against stored facts, and track validity periods. If the source context is sufficient, a window-seat request can be bound to a specific trip. So a decision model should not be added just to duplicate these capabilities.

When is a decision model useful? When the application has its own long-term memory rules that require semantic judgment. A travel app might require: only preferences explicitly stated or confirmed by the user enter account-level memory; preferences inferred from a single booking stay with the trip; passport numbers and payment information never enter general memory; ambiguous candidates remain in the session pending confirmation. These rules can be enforced with ordinary code; the hard part is classifying candidates. Distinguishing long-term preferences, one-off instructions, and weak-evidence inferences requires judgment.

When each candidate is sent to Jev, include the proposed fact, source evidence, and current user/trip/session state. Questions can be typed: Did the user explicitly state it? Should it extend beyond the current trip? What is the retention scope? Is there a genuine risk of later reuse? Jev returns choices, scores, and probabilities. Multiple questions can share state in a single request. The application code then applies thresholds: store the aisle-seat preference at the user level; bind the window-seat request to this trip; keep the delay in the session; reject sensitive fields before they enter general memory.

After passing, send them as episodes to Graphiti. Graphiti handles extraction, entity resolution, provenance, temporal updates, and retrieval. It is an open-source project, and its documentation already describes the Jev dedupe routing: JevClient routes only node dedupe and edge resolution, while generation tasks such as extraction and summarization continue to use a general-purpose LLM. The original article also notes that if Graphiti's current ingestion already satisfies the application, a decision model is unnecessary. Add one when product-specific rules need to be checked.

Jev is TypeSafe's System One model, which can be understood as a semantic decision engine. You provide state and questions, and each question declares its answer shape in advance, supporting Choice, Score, and Noul. It returns probabilities, while ordinary code owns the branching. TypeSafe claims end-to-end latency of 70 to 500 milliseconds and a price of $0.042 per million input tokens, with output free; it also claims to be about 200 times faster and 400 times cheaper than comparable LLM workflows. These are the vendor's own benchmarks and should be viewed as upper bounds, not as promises for every application.

Probabilities matter. Suppose Jev routes a support ticket to billing with a distribution of billing 0.52, technical 0.46, and sales 0.02. Automatic routing would be rash. High-confidence, low-consequence actions can be automated; medium-confidence cases can be confirmed or escalated to a stronger model; low-confidence cases go to a human or require more information. Thresholds live in code, where they can be reviewed and changed.

"No hallucination" also needs to be stated precisely. Jev cannot return options outside the schema or generate malformed prose. But it can confidently choose the wrong valid option. Type safety prevents illegal shapes; it does not guarantee correct judgment. Keep arithmetic, counting, date comparison, and exact string handling in code. Break down judgments that require multi-step hidden reasoning, or hand them to a reasoning model. Stuffing irrelevant context into the state lowers accuracy. Treat user-controllable content as a threat model; prompt injection may shift the answer.

One commenter said the really hard part is not storing, but knowing which old things still apply. Another commenter's bot treated both the old and new time zones as long-term facts; the fix was crude but effective: for facts about the user, the latest one wins; one-off information goes into a dated log and is evicted on expiry. Akshay replied that memory needs regular pruning/cleanup, and a decision model can help with upfront discard.

In implementation, start with a bounded, low-risk decision whose answer can be named. Write the rubric first, then collect representative samples, including ambiguous and adversarial cases. Run it in shadow mode for a while without changing existing behavior. Plot accuracy against confidence, and derive thresholds from the data. Automate the safest branch first, and keep humans or stronger models for uncertain cases. Pin and record the model version, questions, criteria, and thresholds. Questions are also part of the program and should be versioned, reviewed, and tested.

If Graphiti's current ingestion already satisfies the application, don't add it. When product-specific rules need to be checked, put Jev before the write. The core problem of agent memory is not lack of storage capacity; it is judging what is worth storing long term, when it expires, and how strong the evidence is. A decision model turns semantic judgment into typed probabilities, while code retains control. This combination is more stable than letting the extractor run free, and less trouble than treating the memory system as a garbage bin.

References: Akshay's tweet https://x.com/akshay_pachaar/status/2120205022046965836 ; Graphiti open-source repository https://github.com/getzep/graphiti .