Which channel does this customer prefer?
CRM sync and support both report it. The next agent reads one accepted value and the source behind it.
Example updatePreferred channel: phonePreferred channel: email
Managed database for applications and AI agents
One memory
for every agent.
Always current.
Support, sales and billing agents all read and update the same customer record. When a fact changes, every agent sees the new value, and you can see who changed it, when, and what it was before.
- LongMemEval-S R@5
- 98.5%lexical search, no model
- Free plan
- 5,000 ops / monthREST and MCP
CRM sync
Support agent
Sales agent
Billing sync
CRM sync · 10:32 UTC“New customer: they are based in Berlin.”
Customer 1042Shared record · 4 writers
- City
- BerlinUpdated by CRM sync · 10:32
- Plan
- Not known yet
- Account owner
- Not known yet
Added to the record.
Each bubble is one agent update. Illustrative, no live writes.
Six updates from four agents, with the answer ConceptMem actually gives each one.
- 1current value per fieldolder values move to history
- 4things every change recordswho, from where, how sure, and when
- 7MCP clients ready to connectChatGPT, Claude, Cursor, VS Code and more
Connect from the MCP clients your team already uses, or call the REST API.
ChatGPT
Claude
Claude Code
Cursor
VS Code
Codex
LM Studio
01 / Why a record
Agents remember what was said.
Not what is true now.
Chat history and retrieved passages keep every version of a fact side by side, so the agent has to work out which one still holds. ConceptMem keeps one accepted value per field and moves the rest into history.
- CRM export · 13 Sep, 10:32
Customer 1042 is based in Berlin, Germany. Growth plan, renewal in Q4.
similarity 0.82 - Support thread · 13 Sep, 11:45
“We moved the office to Lisbon last month, can you update our account?”
similarity 0.79 - Sales call notes · 13 Sep, 12:03
Berlin HQ, follow up on the growth plan next week.
similarity 0.77
Berlin or Lisbon? Nothing in the result says which still holds.
Customer 1042
Customercustomer:crm_1042cityLisboncurrent · Support · 11:45 UTC · confidence 0.97Berlinsuperseded · CRM · 10:32 UTC
memory_get returns Lisbon, who said so, and when Berlin stopped holding.
Compare the three approaches in detail
| Chat history and memory notes | Document retrieval (RAG) | ConceptMem | |
|---|---|---|---|
| Ask what is true now | Replays the conversation; the model works out the latest value. | Returns the most similar passages, old and new alike. | Returns the accepted current value. |
| A value changes | The new message sits beside the old one. | A new chunk is indexed; the old one still matches. | The new value supersedes the old one, which stays in history. |
| Several agents work on it | Each conversation or notes file keeps its own copy. | Agents share an index, not a current value. | Every authorized agent reads and proposes updates to the same record. |
| Where a value came from | Somewhere in the transcript. | The source document, if you stored it with the chunk. | Source, actor, confidence and time on every change. |
| What may be written | Whatever the model writes down. | Whatever you index. | Your types, fields and policies decide. Refusals are reported. |
| Passages from long documents | Only what was pasted into the conversation. | What it is built for. | Not offered. Use ConceptMem beside your document retrieval. |
02 / How it works
Model the record.
Govern the writes.
Read what’s current.
01
Agree on the record.
Give every writer the same entity types, fields, and relationships. Choose the constraints that govern incoming updates.
Customerstrict
citystring · singleplanstarter · growth · scaleowner→ Person02
Decide what changes.
Reconcile proposed updates with existing facts. Keep repeated values unchanged and apply, reject, or review changes under your policy.
- Appliednew value, within the rules
- Skippedlower confidence than current
- Refusedoutside the declared domain
- Heldunder the review threshold
03
Read the current state.
Query accepted facts for the next action. Follow relationships or inspect earlier values and their sources when you need more context.
memory_get('customer:crm_1042')cityLisbon
plangrowth
asOf 11:00 → cityBerlin
03 / Connect
Three steps
to one shared
record.
Hosted REST and MCP share one access key and one set of rules, so every proposed update is checked the same way whichever client sends it. The TypeScript SDK is in preview.
- Create a database
Sign up on the free plan and copy its access key.
- Point your agent at it
Add the hosted endpoint to your MCP client, or call the REST API from your application.
- Propose an update, read it back
Send one observation with its source. Check the receipt, then read the record and its history.
{
"mcpServers": {
"conceptmem": {
"url": "YOUR_WORKSPACE_MCP_ENDPOINT",
"headers": {
"Authorization": "Bearer YOUR_WORKSPACE_KEY"
}
}
}
}Use your workspace endpoint and access key from Connections. The MCP guide walks through proposing an update, reading the accepted record, and inspecting its history.
Read the MCP guide04 / Built for B2B SaaS teams
Keep support and operations
on the same record.
Pick the workflow where two systems or teams keep updating the same fields. Map those fields once, and support and operations read the same accepted record.
Is this case still open?
Support resolves it, operations reads it. A reopened case supersedes the resolved status, and both stay in history.
Example updateCase status: openCase status: resolved
Who owns this account now?
A handoff from sales lands as a dated, sourced change, so the next agent never has to guess.
Example updateAccount owner: SamAccount owner: Alice
05 / Built like a database
Guarantees,
not best effort.
Agent memory is usually a notes file or a vector index. ConceptMem is a managed database: writes are checked, ordered and receipted, and no value is overwritten in place.
One current value per field
A change supersedes the earlier value instead of sitting beside it. A field holds several values only when you declare it.
Provenance on every change
Source, actor, confidence and time are required on each mutation and kept in the changelog.
A receipt for every write
Each result lists what was applied, skipped, refused or held for review. There is no silent write.
Writes ordered per workspace
Concurrent agents cannot interleave half-applied changes. Each observation commits in order with its own receipt.
Resumable write plans
Every plan carries an idempotency key. A retry resumes at the observation that failed instead of replaying confirmed ones.
Your records, exportable
Export current records with their evidence at any time, as JSON or markdown. An export is a view; the record stays yours.
06 / Pricing
Start free.
Grow with your workload.
Every plan includes governed writes, current-state reads, history, provenance, review and export. Plans differ in operations, storage and databases, with no automatic overage charges.
Compare plans- Free$0/ monthTry shared records with one agent workflow.5,000 operations / month2 databases · 20 MB
- Build$49/ monthConnect your first application to governed records.250,000 operations / month10 databases · 5 GB
- Growth$149/ monthExpand usage across support and operations.1,000,000 operations / month20 databases · 20 GB
- Scale$399/ monthSupport more workflows, records, and agents.3,000,000 operations / month50 databases · 50 GB
Good questions
What to know before you connect.
Where ConceptMem fits, how updates work, and how to get started.
Didn’t find your answer?Ask the team Read the documentation
What is ConceptMem?
ConceptMem is a managed ontological database for applications and AI agents. It checks proposed updates against your model and policies, consolidates them into current records, and preserves the history and provenance of changes.
How is this different from storing conversation history?
A conversation log tells you what was said. ConceptMem gives you the accepted current record for a customer, project, or case. When a value changes, the earlier value stays in history and the mutation records its source.
Is ConceptMem a vector database?
ConceptMem offers exact lookup, text search over current entities and facts, and traversal of typed relationships. It does not offer vector search. Use it alongside document retrieval when your agent also needs passages from source material.
Can several agents share the same records?
Yes. Authorized agents in a workspace can query the same current records and propose updates under the same rules. Use stable entity references so each agent writes about the same customer, project, or case.
Do I need to model everything first?
Start with one entity type and a few useful fields, or explicitly apply the starter vocabulary. Open classes allow undeclared fields. Choose strict classes or enforce individual fields when you need stronger constraints.
What happens when two observations disagree?
By default, an accepted update to a single-value field replaces the current value and preserves the earlier one in history. You can configure confidence-weighted decisions, rejection, or review. Write results show what was applied, skipped, or flagged.
Does ConceptMem verify that information is true?
ConceptMem maintains the state accepted under your configured rules and received observations. It preserves the evidence behind changes; source quality and reported confidence remain your integration’s responsibility.
Does every update need a hosted LLM?
No. Your application or agent can submit structured observations for deterministic consolidation. Hosted AI is used when the requested feature or configured policy calls for it, such as text extraction, synthesis, or assisted conflict decisions.
Can I export my records?
Yes. Export current records with their evidence from the console, the REST API or the memory_export tool, as JSON or markdown. An export is a derived view: editing it does not change the record, and a correction goes back through a proposed update.
What happens when I reach a plan limit?
Additional data operations pause until the next UTC month or an upgrade. There are no automatic overage charges, your data is preserved, and export remains available. An upgrade raises the allowance without resetting usage.
How do I connect my agent?
Create a workspace access key and connect through the hosted MCP endpoint or REST API. The Connections page and integration guides show the setup. The TypeScript SDK and public types are in preview; public npm publication is pending.
The language of governed memoryA short glossary of the concepts behind ConceptMem.
- Governed state
- Shared database state accepted from observations under the configured ontology and policies. Current state and mutation history are separate views.
- Record
- An entity and its current facts and relations after consolidation.
- Proposal
- A candidate change evaluated by the service. It may be applied, skipped, refused, or held for review.
- Flexible
- Database mode in which agents can propose schema changes with vocabulary and consistency checks. The API value is free; this mode does not override class or field constraints.
- Model-driven
- Database mode based on an explicitly adopted model. Semi-restricted allows validated agent schema proposals; Restricted reserves schema changes for authenticated human editors.
- Open class
- A class that accepts undeclared fields. Supported conformance findings are advisory unless a field is enforced or an opt-in policy refuses the proposal.
- Strict class
- A class that refuses undeclared fields and supported type, value, or relation mismatches. Strictness is inherited; missing required fields remain advisory.
- Supersede
- Replace a previous current fact with a new current value while preserving the earlier value in history.
- Review
- An authorized human or agent decision on a proposal held by policy. A held proposal is not yet current state.
- Canonical ID
- The entity reference returned by the service, typically type:slug. Save it or the entity UUID from the receipt; an input entityRef may normalize differently.
- Observation
- The write primitive. A proposal about the world — entity type, data, optional relations, and required provenance — not a direct edit to stored state.
- Consolidation
- The step that turns an observation into typed operations. Duplicates collapse into the existing record, new values supersede old ones, and policy can refuse a write or hold it for review.
- Ontology
- The schema that governs what can exist: classes, predicates with value types and cardinality, and typed relation types with a domain and range. Strict classes refuse undeclared fields and invalid values. Open classes report supported violations without blocking, unless a predicate is enforced. Required fields remain advisory.
- Fact
- A predicate and value on an entity, with a status of current, superseded, retracted, disputed, or pending review.
- Current state
- The records accepted under the configured rules and received observations. Read the current record for an action, or inspect earlier values and changes through history.
- Provenance
- The origin recorded on every mutation: source, actor, confidence, timestamp, and extraction method.
- Policy
- The per-class and per-predicate rules that decide an update: supersede, confidence-weighted arbitration, rejection, or routing to human review.
- Bitemporal fact
- A fact carrying both valid time (when the value was true of the world) and transaction time (when it was recorded), with historical entity reads along the valid-time axis.
- Projection
- A derived view of database state — a Markdown entity page, a summary, an export. Projections are never the source of record, and editing one changes nothing.
Start with one shared record
Give your next agent
the current record.
Create a database on the free plan, connect an agent over MCP or REST, and propose your first update.