La memoria compartida de agentes tiene un problema de access control, y nadie lo ha resuelto

Aquí va una afirmación que habría rechazado hace un año: la parte difícil de agent memory nunca fue conseguir que un agente recordara. Es decidir qué ocurre cuando cincuenta agentes recuerdan la misma cosa equivocada. La memoria de un solo agente es un problema de convenience. En cuanto la memoria se comparte por un equipo, se convierte en un problema organizacional de access control, con semantics de correction, deletion y conflict, y esas son exactamente las features donde los productos actuales son más débiles.

Dos vendors lanzaron respuestas a esto con semanas de diferencia. El release Team Memory de Tencent Cloud, que cubrí en un artículo separado cuando se lanzó, hizo open source un governed memory hub el 13 de agosto. Asana lleva ejecutando silenciosamente desde finales del año pasado la versión cerrada y platform-bound, Agentic Work Management, con sus AI Teammates. Este artículo no es otro announcement recap. Es la comparación que los anuncios se saltan: qué hace realmente cada sistema cuando una memoria necesita corregirse, borrarse o adjudicarse, y quién dentro de una organización decide.

Conclusiones clave - Shared memory convierte un hecho incorrecto de molestia para un user en herencia de todos los agentes. La governance layer, no la retrieval quality, es ahora la feature estructural. - Team Memory de Tencent ofrece el access model más explícito, cuatro visibility tiers, loadouts por agente, private by default, pero no un proceso documentado de correction o expiry para un hecho ya consumido por otros agentes. - Agentic Work Management de Asana resuelve bien el caso de confidential leak al heredar los permisos existentes del Work Graph, pero la memoria vive dentro de la plataforma Asana y sus correction semantics son opacas. - Graphiti de Zep es la única implementación mainstream con una respuesta principiada a stale facts: invalida en lugar de borrar, conservando history. Pero gobierna la memoria de un agente, no de un equipo. - Nadie ofrece conflict resolution para el caso en que dos agents hayan escrito hechos contradictorios sobre lo mismo. Hoy la pregunta se responde con "retrieval ranking", que no es una respuesta.

Qué ocurrió

En las primeras dos semanas de agosto, shared agent memory pasó de research topic a shipping category. Dos eventos sirven de ancla:

• El 13 de agosto, Tencent Cloud anunció Team Memory, la extensión a escala de equipo de su proyecto open source TencentDB Agent Memory. Conversations, documents, code graphs y distilled skills se convierten en governed team assets con owners, versions y un visibility model de cuatro niveles, ensamblados por agent role.

• Una semana antes, el fireside chat de VentureBeat con el CPO de Asana Arnab Bose dio el primer detalle técnico real de Agentic Work Management, AWM, el sistema shared-memory detrás de AI Teammates de Asana, que Asana dice ya está en production con clientes como FedEx.

Alrededor están las capas open source de memoria de un solo agente, Mem0, Graphiti de Zep, Letta, donde sigue viviendo la mayor parte de la infraestructura real de memoria de los equipos. El cambio interesante es que todos se evalúan ahora por las mismas cuatro preguntas. ¿Quién puede leer una memoria? ¿Qué ocurre cuando está mal? ¿Qué ocurre cuando se borra? ¿Y qué pasa cuando dos memorias discrepan?

Tencent Cloud lanzó Team Memory, un governed shared-memory hub para equipos de agentes, el 13 de agosto de 2026, según el anuncio. Días antes, el CPO de Asana detalló Agentic Work Management, el sistema shared-memory detrás de AI Teammates, en una entrevista de VentureBeat publicada el 3 de agosto de 2026.

Las cuatro preguntas, comparadas

El framing perezoso para esta categoría es "Tencent versus Asana", open source chino frente a SaaS estadounidense. Eso no capta la forma real. La división verdadera es entre sistemas que gobiernan memoria como documentos con permissions y sistemas que gobiernan memoria como facts con lifecycles, y ningún grupo tiene todavía las dos mitades.

Lee las filas de correction y conflict y el patrón es incómodo: las dos cells que más importan son precisamente las que nadie ha rellenado.

La documentación propia de Team Memory distingue "who can use it, which version is valid, and which Agent should receive it", según documentación de Tencent reportada por VentureBeat. Graphiti de Zep invalida stale facts en vez de borrarlos, según el repositorio. Ni Tencent ni Asana documentan públicamente un proceso de correction o conflict resolution para shared memories ya consumidas por otros agentes.

Qué hace bien cada sistema

La contribución de Tencent es el access model, y merece crédito por ser explícito donde todos los demás son vagos. Cada memory asset lleva owner, version y visibility tier, private, team, restricted, agent; nuevos assets son private by default; y los agents reciben un "Agent Loadout" ajustado a su role en lugar de acceso total al hub. Un Scout agent de research recibe market-analysis assets; un Builder agent recibe el code graph. Es memoria tratada como infraestructura organizacional con lock policy y, como señaló la cobertura de VentureBeat, la propia documentación marca la diferencia con plain RAG: retrieval responde qué se puede encontrar; Team Memory también responde quién puede usarlo.

La contribución de Asana es la leak boundary, y su ejemplo debería estar en todo governance deck. Si el AI Teammate de un ejecutivo construye memoria sobre un proyecto confidential de M&A, un colega que más tarde hable con el mismo Teammate no debe heredar ese contexto. La respuesta de Bose, según la entrevista de VentureBeat, es que AWM se apoya en el Work Graph de Asana de 18 años, así que memory access hereda los mismos permissions del trabajo subyacente: si no puedes ver el proyecto, tampoco te pertenece la memoria del agente sobre ese proyecto. Es un problema realmente difícil resuelto negándose a construir otro permission system, y funciona solo porque Asana ya sabe quién puede ver qué. Asana habla de team-wide memory y enterprise controls desde el anuncio de AI Teammates en septiembre pasado, pero la boundary M&A es el primer mecanismo concreto.

La contribución de Graphiti es lifecycle. La mayoría de sistemas trata un fact incorrecto como problema de deletion. Graphiti lo trata como problema temporal: cuando un fact deja de ser verdadero, el edge se invalida y timestamped, no se borra, de modo que el agente puede responder tanto "qué es cierto ahora" como "qué era cierto en marzo". Para cualquier caso con audit, esa es la primitive correcta, y es notable que venga del mundo single-agent, no de ninguno de los nuevos team systems.

Tencent ofrece los access tiers más explícitos con sharing private-by-default; Asana scopea agent memory a existing Work Graph permissions para que confidential-project memory no se filtre a colegas sin clearance, según Asana CPO Arnab Bose en VentureBeat; Graphiti de Zep invalida stale facts con timestamps en lugar de borrarlos, según su repositorio.

El medio sin resolver: correction, conflict, propagation

Ahora la parte que las dos narrativas de launch omiten. Un fact incorrecto en memoria single-agent cuesta a un user una correction repetida. Un fact incorrecto en un shared store se propaga a todo agent que lo leyó antes de que alguien lo notara, y ninguno de los sistemas que shippea documenta un proceso para ello. La coverage del launch de VentureBeat recogió practitioners señalando el gap a las pocas horas: correction y expiry para hechos consumidos, la decisión de qué no debería escribirse nunca, y el caso donde agentes de dos teammates escribieron hechos contradictorios sobre el mismo module y el shared store debe elegir ganador. Single-agent memory drifts lentamente. Shared memory drifts rápido, porque un stale write llega a gente que nunca vio la session que lo produjo.

Esto no es implementation nitpick que arregla un point release. Un paper de marzo de 2026, "Governed Memory: A Production Architecture for Multi-Agent Workflows", identifica governance fragmentation y silent quality degradation sin feedback loops como riesgos estructurales de shared multi-agent memory, una forma académica educada de decir que el failure mode está en la arquitectura, no en el vendor. El framing de security lo complica: la guidance agentic de OWASP nombra memory poisoning como attack class distinta, y un shared store es shared blast radius. Permission inheritance de Asana y los tiers private-by-default de Tencent limitan quién puede leer una memoria poisoned o stale. Ninguno aborda qué pasa después de que una mala se haya leído.

Mi lectura: correction y conflict resolution terminarán funcionando como en cualquier otro shared information system, socialmente. Owner nombrado por asset, hábito de review, norma de expiry. Las tools que ganen esta categoría serán las que hagan fácil ese proceso social, no las que prometan automatizarlo fuera de existencia. Ya vi esta película con wikis, CRMs y feature flags. Las governance features son el producto, la misma conclusión que saco en el artículo de agent governance y la misma razón por la que "just add memory" no es plan en agentic architecture.

Practitioners respondiendo al launch de Team Memory señalaron correction, expiry y conflict resolution como gaps no documentados, según VentureBeat. El paper "Governed Memory" de marzo de 2026 identifica los mismos riesgos como estructurales en shared multi-agent memory, y la guidance de OWASP sobre agentic AI threats clasifica memory poisoning como attack class distinta.

Qué hacer ahora

Si evalúas shared agent memory este trimestre, cuatro pasos, en orden.

1. Hoy: escribe tus cuatro respuestas antes de cualquier demo: read scope, correction process, deletion semantics, conflict rule. Cualquier vendor que no pueda igualarlas feature por feature te dice dónde termina su roadmap.

2. Esta semana: ejecuta la prueba M&A. Crea una memoria bajo un proyecto confidential y luego pregunta al mismo agente como user sin acceso al proyecto. Asana se diseñó explícitamente para esto; los demás deberían tener que demostrarlo.

3. Este mes: poison algo deliberadamente, en sandbox. Escribe un fact incorrecto plausible en el shared store, deja que dos agentes lo consuman y luego intenta retirarlo. Lo que aprendas en una tarde sobre propagation y cleanup vale más que cualquier architecture diagram.

4. Continuamente: asigna owners. Un memory asset sin human nombrado responsable de su corrección es technical debt con vector index.

Si tus necesidades siguen siendo single-agent, el cálculo es diferente y más ligero; el artículo de self-hosted agents cubre ese extremo del trade-off.

FAQ

¿Qué es shared agent memory, en una frase?

Un store persistente de facts, procedures y context que múltiples agents, y sus humanos, leen y escriben, para que el equipo deje de rebriefar cada agente desde cero y empiece a heredar los errores de los demás.

¿Es más seguro Team Memory de Tencent o AI Teammates de Asana?

Responden preguntas distintas. Tencent ofrece el access model más granular y explícito, cuatro tiers, per-agent loadouts, private by default, y puedes self-host, así que data location es tu decisión. El modelo de Asana es más grueso pero battle-tested, porque hereda workspace permissions que ya gobiernan trabajo confidential. "Secure" aquí significa sobre todo "scoped correctamente para tu org chart", y solo tú sabes eso.

¿Qué ocurre cuando una shared memory está mal?

Hoy, casi nada automático. Tencent trackea versions y status pero no documenta correction o expiry para hechos consumidos. Asana corrige behaviour mediante human feedback loops sin documentar memory correction. Graphiti invalida stale facts con timestamps, la mejor primitive disponible, pero gobierna el graph de un solo agente. Presupuesta un proceso manual de review elijas lo que elijas.

¿Pueden reconciliarse automáticamente memorias contradictorias de dos agentes?

No en ningún shipping system que pueda documentar. El behaviour actual es que retrieval ranking elige una, lo que significa que el conflict se resuelve invisiblemente, por query, mediante similarity score. Si tu use case tiene facts que importan, regulatory, financial, safety, trata "qué memoria gana" como policy question que respondes tú, no como feature que esperas.

En resumen

Shared memory es la dirección correcta y un producto inacabado. Tencent y Asana han demostrado por separado que la mitad de access control se puede construir, uno abierto y portable, otro cerrado y permission-native, y eso por sí solo hace agosto un milestone real. Pero la mitad de correction, expiry y conflict no la documenta nadie y por defecto es tuya. Compra los access controls, planifica las corrections tú mismo y trata toda shared memory como un fact sobre el que todo el equipo ya ha actuado, porque cuando lo notes probablemente ya lo habrá hecho.

Si estás resolviendo dónde encaja shared memory en tu agent 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-29)

• VentureBeat, "Tencent's Team Memory shares AI agent memory across a team, with no governance yet for when it's wrong": https://venturebeat.com/data/tencents-team-memory-shares-ai-agent-memory-across-a-team-with-no-governance-yet-for-when-its-wrong (publicado 2026-08-07, consultado 2026-08-29)

• VentureBeat, "Asana's AI agents share memory across your company, but not your secrets": https://venturebeat.com/orchestration/asanas-ai-agents-share-memory-across-your-company-but-not-your-secrets (publicado 2026-08-03, consultado 2026-08-29)

• Asana, Inc., "Asana Announces New AI Teammates": https://investors.asana.com/news-releases/news-release-details/asana-announces-new-ai-teammates-collaborative-agents-deliver/ (publicado 2025-09-25, consultado 2026-08-29)

• TencentCloud, TencentDB-Agent-Memory repository: https://github.com/TencentCloud/TencentDB-Agent-Memory (consultado 2026-08-29)

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

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

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