xmemory vs Graphlit

Graphlit and xmemory get compared because both say “knowledge graph” and both say “memory”. They mean different things by both words. Graphlit remembers what your content contains: it pulls in documents, email, Slack, meetings and web pages, extracts the people, organisations, places and events mentioned, links them to their sources, and lets you ask questions with citations. xmemory remembers what your agents know and have decided: typed records under a schema you wrote, updated by key as the world changes, and queried as state. One is a memory of sources; the other is a memory of facts that are true now.

Documentation reviewed 23 October 2026: Graphlit key concepts, semantic memory, platform overview, MCP integration; on our side How xmemory works, XMD and the API.

What Graphlit does

Content comes in through one-off ingestion or feeds, recurring connectors to more than thirty sources. A workflow runs it through preparation (text extraction, vision models for PDFs, transcription), extraction (entities, relationships, summaries) and optional enrichment from external data. Extracted entities are observables, Schema.org types such as Person, Organization, Place, Event, Product, Software and Repo; each observation links an entity to the content, page and timestamp where it appeared, so the graph is always anchored in sources. Retrieval is hybrid search with date and entity filters, reranked sources for custom RAG, and conversations that answer with citations. An MCP server exposes this to agents, and Graphlit frames the whole thing as the agent’s semantic and episodic memory.

For “everything we have ever been sent, searchable and connected”, it is a capable managed service, and it does a great deal of ingestion work you would otherwise build.

Where xmemory is stronger

The schema is yours. Graphlit’s entity types are Schema.org’s: a Person has a jobTitle, an Organization has what Schema.org says it has, and the docs we reviewed describe choosing among built-in observable types rather than defining your own. That is the right call for a platform whose job is to recognise the same person across email and Slack. It is the wrong shape for an agent’s working state, where the thing you need to remember is Deal.stage from a list of five values, Incident.severity as an integer, or Policy.applies_to as a relation. Graphlit does let you extract custom structured output: extractText takes a caller-defined JSON tool schema and a prompt and returns the fields you asked for. What it returns is a result, not a record. An XMD schema is a persistent definition the instance owns: the same shape on every write, with identity, allowed values and relations that decide how each new extraction merges into what is already stored.

Facts update; observations accumulate. In Graphlit a fact is an observation of a source. If a contract renews, the renewal document is ingested and a new observation joins the old ones; the graph is a faithful record of what was said where, and “what is the current term” is a question you answer by reading the newest source. The pages we reviewed do not describe editing or superseding an entity’s facts directly. In xmemory the account’s record has a renewal_on field, the renewal text updates it by key, and the previous value stays as lineage. The Why page shows the pattern on the “who is Kevin’s manager” case.

Reads are queries over your records, not over content metadata. Graphlit’s read API is more than the conversational path: queryContents takes structured filters and returns content with its metadata and entities, and their examples aggregate that metadata in application code. What you are querying is still content and the observations extracted from it. xmemory translates a question into SQL over your own typed domain records, so joins across objects, counts over a field you declared, and “which required values are still empty” are answered in the store, over all matching stored records, with the rows returned for code to act on. This is the argument of Schema as the Core of Reliability.

What happens to a sentence the agent writes. An agent can write to both: Graphlit’s ingestText, including over MCP, accepts a sentence like “Acme prefers Tuesday calls” as content. The difference is what happens next. In Graphlit it becomes a content item with extracted entities and observations, retrievable by search. In xmemory it is extracted against the schema, matched to Acme’s record by key, and applied as a field value, in the same API the agent reads state from.

On evidence. We have not run Graphlit on our benchmarks and will not quote numbers for it. Its documentation positions it as a content and retrieval platform, which our four-domain and Splitwise tasks are not designed to measure; those tasks test updates, deletions, relation changes, aggregation and arithmetic over stored facts, the operations this page argues are the difference (white paper, method and numbers in Chasing AI memory SOTA). If you evaluate both on your own workload, test Graphlit on source retrieval and citation quality across your connectors, and xmemory on state updates, relational queries and missing-value checks over your schema.

Choosing

Choose Graphlit when the problem is content: many sources, continuous sync, “what do we know about this company across everything we have”, answers with citations. Choose xmemory when the problem is state: what the agent has established, decided or been told, kept correct as it changes and read by code. They combine naturally, Graphlit as the memory of sources and xmemory as the memory of what is true, with the agent in between.

Graphlit’s observables as an XMD schema

Suppose Graphlit has already found the people and organisations in your inbox. The state an agent needs about an account is a different object, and it looks like this. The example assumes the identifiers are supplied with the input, the way a CRM id would be, rather than inferred from names.

xmd_version: v1
title: Account state
description: Current commercial state of each customer account and the people at it, as the agent learns it.
objects:
  Account:
    description: >-
      One customer organisation, identified by the account id supplied with the
      input. A statement about its plan, stage or renewal updates the existing record.
    fields:
      account_id: { type: str, required: true, description: "The account identifier supplied with the input; do not invent one." }
      name: { type: str, required: false, description: "Display name as commonly used." }
      plan: { type: str, required: false, enum: [free, team, pro, enterprise] }
      stage:
        type: str
        required: false
        enum: [prospect, trial, active, churned]
        description: >-
          Commercial stage. A signed contract or first payment is active; a
          cancellation or non-renewal is churned.
      renewal_on:
        type: str
        required: false
        description: >-
          YYYY-MM-DD of the current contract end. Set it only when the text states a
          full date, or a month and year that can be resolved to the last day of that
          month; a month alone is not enough.
    primary_key: [account_id]
  Person:
    description: A person at a customer account, identified by the person id supplied with the input.
    fields:
      person_id: { type: str, required: true, description: "The person identifier supplied with the input; do not invent one." }
      name: { type: str, required: false }
      email: { type: str, required: false, description: "Current work email, lowercased; may change." }
      title: { type: str, required: false }
    primary_key: [person_id]
relations:
  works_at:
    description: Connect a Person to the Account they work for; a change of employer moves the link.
    objects:
      person: { type: Person, on_delete: cascade }
      account: { type: Account, on_delete: nullify }
    keys:
      one_account_per_person: [person]

Graphlit’s Organization and Person observables are the raw material here, and a good source for name and email. What the schema adds is the state those entities do not carry: plan, stage and renewal_on, each bounded and each updated in place. “Account acc_42 (Acme) renewed on Pro through March 2027” matches the acc_42 record, sets plan to pro and renewal_on to 2027-03-31, and leaves the previous term in lineage; nothing is re-ingested. A person whose work email changes keeps their record, because the key is the supplied id, not the address.

Why we think this matters, and for whom

xmemory works well for short-running agents, and it is at its best for repeated tasks, where each run adds to a body of knowledge the next run can use. Long-horizon agents deserve a special mention, because there is very little objective evidence yet about what memory design works for them. Our working belief, and the reason xmemory exists: an agent running a long, multi-step task does better on structured state than on accumulated context. A schema gives it an explicit feedback loop at write time (what was accepted, what was rejected, what changed), so memory is updated rather than bloated and the trajectory stays on course: fewer re-reads, faster steps, more reliable outcomes.

If that is your workload, try xmemory on it. We are building objective measurements for this claim. The Toloka evaluation is our first independent measurement of the benefits of structured memory; evaluating changing working state over long-horizon tasks is next, and we would welcome collaborators on it. Write to info@xmemory.ai.