Continuity
New session, same knowledge
Agreed terms, exceptions and preferences carry forward, so nobody re-briefs the assistant every morning.
Use case
Assistants that remember.
Session chat forgets everything at close. Agent memory keeps decisions, preferences and facts in a local store, recalled when they matter.
Your assistant meets you for the first time, every time.
Every session starts from zero: agreed terms, exceptions and decisions evaporate at close, so people re-brief the tool that was meant to save time.
- The re-briefing tax. The same context gets typed again every morning, by everyone on the team.
- Lost decisions. What the CFO approved in July is nowhere the assistant can see in August; agent memory is where it belongs.
- Tribal knowledge. The real context lives in veterans' heads, and it leaves when they do.
- Hosted memory. Cloud assistant memory means your decisions accumulate on infrastructure you do not control.
Noted once, known from then on.
Memory is retrieval, not magic: facts embed locally and surface by meaning.
01
Note
The agent notes facts worth keeping as it works.
02
Store
Memories embed into a local store you can open and audit.
03
Recall
Relevant memories surface by meaning, not by session id.
04
Ground
Recall lands in context before the answer is written.
Institutional knowledge that survives the session.
The value compounds: every decision the assistant witnesses makes the next answer better.
Auditable
Memory is data, not a vibe
The store is inspectable: read what the assistant believes, correct what is wrong, delete what should not persist.
Private
As sensitive as the documents
Memories distill your decisions and terms, so they live under the same roof as the files, fully local.
One store, wired in at build.
Attach a memory to the agent and recall happens before every generation, from a store that never leaves the machine.
using LMKit.Agents;
using LMKit.Model;
var model = LM.LoadFromModelID("qwen3.5:9b");
var embedModel = LM.LoadFromModelID("embeddinggemma-300m");
var memory = new AgentMemory(embedModel);
var agent = Agent.CreateBuilder(model)
.WithMemory(memory)
.Build();
var reply = await agent.RunAsync(
"Draft the Meyer renewal with our agreed settlement terms.");
// Recall happens before generation; the store stays local.On LM-Kit One, memory is a field: facts persist server-side under an id and recall as hidden context, and a server agent carries its own shared store.
curl http://your-server:5189/lmkit/v1/chat \
-H "Authorization: Bearer your-server-token" \
-H "Content-Type: application/json" \
-d '{"agent":"account-assistant",
"memory":"team-finance",
"messages":[{"role":"user","content":"Draft the Meyer renewal with our agreed settlement terms."}]}'
# Facts from this exchange persist under the memory id;
# earlier facts return as hidden context on every channel.The technology underneath.
Memory is retrieval infrastructure, and every layer of it is documented.
Store
Agent memory
The persistent store agents note into and recall from, local and inspectable.
How agent memory worksRecall
Embeddings
Meaning-based recall comes from local embedding models, never a hosted API.
How embeddings workPersist
Vector storage
Built-in local vector storage, or Qdrant and pgvector when you already run them.
How storage worksIn practice
Memory at work: customer support
The support use case shows this pattern deployed: an assistant that remembers customer context across sessions, grounded in your docs and governed by policy. On LM-Kit One, server-side agents bundle memory with prompt and tools, adopted by name from any client.
The support use caseFrequently asked questions.
What exactly does the assistant remember?
Facts it noted while working: agreed terms, decisions, preferences, corrections. Memory is a retrieval store, not a transcript; entries embed locally and surface by meaning when a new request touches them.
Can we see and edit what it believes?
Yes, and that is the point. The store is data you can open: read every memory, correct wrong ones, delete what should not persist. Memory an operator cannot audit is a liability, not a feature.
Where does the memory live?
On your infrastructure, in the built-in local store or a vector database you already run. Decisions and terms are as sensitive as the documents they came from, so they stay under the same roof.
How does this work for a whole team rather than one machine?
Deploy LM-Kit One and define the assistant server-side: prompt, tools, and memory bundled as one agent that clients adopt by name, so every channel shares the same remembered context under the same governance.
Private Document Intelligence