6 context types for agent memory
An agent may need the current truth, exact original wording, the outcome of a session, or a pattern across several conversations. Those requests require different forms of context.
A useful memory system stores history once and reads it in six ways.
Facts answer what changed and when. Each claim carries validity dates, so an older truth can be closed without being deleted.
Entities answer “tell me about this thing.” A maintained description combines separate facts about a person, product, or system into one coherent briefing.
Episodes answer “what did they actually say.” The original messages and records preserve exact wording, field names, error codes, and supporting evidence.
Thread summaries answer “how did that session end.” They capture the outcome of an entire conversation, including distinctions such as service being restored while the root cause remains unresolved.
Observations answer “why does this keep happening.” They surface evidence-backed patterns across conversations without presenting correlation as causation.
User summaries provide context before a meaningful query exists. When a returning user only says “hi,” the agent can still begin with their role, setup, and unresolved issues.
The key insight is not to build six separate memory stores.
As the graphic shows, these are six ways to read the same temporal memory graph, with a real-world example. Each reshapes the underlying history for a different job.
This also changes how we should evaluate agent memory. Retrieving related text is not enough. The system must return the right form of context for the question being asked.
Graphiti implements this approach by assembling several context types into one fixed-budget block. Its underlying temporal graph framework, Graphiti, is open source and tracks how facts evolve while preserving their original sources.
Graphiti repository: https://github.com/getzep/graphiti
(don’t forget to star 🌟)
Train your own Jev-style decision model locally!
We just trained our own Jev-style Decision model locally!
With Qwen3.5 0.8B as the base, accuracy jumped from 37% to 65% in just 60 steps (10 minutes of training).
All on just 4GB of VRAM.
This video shows how you can do the same:
Chapters:
0:00 - Intro
0:50 - Set up Unsloth Studio
3:47 - Pick a model and dataset
5:19 - Train with LoRA
7:51 - Test it in the app
10:03 - Same workflow in code
12:38 - Train and evaluate (37% → 65%)
14:46 - Save and run inference
15:24 - Outro
Jev becomes more useful when the same typed decisions sit inside a complete agent loop. Parts 3 and 4 of our Agent Engineering course implement that system end to end:
Part 3: Build routing, guardrails, and approval controls with LangGraph and Jev →
Part 4: Add planning, verification, replanning, and stopping logic →
Good day!
The 37% to 65% jump in 60 steps is the number I'd want broken down by choice type, because a decision model can gain accuracy by learning which options are usually wrong rather than by reading the input. A quick check: hold out one choice from training entirely and see whether the model still ranks it correctly when it appears, which is closer to how it will behave on an incident it hasn't seen before.
The thread summary example is the one I'd test first. A session where service came back but the root cause is still open is exactly what gets flattened into "resolved" when you only retrieve related text.