#User shared memory

1 messages · Page 1 of 1 (latest)

abstract kayak
#

ChatGPT has memory, Projects, Custom GPTs, Workspaces, apps, connectors, and agents. The missing layer is scoped context: user control over where each memory or private file may be used.

Today, memory acts as a general personalization layer. That is useful, but too broad when one person uses ChatGPT for personal life, work, clients, teams, education, GPTs, Projects, apps and agents. The same context should not follow the user everywhere.

User Shared Context would let each memory or context block have a clear scope: all ChatGPT, only this Project, only this GPT, selected GPTs or Projects, this Workspace, personal only, professional only, or never use with GPTs, agents, apps, or connectors.

This matters because users need to decide not only what ChatGPT remembers, but where it may influence answers. A writing preference may be global; a brand guide may belong only to one workspace; a client process only to one Project; a private preference should not affect corporate workflows; and an agent should not receive more context than required.

It should also support private files attached to a scope: templates, logos, style guides, reference docs, examples, checklists, signatures, procedures, or small knowledge bases. These files could act as private RAG, available only where permitted.

For Business, Enterprise, and Edu, this would be especially valuable. The challenge is remembering with boundaries: separating user, workspace, team, Project, GPT, and agent context without leakage.

A "Context used" panel could show whether memory, Project, GPT, Workspace context, shared context, files, connectors, or agents influenced the answer.

In short: ChatGPT should not just remember more. It should remember better, with user-controlled scope.

abstract kayak
#

testing, testing, does anyone read this? 😅

grand geode
abstract kayak
#

😅

carmine sierra
#

Do these suggestions actually accomplish anything? -- I'm not entirely sure myself. I have a certain "basic trust" that someone might read them, but there's no real certainty about that. -- @abstract kayak Very interesting approach, by the way!

#

Correction: Of course, I hope someone in a position of influence reads this (someone who can actually reach the developers)

abstract kayak
#

Memory:
{
"id": "mem_001",
"text": "The user prefers concise executive summaries, clear risks, and actionable next steps.",
"scope": {
"mode": "global",
"apps": [""],
"gpts": ["
"],
"projects": [""],
"agents": ["
"]
}
}

{
"id": "mem_002",
"text": "The user manages enterprise ERP integrations, API documentation, and deployment workflows.",
"scope": {
"mode": "custom",
"apps": ["chatgpt", "gmail", "calendar"],
"gpts": ["Enterprise Support", "SQL Assistant", "Documentation GPT"],
"projects": ["ERP Migration", "Customer Onboarding", "Internal Automation"],
"agents": ["ResearchAgent", "DocumentAgent", "CodeAssistant"]
}
}

Context composer:

  1. Load global memories.
  2. Detect the current execution context:
    • current app
    • current Custom GPT
    • current Project
    • current Agent
  3. If custom-scoped memories exist:
    • query the scoped-memory index for memories allowed for those entities.
  4. Merge global memories + matching custom memories.
  5. Deduplicate results.
  6. Rank by semantic relevance.
  7. Inject only the relevant memories into the model context.
vagrant nymph
abstract kayak
#

Ah! Okay, thank you very much! so, I hope to see this implemented one day, good feedback 😅

abstract kayak
# vagrant nymph Yes, there are OpenAI employees in this server. They have a yellow name tag. (Sa...

Yes, it makes sense. Many times they surely read even if they don't respond, especially if the idea touches on delicate internal parts such as memory, connectors, apps and the composer itself.

It seems to me that the latest improvements in memory management go a little in that direction: solving the problem from a common point, instead of patching it separately in each GPT, app or connector. If in the future the global context of each interaction grows, a “user shared memory” layer with configurable scope could fit quite well.

At least I tried to contribute a constructive idea. It may not be perfect, but I think it addresses a real problem. XD

abstract kayak
#

It’s been leaked on X/Twitter that ChatGPT’s memories could be replaced by a summary, and there are already quite a few complaints.

That’s exactly why I think the approach I propose in my suggestion could fit really well: keeping useful context, reducing noise, and giving users more control.

dusty salmon
#

I strongly support this idea, and I would add one important layer: user-scoped memory for each Custom GPT.

When a user works with the same Custom GPT across multiple conversations, that GPT should be able to access selected memories or context from previous conversations with that same user, even across different Projects, if the user explicitly allows it.

For example, a user may have a Custom GPT used as a long-term writing partner, coach, project assistant, business advisor, or role-specific companion. In that case, continuity matters. The GPT should not behave like a completely fresh instance every time a new conversation starts.

A useful option could be a conversation-level flag such as:

“Share this conversation’s context with future conversations using this GPT.”

Or even more granular controls:

  • share with this GPT only
  • share with selected GPTs
  • share only inside this Project
  • share across Projects for this GPT
  • never share with agents, apps, or connectors

This would solve a major continuity problem: today, a Custom GPT can have a stable identity and purpose, but its memory across conversations is inconsistent or unavailable. That makes long-term workflows harder, especially when the same GPT is used across different Projects or invoked inside another active workflow.

Scoped context should therefore not only control what ChatGPT remembers globally, but also allow each Custom GPT to build a private, user-specific continuity layer, with explicit user permission.