Single-hop
"What plan is this user on?" One fact, one place.
Architecture
How Maximem Synap works
Published Updated
Memory is not a storage problem alone. It is an active context-management problem. This page walks through how a message becomes structured, scoped memory, and how each layer was designed to prevent a specific failure we watched happen in production.
01The trilemma
Context management has three jobs
Your agent does not know what it does not know. The agent that needs context is the same agent that is missing it. So storing and searching is not enough. Managing context well means doing three things at once.
Job
What it means
The failure when it is missing
Capture
Learn what matters from the conversation, with high enough recall
A 32-day audit of 10,134 stored entries found 38 usable. A 97.8% junk rate. The system stored first and extracted never.
Compact
Shrink history without losing signal, with high enough precision
An 18,282-token context compressed to 122 tokens, and accuracy dropped below having no memory at all.
Recall
Surface the right information when the agent needs it, not when it guesses
A Pro customer was told twice they upgraded, then sent the upgrade link fifteen turns later.
One system, three ways to fail. Synap was designed around all three.
02The lifecycle
What happens to a message after you send it
Every message flows through the same arc. It is ingested, its meaning is extracted into structured memories, those memories are stored across a vector, graph, and file store, and they are retrieved to enrich the next turn. The first three stages run asynchronously and never block your app.
Scroll the diagram sideways to follow the full path →
Stage 1
Ingest
You record a turn or submit a document through the SDK, and the call returns immediately with an ingestion ID. Chat and text, audio through speech-to-text, documents and images are all taken in natively rather than routed through a converter. The scope identifiers you pass decide where the memory lives.
Stage 2
Extract
The content runs through a multi-stage pipeline: categorize, extract structured memory, chunk, resolve entities, organize.
Stage 3
Store
Processed memories are persisted in a vector store for semantic similarity and a graph store for entity relationships, with source documents kept in a file store, all scoped to the right level.
Stage 4
Retrieve
On the next turn, Synap searches the applicable scopes in parallel, on the fast path by default or the accurate path when the question needs breaking apart, ranks the results, and returns the most relevant memories within your token budget. Most reads never leave your process. Context is pre-fetched while the conversation is still going.
Accepted uploadstxtmdjsonpdfdocxxlsxpptxpngjpgjpegwebp
03Extraction
Extraction is the first step, not the last
Most memory systems store raw text and hope retrieval sorts it out later. That is how a system ends up storing “user mentioned a plan” instead of “user upgraded from Starter to Pro on April 3.” No retrieval algorithm recovers that lost precision.
Synap inverts the order. It identifies structured knowledge from the raw conversation first, each piece extracted with its surrounding context: facts, preferences, episodes, emotions, temporal events, procedures, plans, habits, and whatever else matters to your agent. The set of types is not fixed. It is defined by the Custom Context Architecture generated for your agent, so a support agent and a coaching agent extract different kinds of statement from the same sentence. Retrieval quality is bounded by extraction quality, so the right information enters the system with the right structure from the start.
One turn, four statements
“Quick one before I run. I’m at Google now, senior eng on the payments team. Honestly just send me a written summary rather than a call. Oh and our contract renews 1 March. Still annoyed the refund took three weeks.”
Fact
The user works at Google as a senior engineer on the payments team.
Preference
The user prefers written summaries over calls.
Temporal
The user's contract renews on 1 March.
Emotion
The user was frustrated by the delay in the refund.
Each statement stands on its own and is retrievable on its own, which a stored passage of conversation can never be. Which types exist, and how aggressively each is extracted, comes from the Custom Context Architecture for this agent; the four above are what a support agent would keep from that turn.
04Entity resolution
“Sarah,” “Sarah Chen,” and “SC” are the same person
Without entity resolution, a system stores three unrelated strings and retrieves whichever one happens to match the query. Synap resolves entities automatically during ingestion and during later consolidation cycles, with no extra SDK calls.
It uses four strategies in descending order of confidence, so “Alex from billing” resolves to a different person than “Alex from engineering.” New entities auto-register at the customer scope, and the registry builds itself into an organizational knowledge graph as conversations happen. When a match is ambiguous, the entity goes to a review queue instead of a silent wrong guess.
Exact match Alias match Semantic match Contextual match
05Forgetting
A change should overwrite. A vaguer version should not.
When something about a person changes, the customer-facing agent has to stop repeating what is no longer true. Most memory systems get that half right and quietly lose detail on the way. Synap will not make that trade, and the two cases below are the difference. It will, however, remember what was true earlier, in case the customer references it (provenance management).
What was stored
The user lives in Chicago.
What arrives
"I moved to Berlin."
Replaced
The old statement is retired, linked to the one that replaced it, and the agent stops mentioning Chicago.
What was stored
The user takes 20mg of Atorvastatin daily for cholesterol management.
What arrives
"I take a cholesterol medication."
Both kept
The newer statement is poorer than the one it resembles, so it does not replace it. Nothing is discarded.
Nothing is destroyed by an update. The previous version is kept, marked historical, and linked to what replaced it, so you can always ask why the agent believes something and read the answer rather than guess at it. That is provenance, and it is what makes the two cases above auditable instead of merely claimed.
06Compaction
Compaction is not summarization
A naive summarizer throws away the details that mattered because it has no way to know what will be needed downstream. Synap uses adaptive compaction strategies chosen for the conversation, and every result includes a validation score, a preserved-facts count, and a compression ratio.
If the score drops below a threshold, you know critical information was lost and can retry with a less aggressive strategy. Compaction reduces the current conversation’s footprint; retrieval brings in knowledge from past conversations. A production turn does both.
ConservativeBalancedAggressiveAdaptiverecommended
07Scoping
One user’s memory never leaks into another’s session
Most systems scope everything to the user, which breaks the moment you have more than one organisational boundary. Synap supports a hierarchical scope chain, Client, Customer and User, plus the conversation itself. Memories are stored at the right scope at ingestion, and retrieval respects those boundaries automatically, preferring the narrowest applicable scope.
Client · your whole app
Shared product knowledge, visible to everyone
Customer · Acme
Policies, team, and shared projects for this tenant
User · Alice
Facts, preferences, and episodes about this person
private to Alice
Customer · Globex
Policies, team, and shared projects for this tenant
User · Bob
Facts, preferences, and episodes about this person
private to Bob
When three levels is not your shape
Define your own hierarchy at any depth, with the names you already use, and have every level mean something real to retrieval. A hospital group runs hospital → department → clinician → patient, and “department” is a boundary the system respects rather than a label it stores. Levels are declared once, per deployment, and retrieval honours them on every query without a filter in your code.
Your organisation’s context lives at the top
The client level is where your organisation’s own knowledge sits: product facts, policies, pricing. It reaches every agent that should see it and none of the users or tenants beneath it that should not. It can be uploaded as files, sent over the API, or kept current through first-party connectors. The connectors, on the integrations page →
08Recall
Recall is not one problem. It is four.
Multi-hop
"Given what they bought and complained about, what should I offer?" A chain across sessions.
Temporal
"What changed since last month?" Reasoning over time.
Preference
"How does this user like things done?"
A retrieval system that handles the first one is not a memory system. The fast path is built for the first and fourth, inside a live turn. The accurate path exists for the second and third.
09Storage and retrieval
Three stores, two retrieval speeds
Synap stores memory in a vector store for semantic similarity, a graph store for entity relationships, and a file store for raw documents, and queries them together. Retrieval has two modes, so the agent spends latency only where it pays off.
Fast
Vector and graph search, tuned for low latency
The default in the agent hot path, built for interactive turns where the response cannot wait.
Accurate
Adds subquery decomposition and reranking
For high-value or complex queries, where deeper recall is worth the extra work.
Anticipatory retrieval
While the conversation is still going, Synap works out what the agent is about to need and puts it in reach before it is asked for. Most reads are served from context already fetched into your process. For a voice agent, a network round trip is audible; this is the difference between a natural turn and a pause.
Resilient retrieval
Retrieval runs several techniques at once and merges them into one ranked answer. If one of them has a bad day the answer narrows rather than disappearing, and the response tells you that it narrowed. Your agent keeps talking.
10Consolidation
Memory that is maintained, not just stored
Memory that only ever grows is a liability: duplicates pile up, contradictions sit side by side, and every retrieval has to wade through both. Synap works on the stores in the background at three cadences, modelled on how a brain handles the same problem.
Meditation
Every few hours. A light pass.
Nap
Once a day. Deeper than meditation, lighter than sleep.
Sleep
Your product's quiet hours. Deep consolidation, and conscious forgetting.
The heavy work happens when your traffic does not need the capacity. The light work happens often enough that the agent is never operating on a stale picture.
11Architecture
A memory architecture designed for your agent
A customer support agent cares about ticket history and plan details. A voice concierge cares about guest preferences and booking constraints. A universal memory model serves both badly.
Synap generates a Custom Context Architecture (MACA) for each agent from a use-case description you provide. It governs what is extracted, how it is scoped and stored, how it is retrieved, and how long it is retained. You describe the agent; Synap derives the architecture. There is no schema to hand-author.
The architecture is authored by a frontier coding model and validated by two further frontier-model judges before you ever see it. It is never applied on its own: a person on your side reviews and approves it, it is versioned, and any version can be rolled back. You describe the agent; Synap derives the architecture; you keep the final say.
12Multi-agent
Context that survives the handoff
Production agents are rarely one agent. They are a router, two or three specialists, and a human escalation path. If those agents cannot share context, the customer repeats themselves at every handoff.
Synap handles multi-agent natively. Agents share a central context layer while keeping their own agent-specific memories, and the scope chain handles isolation.
13The numbers
92% on LongMemEval. Under 15ms at P75.
These are a consequence of the architecture described above, not of prompt tricks or model selection. Every layer addresses a specific failure mode observed in production and in the community. The methodology is published and the eval harness is open source, so you can verify every number.
Get started
Start building with Maximem Synap
No credit card required. Google or GitHub sign-in.
Scoping call → eval on your data → trial. No card required.