Group Chatbot Memory Needs Explicit Conversation Boundaries

A chatbot belongs to two group chats. Room A discusses an internal quote; someone in room B asks what price was just mentioned. Room B's model request should never include room A's messages, summaries, or retrieved records. That boundary belongs in the application before model inference.

This guide uses LangGraph's current memory and persistence documentation, checked November 13, 2026. It describes an application design, not a confirmed vulnerability in a chat platform. All identities are synthetic; no live group integration or complete bot was tested.

Decide what a conversation means

One history per user may be wrong for group chat. The same person can speak in an internal room, a customer room, and a private conversation. Matching sender IDs should not silently combine all three.

For a collaborative room, the opposite choice can also be wrong: isolating every sender may hide useful context supplied by another participant. Start with the product's intended audience.

Interaction	Typical history scope	Additional decision
Collaborative group discussion	Tenant, platform, room, topic	Which room members may read it?
Personal assistant in a group	Above scope plus user	Is the reply visible to everyone?
Private conversation	Tenant, platform, private chat, user	May persistent preferences be reused?
Support case	Tenant, case, participant scope	Who retains access after transfer?

The Feishu integration article covers the basic request path. This article addresses the scope applied before messages enter history. Check each platform's actual event fields rather than assuming a universal topic ID.

An identifier is not authorization

LangGraph's checkpointer stores thread-scoped state and uses thread_id to resume it. A store supports longer-lived information across threads. Neither mechanism can infer your organization's permissions from an arbitrary string.

This JSON is an application design sketch, not a platform event schema or a complete authorization implementation:

{
  "tenant_id": "demo-company",
  "platform": "demo-chat",
  "conversation_kind": "group",
  "conversation_id": "demo-room-a",
  "topic_id": "demo-topic-1",
  "memory_scope": "group-shared"
}

Resolve these values from a verified event or authenticated context, authorize access, then create the internal conversation ID. A client-supplied room ID must not grant access to that room's history. Use an unambiguous encoding or an internal mapping rather than concatenating unescaped values.

Separate API keys do not fix a shared history key. Nbility enterprise workspace membership and usage controls operate at a different layer from your bot's conversation authorization.

Carry the scope into every storage path

Adding a room column to the messages table is insufficient if a global summary is loaded into every request. Other common mistakes include caches keyed only by question text, preferences keyed by display name, and background jobs that retain the previous room's destination.

Persistent preferences can intentionally span conversations. A language preference may belong to a user, while a project quote belongs to a restricted team. Similarity in vector search is not permission. The application must enforce access around retrieval and propagate it through external tools. The same principle appears in the MCP permissions guide.

Verify with synthetic facts

In a temporary setup, give room A the distinctive sentence “The demo code is Orange Bridge.” Then verify:

1. A follow-up in A can use it; the input assembled for B contains none of it.
2. The same user in B or a private chat still receives the intended isolation. A second participant in A receives the intended shared-room behavior.
3. The checks continue to hold after summarization, with response caching, retrieval, and background summaries enabled.
4. Requests for nonexistent or unauthorized conversation IDs are rejected by the server.

Inspect selected records and redacted scope metadata before inference. A model saying “I don't know” does not prove that restricted data was absent from its input. See safe support logs for what to retain without exposing message bodies.

Test “clear memory” separately. Removing current messages may leave summaries, checkpoints, or long-term records. Define deletion and retention against the full storage inventory. Explicit scopes let a bot remember useful context without making unrelated conversations available to it.