Conversations, agent state, and user memory

Overview

• MongoDB collections can store conversation messages, task/run state, approved preferences, and memory records.
• A LangGraph checkpointer requires its expected integration contract rather than an arbitrary collection called memory.
• Business claims remain authoritative domain records.

Why this matters

These data types need different updates, query patterns, and retention.

An everyday example

Keep conversations, task checklists, and customer profiles in different sections of the filing system.

A technical example

conversations, messages, runs, approvals, user_memories, documents, and chunks have distinct schemas.

How it works

1. Derive tenant/user
2. Query specific collection
3. Validate ownership
4. Update with concurrency rules
5. Project minimal context.

Architecture and flow

Node services → scoped collections → context builder / workflow / audit.

The insurance assistant example

Memory stores a confirmed language preference; approval stores exact draft authorization; claim status comes from the claim backend.

When to use it

Existing MongoDB application data when schemas and operational requirements fit.

When to avoid it

Avoid one indefinitely growing array containing every message and graph event.

Interview answer

“I model messages, task state, approvals, and memory separately and keep all access tenant/user scoped.”

Benefits, trade-offs, and production considerations

• Use bounded documents, pagination, appropriate TTLs, and optimistic concurrency.
• TTL expiry is not immediate and is not the whole deletion policy.
• Retention for audit records may differ from chat history.