Description:
I want to flag three related issues that together make Supermemory significantly harder to use than it should be for a straightforward use case: a single user running multiple connectors and plugins against a unified memory store.
1. Deprecated documentation is still being served without clear warnings
The Organizing & Filtering Memories page shows containerTags as an array with working code examples. The Container Tags concept page says the array form is deprecated, containerTag is a single string, and V4 only accepts the singular form.
Both pages are live, both look current, and there is no deprecation warning on the outdated page pointing users to the correct one. The result is that developers read the wrong page, build against deprecated behavior, and have no obvious way to know they've done so until something breaks or they happen to find the other page.
The deprecated examples should either be removed or marked clearly with a notice that directs users to the current API behavior.
2. No server-side tag normalization for connectors and plugins outside developer control
My use case: one user, multiple connectors and plugins, unified memory across all of them. This seems like a primary use case for Supermemory.
The problem is that many connectors and third-party plugins hard code their own containerTag values or derive them from internal logic the developer cannot override. Since Supermemory applies no server-side normalization after receiving a write request, memories end up scattered across disconnected tag namespaces with no way to unify them at the query layer.
A simple account-level or API-key-level default tag injection rule would solve this entirely. Something like: "if the incoming request matches these criteria, append or override the containerTag with this value." This would give developers control over tag consistency even when the client cannot be modified.
3. The playground assistant cannot answer basic configuration questions about Supermemory's own API
The embedded assistant in the Supermemory playground was unable to definitively explain how containerTag works, what the difference between the deprecated and current field is, or how to configure unified memory across multiple connectors. It deferred to external documentation that itself contained the contradictions described above.
If the playground assistant is positioned as a configuration and onboarding resource, it should have accurate, current knowledge of Supermemory's own API behavior. As it stands it adds confusion rather than reducing it.
These three issues compound each other. A developer trying to configure a basic multi-connector setup hits contradictory docs, gets no useful guidance from the assistant, and then discovers there is no platform-level solution for the underlying problem anyway.
All three are fixable. Happy to provide config examples, conversation logs, or any other context that helps.
Drew Richburg (@Drewlius)
Description:
I want to flag three related issues that together make Supermemory significantly harder to use than it should be for a straightforward use case: a single user running multiple connectors and plugins against a unified memory store.
1. Deprecated documentation is still being served without clear warnings
The Organizing & Filtering Memories page shows containerTags as an array with working code examples. The Container Tags concept page says the array form is deprecated, containerTag is a single string, and V4 only accepts the singular form.
Both pages are live, both look current, and there is no deprecation warning on the outdated page pointing users to the correct one. The result is that developers read the wrong page, build against deprecated behavior, and have no obvious way to know they've done so until something breaks or they happen to find the other page.
The deprecated examples should either be removed or marked clearly with a notice that directs users to the current API behavior.
2. No server-side tag normalization for connectors and plugins outside developer control
My use case: one user, multiple connectors and plugins, unified memory across all of them. This seems like a primary use case for Supermemory.
The problem is that many connectors and third-party plugins hard code their own containerTag values or derive them from internal logic the developer cannot override. Since Supermemory applies no server-side normalization after receiving a write request, memories end up scattered across disconnected tag namespaces with no way to unify them at the query layer.
A simple account-level or API-key-level default tag injection rule would solve this entirely. Something like: "if the incoming request matches these criteria, append or override the containerTag with this value." This would give developers control over tag consistency even when the client cannot be modified.
3. The playground assistant cannot answer basic configuration questions about Supermemory's own API
The embedded assistant in the Supermemory playground was unable to definitively explain how containerTag works, what the difference between the deprecated and current field is, or how to configure unified memory across multiple connectors. It deferred to external documentation that itself contained the contradictions described above.
If the playground assistant is positioned as a configuration and onboarding resource, it should have accurate, current knowledge of Supermemory's own API behavior. As it stands it adds confusion rather than reducing it.
These three issues compound each other. A developer trying to configure a basic multi-connector setup hits contradictory docs, gets no useful guidance from the assistant, and then discovers there is no platform-level solution for the underlying problem anyway.
All three are fixable. Happy to provide config examples, conversation logs, or any other context that helps.
Drew Richburg (@Drewlius)