xmemory vs Honcho

Honcho, from Plastic Labs, keeps a reasoned model of whatever it observes. Its centre of gravity is users: every message a peer writes is reasoned over to extract premises and draw conclusions, and the result is a representation of that peer, what they are like, what they tend to want, how they communicate. The same machinery applies to other changing entities, objects, groups and ideas, fed by messages, events and documents. The distinction this page draws is not people versus work; it is representations maintained by reasoning versus records maintained by a schema. That is a different job from xmemory’s, which is to hold the facts a workflow runs on as typed, keyed records under rules you declared.

Documentation reviewed 23 October 2026: Honcho representations, structured outputs and the overview; on our side How xmemory works and XMD.

What Honcho does

Peers (users or agents) exchange messages in sessions. With observe_me on, Honcho builds a global representation of a peer from everything they have written; with observe_others enabled on a session, one peer forms its own view of another from only what it witnessed, so Alice’s model of Bob and Charlie’s model of Bob can differ. A representation holds conclusions, which the docs classify as deductive (certain from the premises), inductive (patterns across messages) and abductive (the simplest explanation of behaviour), plus rolling session summaries and a peer card of basic biographical facts. New messages refine conclusions, and conflicting information is reconciled rather than piled up.

There are three ways to read it. You can fetch a peer’s representation directly, list its conclusions with filters and pagination, or ask: the chat (dialectic) endpoint runs a tool loop over conclusions and messages and answers in prose, or, with a response_format schema, as a typed object with types, required fields and enums honoured, returning null when it has nothing relevant. The docs note that the schema shapes only the final synthesis, that keywords such as minimum, maxLength, pattern and format reach the model as hints rather than being enforced, and that the chat answer is generated, not looked up. Honcho is open source under AGPL-3.0, with a managed cloud.

Where xmemory is stronger, and where it is not the point

Records under a contract, not conclusions from reasoning. A representation is Honcho’s reasoning about a peer or entity, and it is meant to be: the value is in the inference. xmemory does not reason about what something is like. It records what has been established: the customer’s plan, the ticket’s status, the decision that was taken and why, each as a field on a keyed record under an XMD schema, with the allowed values and relations declared up front. If you want to know whether a user seems time-pressed, ask Honcho. If you want to know which of their requests are still open and who owns them, that is a query over records, and the argument for keeping it that way is Schema as the Core of Reliability.

Domain records and relational queries, not retrieved conclusions or shaped answers. Honcho lets you retrieve what it has stored, as a representation or a filtered list of conclusions, and its structured outputs give you an LLM’s answer in the shape you asked for over the conclusions it chose to consult. Neither is a schema-defined domain record: a conclusion is a reasoned statement about a peer, not a Ticket with a status enum and a relation to its Customer. An xmemory record is that structure, validated against the schema when written, and reading it back is a query over all matching stored records, with joins and counts, rather than a listing or a synthesis. For a personalisation feature that is a distinction without much difference; for a billing workflow it is the whole difference.

Resolution by key, not reconciliation by reasoning. Honcho reconciles a conflicting conclusion by reasoning about which to believe. xmemory resolves a conflicting value by key: the new statement lands on the record it names, the old value becomes lineage, and no judgement is involved. Which you want depends on whether updates should reconcile conclusions through reasoning or apply mutations to records under declared rules.

Perspective is Honcho’s feature, not ours. Per-observer representations, where each peer holds its own model of the others, is something xmemory has no equivalent for and does not try to. Field-level access control decides who may read a record; it does not give each reader a different belief about it. If your product needs the second, that is a reason to use Honcho.

On evidence. We have not benchmarked Honcho and will not quote numbers for it. Our four-domain and Splitwise tasks measure updates, deletions, relation changes, aggregation and arithmetic over stored facts (white paper); anyone evaluating both should run those operations through each and test Honcho separately on the user-understanding tasks it is built for.

Choosing

Use Honcho when the product needs to understand the people and entities it deals with: to adapt tone, anticipate needs, hold one peer’s view of another, and ask open questions about them. Use xmemory when the product needs to remember facts about the work and act on them: typed, keyed, queryable, governed. Many products need both, and nothing about either prevents it.

Stored preferences beside a Honcho representation

The sensible split is to let Honcho infer who the user is and to let xmemory store what the user has actually said they want, bounded so an agent can act on it without re-deriving it.

xmd_version: v1
title: Stated preferences
description: What each user has explicitly asked for, on a fixed set of dimensions, as current values. Inferred traits are not stored here.
objects:
  Preference:
    description: >-
      One explicitly stated, ongoing preference of one user on one dimension. A new
      statement on the same dimension replaces the value. Record only what the user
      said they want as a standing rule ("by default, keep replies short"); a request
      about the current reply alone ("keep this one short") is not a preference. Never
      infer a preference from behaviour, tone or frequency.
    fields:
      user_id: { type: str, required: true, description: "Supplied with the input; do not invent one." }
      dimension:
        type: str
        required: true
        enum: [reply_length, formality, language, contact_channel, quiet_hours]
        description: >-
          The specific thing the preference is about. "By default, keep your replies
          short" is reply_length; "email me, not Slack" is contact_channel. Skip
          statements that fit none of these.
      value: { type: str, required: true, description: "The preference as stated, in a short phrase." }
    primary_key: [user_id, dimension]

The things this schema refuses to store, whether the user seems stressed, what they probably mean, how they compare with other users, are exactly what Honcho’s representation is for. The things it does store are the ones an agent should not have to guess at twice.

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.