Team Memory de Tencent: cuando los agents comparten memoria, alguien tiene que ser owner

La lectura fácil del último release open source de Tencent es la de los datos. Un vendor cloud chino lanza un sistema que guarda la memoria colectiva de tu equipo y puedes escribir tú mismo el resto del titular. También es la lectura equivocada, y bastan unos cinco minutos con el repository real para superarla.

El 13 de agosto, Tencent Cloud anunció Team Memory, una actualización importante de TencentDB Agent Memory que mueve agent memory de una convenience personal a shared team infrastructure. He revisado el anuncio y el repo en vez de ejecutar la cosa, así que trata esto como desk read, no field report. Esto es lo que es, por qué la parte "team" es la historia real y por qué la preocupación a la que llegará primero gran parte de los lectores occidentales apunta al lugar equivocado.

Conclusiones clave - Team Memory extiende TencentDB Agent Memory desde long-term memory individual a shared team assets: chat history, documents como wiki consultable, code repositories como graph y distilled reusable skills, todo detrás de access controls. - A pesar del nombre, no es una database. Es una suite local-first de servicios TypeScript sobre SQLite con vector search, licencia MIT, y se conecta a Claude Code hablando el propio API protocol de Anthropic. - El deployment por defecto mantiene todo en tu environment, así que la preocupación reflexiva "mis datos van a China" no aplica en gran medida. Los riesgos residuales son governance, una community Chinese-first y una ruta opcional a Tencent Cloud VectorDB. - Shared memory es shared attack surface. La research sobre memory poisoning dice que entradas corruptas se propagan entre sessions, y aquí se propagarían por diseño entre los agents de tus teammates. - Los benchmark claims del vendor son self-reported. La traction en GitHub, algo más de 24.900 stars a 27 de agosto, es real, pero el uptake de developers occidentales parece mucho menor de lo que sugiere la cifra.

Qué ocurrió

El 13 de agosto de 2026, Tencent Cloud anunció Team Memory, el segundo gran release de TencentDB Agent Memory, que open-sourced en mayo. Los key facts, desde el anuncio y el repository:

• Team Memory se compone de cuatro asset types: Chat Memory, historical agent conversations; un LLM-Wiki, project documents consultables en natural language; un Code Graph, repository structure, symbols y call paths; y Skills, una completed troubleshooting session o code review distilled para reutilización.

• Una nueva console, Memory Hub, gestiona teams, agents y tasks, con cada memory item llevando owner, version, status y usage history. Permissions funcionan por user, role y agent, de private a team-wide.

• Los assets se ensamblan por role: un bug-fixing agent recibe el Code Graph y troubleshooting skills anteriores, mientras un requirements agent recibe wiki y business context.

• Funciona entre agent platforms, incluidos CodeBuddy de Tencent, OpenClaw y Claude Code, y el code release v2.0.0 llegó el 3 de agosto, diez días antes del newsroom post.

El claim que vale conservar es el de portability: "the accumulated experience in Team Memory remains fully compatible even if the underlying models or agent frameworks change." Tencent también dice que el proyecto superó 20.000 GitHub stars en sus primeros 90 días y llegó a la cima de GitHub Trending más de una vez. El star count actual sí se puede verificar, 24.912 cuando miré el 27 de agosto, frente a 7.200 registrados por un third-party tracker el 4 de julio, así que la trajectory es plausible. El Trending claim remite al propio post de Tencent y no puede verificarse, así que lo archivaría como marketing.

El release Team Memory de Tencent Cloud extiende el proyecto open source TencentDB Agent Memory de uso individual a uso en equipo, organizando conversations, documents, code y distilled skills como governed memory assets para platforms incluidas Claude Code, según el anuncio del 13 de agosto de 2026. El repository tenía 24.912 stars el 27 de agosto de 2026, según GitHub.

Qué es realmente, leído como practitioner

Primero, el nombre. TencentDB Agent Memory no es una database, no está construido sobre PostgreSQL y no es tecnología TencentDB en ningún sentido importante. Es un conjunto de servicios TypeScript, MemoryCore, MemoryKnowledge, MemoryPanel, MemoryProxy, que guardan en SQLite local con sqlite-vec para vector search, con una ruta opcional a Tencent Cloud VectorDB si quieres scale out. La etiqueta TencentDB es brand adjacency. El database team de Tencent sí ha open-sourced infrastructure real antes, TBase, ahora OpenTenBase, desde 2019, pero este es un application-layer project de esa org y se comporta como tal.

La arquitectura está más pensada de lo que sugiere el star chasing. Memories se distilled por layers, desde raw conversation hasta stable persona-level facts, y retrieval mezcla BM25 keyword search con vector search bajo item y time budgets, que es como mantienes pequeño el injected context. La pieza más clever es Memory Proxy: se sienta entre tu agent y el model hablando tanto Anthropic como OpenAI API protocols e inyecta memory relevante en system prompt. Para Claude Code eso significa sin plugin, sin hook, sin MCP server. Tu client nunca sabe que está ahí.

También es software real, no un README con aspiraciones. Hay one-command Docker deployment, TypeScript y Python SDKs, OpenAPI docs y documentación bilingüe, con commits diarios. El default branch es feat/server_team en vez de main, que te dice lo rápido que todavía se mueve.

TencentDB Agent Memory es una suite local-first de servicios TypeScript que guarda en SQLite con sqlite-vec, layered memory distillation y hybrid BM25-plus-vector retrieval. Su Memory Proxy habla los API protocols de Anthropic y OpenAI, así que Claude Code recibe long-term memory sin plugin ni MCP server, según el README del proyecto, consultado el 28 de agosto de 2026.

Por qué "team" es la historia real

Agent memory como categoría ha sido mayormente single-player hasta ahora. Mem0, el entrant mejor financiado, levantó $24 millones en octubre de 2025 y es el memory provider del agent SDK de AWS. Graphiti de Zep construye un temporal knowledge graph donde facts se invalidan en vez de borrarse. Letta da a cada agent una tiered memory que gestiona por sí mismo. Los tres tratan de un agent recordando su propio pasado.

GitHub stars de los cuatro proyectos open source de agent memory más observados, revisadas 27-28 de agosto de 2026: Mem0, Graphiti, TencentDB Agent Memory, Letta. La entrada de Tencent es la más joven por años.

La apuesta de Team Memory es que la unit of memory va a ser el team, no el agent. Cualquiera que ejecute agents en trabajo real conoce el problema que nombra: project background re-explicado cada session, el fix descubierto el mes pasado que nadie puede reconstruir, el método que funciona viviendo dentro del Claude Code history de una persona. La respuesta de Tencent es tratar todo eso como managed assets con owners, versions y permissions, y ensamblar slices diferentes para agent roles diferentes.

Ese último punto es lo genuinamente nuevo. Un access-control model donde "private" significa que ni siquiera team admins pueden leer un item, y donde un troubleshooting skill que un developer distilled puede reviewed y después compartirse con agents o personas específicas, es memoria como team infrastructure. Ninguno de los proyectos occidentales ship eso como core. Te venden un notebook mejor; este quiere ser el filing cabinet compartido con lock policy.

Mem0, Zep y Letta se centran en un solo agent recordando su propia history. Team Memory trata conversations, documents, code graphs y distilled skills como governed team assets con permissions per-user, per-role y per-agent, assembled por task, según el anuncio de Tencent Cloud y la documentación del repository.

Un cerebro compartido es un objetivo compartido

Esta es la parte en la que el anuncio no se detiene. Memory existe porque context windows más grandes no resolvieron retention: el estudio Context Rot de Chroma mostró 18 frontier models degradándose a medida que aumenta el input, mucho antes de llenar la window. Así que todo el mundo está construyendo memory, y la security research ya alcanzó el porqué es delicado. La agentic threat guidance de OWASP nombra memory poisoning directamente: corrompe el long-term store una vez y cada future session hereda la corrupción.

Ahora haz shared el store. Un troubleshooting skill poisoned no solo engaña a tu agent la semana que viene; engaña a every agent y teammate con quien se comparte, por diseño. Un repository que guarda conversations, documents, code structure y working methods de tu team es también, visto desde fuera, un catálogo ordenado de todo lo que un attacker querría. Las mitigations de Tencent son reales pero procedurales: el ACL model limita quién puede leer qué y los skills deben reviewed antes de compartir, lo que pone a un human en el loop de machine-distilled content. Ese control es exactamente tan fuerte como el review habit que lo respalda.

Nada de esto es razón para no usarlo. Es razón por la que governance features son el producto, y "qué agent puede leer qué memory" merece la misma seriedad que cualquier otra access policy de tu stack, como con agent governance en general.

Research sobre agent security, incluida la agentic AI threat guidance de OWASP, identifica memory poisoning como attack class distinta donde long-term memory corrupta dirige future sessions. Un shared team memory store extiende ese riesgo entre teammates y agents por diseño, haciendo de review-before-share workflows y access control las features estructurales.

La cuestión China, respondida honestamente

Primero voy a declarar la deployment assumption, porque la respuesta cambia por completo según ella. Si self-hosteas el release open source, MIT-licensed y local-first, tus datos se quedan en tu environment. Storage es SQLite local, los LLM endpoints los configuras tú y no necesitas Tencent Cloud account. En ese camino, la preocupación reflexiva sobre un vendor chino guardando la memoria del team no aplica, y vale decir claramente que es la preocupación equivocada para el deployment por defecto.

Las residual concerns reales son más silenciosas. La ruta opcional Tencent Cloud VectorDB sí te liga a Tencent Cloud si la eliges, así que trátala como decisión separada. El repository incluye OpenTelemetry instrumentation, que es hygiene normal para auditar antes de desplegar algo así, no una acusación. La community es Chinese-first: discussions, tutorials, la mayoría del momentum. Y si alguna vez quieres enterprise support, se lo compras a un vendor chino, con las procurement conversations que eso implica en algunas organizaciones.

Una cifra captura mejor la forma de la community que el star count. El proyecto tiene algo menos de 25.000 GitHub stars; su submission en Hacker News a principios de mes recibió dos points y cero comments. Las stars son reales, pero su centre of gravity es domestic. Para equipos occidentales es una caveat sobre de dónde vendrá la ayuda. Para equipos chinos que salen global, es una pista de que esta tool se construyó para cómo trabajan realmente los equipos aquí, una consideración build-versus-buy por sí sola.

Self-hosting de TencentDB Agent Memory, MIT-licensed, mantiene los datos en tu propio environment sobre SQLite local, con model endpoints configurados por el user y sin requerir Tencent Cloud account, según la documentación del repository. Las residual considerations son la ruta opcional Tencent Cloud VectorDB, el standard dependency auditing y una community/support channel Chinese-first.

Qué hacer ahora

Si agent memory está en tu radar, tres pasos, en orden.

1. Hoy: lee el repo, no solo el anuncio. Architecture docs y ACL model son donde vive el diseño real, y el Docker deployment es one command si quieres tocarlo.

2. Esta semana: levántalo contra un repository no crítico y un agent, y observa qué retienen realmente las distillation layers. Vendor benchmarks, Tencent reporta un salto PersonaMem de 48% a 76%, no reproducido por nadie independiente, no sustituyen tu propio corpus.

3. Este mes: antes de importar nada real, escribe la access policy. Qué memories son private, cuáles team-wide, quién reviews un distilled skill antes de compartirlo. La tool te da controls; la policy es tuya.

Dos cosas que no debes hacer. No importes proprietary code o client conversations a un shared store antes de que exista esa policy, porque retroactive permissioning es peor que no tener memory. Y no trates el star count como señal de Western readiness; la community con la que depurarás publica sobre todo en chino. Si estás antes en el viaje y aún evaluando dónde encajan los agents, empieza por el artículo de agentic architecture.

FAQ

¿TencentDB Agent Memory es realmente una database?

No. A pesar del nombre, es una suite de servicios TypeScript que guardan en SQLite local con vector search, sentándose entre tus agents y los models que llaman. La etiqueta TencentDB refleja el team que lo construyó, no la tecnología. Existe integración opcional con Tencent Cloud VectorDB para scale-out, pero el deployment por defecto no necesita ningún database server.

¿TencentDB Agent Memory envía datos a Tencent Cloud?

No en el setup self-hosted por defecto. Es MIT-licensed, guarda localmente en SQLite y llama al LLM endpoint que configures. No requiere Tencent Cloud account. La excepción es la integración opcional Tencent Cloud VectorDB, una elección deliberada, no default behaviour.

¿Funciona con Claude Code?

Sí, y el mecanismo es elegante. Su Memory Proxy habla los API protocols de Anthropic y OpenAI, así que Claude Code, y CodeBuddy de Tencent y OpenClaw, recibe memory inyectada mediante system prompt sin plugin, hook ni MCP server. Apuntas el agent al proxy en vez de al model endpoint directamente.

¿Cómo se compara TencentDB Agent Memory con Mem0?

Mem0 es la opción occidental más establecida: más antigua, mejor financiada, $24 millones levantados en octubre de 2025, e integrada en el agent SDK de AWS. TencentDB Agent Memory es más joven y local-first por defecto, y su feature diferenciadora es team-level governance: owners, versions, permissions y role-based assembly. Si tu problema es que un agent recuerde, ambas sirven. Si tu problema es que un team comparta memory de forma segura, la de Tencent está construida alrededor de eso.

En resumen

Team Memory es un proyecto joven y rápido de un equipo más conocido por databases, y tanto vendor benchmarks como Trending claims merecen el descuento habitual. Pero el design instinct debajo es correcto: una vez los agents hacen trabajo real de team, memory deja de ser personal convenience y se vuelve shared infrastructure que necesita owners, permissions y review. Tencent llegó primero entre los open-source projects, y llegó con algo que puedes ejecutar en tu propio hardware sin enviar nada a nadie. La pregunta que vigilaré no es si el star count sigue subiendo. Es si la disciplina review-before-share sobrevive al contacto con teams con prisa, porque ahí esto funciona o se convierte silenciosamente en una liability.

Si estás decidiendo dónde encaja shared agent memory en tu propio stack, es una conversación que tengo regularmente con clientes. Ponte en contacto.

Fuentes

• Tencent Cloud, "TencentDB Agent Memory Releases Team Memory": https://www.tencentcloud.com/dynamic/news-details/101465 (publicado 2026-08-13, consultado 2026-08-28)

• TencentCloud, TencentDB-Agent-Memory repository: https://github.com/TencentCloud/TencentDB-Agent-Memory (consultado 2026-08-28; star and fork counts revisados 2026-08-27)

• MarkTechPost, "Tencent Cloud Open Sources TencentDB Agent Memory v2.0": https://www.marktechpost.com/2026/08/07/tencent-cloud-open-sources-tencentdb-agent-memory-v2-0/ (publicado 2026-08-07, consultado 2026-08-28)

• Open Source For You, "Tencent Cloud Agent Memory v2": https://www.opensourceforu.com/2026/08/tencent-cloud-agent-memory-v2/ (publicado 2026-08, consultado 2026-08-28)

• PR Newswire via Morningstar, "Mem0 raises $24M": https://www.morningstar.com/news/pr-newswire/20251028sf07039/mem0-raises-24m-series-a-to-build-memory-layer-for-ai-agents (publicado 2025-10-28, consultado 2026-08-28)

• Mem0 repository: https://github.com/mem0ai/mem0 (consultado 2026-08-28)

• Zep, Graphiti repository: https://github.com/getzep/graphiti (consultado 2026-08-28)

• Letta repository: https://github.com/letta-ai/letta (consultado 2026-08-28)

• Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance": https://research.trychroma.com/context-rot (publicado 2025-07, consultado 2026-08-28)

• OWASP, "Agentic AI Threats and Mitigations": https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ (consultado 2026-08-28)

• OpenTenBase (formerly TBase): https://www.opentenbase.org/en/ (consultado 2026-08-28)

• Wikimedia Commons, cover image "African Bush Elephant" (GFDL 1.2, Muhammad Mahdi Karim): https://commons.wikimedia.org/wiki/File:African_Bush_Elephant.jpg (consultado 2026-08-28)