Memory is backed by Feather’s in-house facts store (PostgreSQL). It is the
sole memory backend — there are no third-party memory vendors.
How memory is scoped
Facts are scoped to a(organization, end_user) pair — one memory thread per person, persisting across individual conversations. When a conversation contributes a fact, Feather records which session it came from (source_session_id) for attribution, but the fact itself belongs to the end user, not the session.
Memory is governed by an organization-level toggle. Turn it on or off with GET/PUT /v1/identity/org/memory ({ "memory_enabled": true }). When it’s off, no new facts are ingested and recall is suppressed — but existing facts remain readable and deletable.
You can also toggle memory per assistant revision with the memory_enabled field.
Reading memory
A fact looks like:
state of pending, synced, skipped, or suppressed, so you can tell whether a conversation’s facts have been ingested yet.
Deleting memory
Memory deletion is immediate and scoped to the org and user.Deleting a user’s memory removes the derived facts. It is not a full
right-to-be-forgotten erasure of the end user’s identity and transcripts — for
that, use the identity and privacy tooling.
Next steps
Conversations
How turns, closing, and post-session processing produce memory.
Privacy & data protection
Control PII scrubbing and data retention across memory, transcripts, and audio.