MemoryLake
Volver a todos los artículos
News7 de agosto de 2026·12 min de lectura

Por qué las habilidades de los agentes no son memoria, y qué hacer al respecto (2026)

Esta semana, la industria se puso de acuerdo sobre cómo empaquetar lo que un agente puede hacer. Seis empresas firmaron un formato único para distribuir habilidades y herramientas entre clientes. Nadie se puso de acuerdo sobre lo que un agente sabe sobre ti, y la especificación lo dice explícitamente.

Aquí está la respuesta directa: una habilidad es un procedimiento (cómo crear una tabla dinámica, cómo revisar una migración, cómo reportar un error correctamente). Es general, se escribe una sola vez y, a partir de agosto de 2026, es portable entre proveedores gracias a un estándar. La memoria es lo contrario: las convenciones de tu repositorio, por qué la lógica de reintento parece incorrecta pero no lo es, qué ha rechazado ya este cliente. Es específica para ti, se acumula y ningún formato la transfiere a ninguna parte. Confundir ambas cosas es la razón por la que los equipos siguen instalando mejores habilidades en agentes que continúan iniciando cada sesión como perfectos desconocidos.

Este artículo analiza lo que realmente se lanzó, la diferencia en el mecanismo en lugar del vocabulario, y cómo estructurar ambas capas para que la parte portable siga siendo portable y la parte específica deje de evaporarse.

Lo que se lanzó esta semana

Agent Plugins 1.0.0 llegó el 6 de agosto de 2026, anunciado en el Google Developers Blog. Es un formato de paquete que agrupa Agent Skills y servidores MCP en una estructura de directorios portable con ubicaciones fijas para cada uno. La lista de patrocinadores es la parte interesante: Amazon, Cursor, Microsoft, OpenAI y Vercel, con Google uniéndose como Core Maintainer. El soporte ya abarca la Agents CLI (que incluye Antigravity, Gemini CLI, Claude Code y Cursor), además del Data Agent Kit, con una lista de clientes compatibles mantenida en agent-plugins.org.

El problema que resuelve se expone claramente en el anuncio: "Los autores de plugins no deberían tener que elegir entre llegar a todos los clientes y aprovechar lo que hace bueno a cada cliente". El objetivo es que los componentes de un plugin estén "disponibles de forma portable en cualquier cliente compatible".

Luego viene la frase clave para cualquiera que piense en la memoria. La especificación traza su propio límite: Agent Plugins v1 "es un formato de paquete y nada más. No define ningún mecanismo de instalación, protocolo de distribución, modelo de permisos, requisitos de sandboxing, verificación de confianza o procedencia, ni experiencia de usuario".

Esto no es una crítica; un alcance acotado es la razón por la que las especificaciones se publican. Pero lee la lista de lo que queda fuera de alcance y nota lo que ni siquiera aparece en ella. La memoria y el estado persistente no están excluidos; nunca formaron parte de la conversación. El formato estandariza la capa de capacidad, y la capa de capacidad es algo diferente de tu contexto acumulado.

La investigación apunta en la misma dirección. Un preprint titulado SkillOpt: Executive Strategy for Self-Evolving Agent Skills (arXiv 2605.23904, presentado el 22 de mayo de 2026 y recogido en la cobertura del sector el 5 de agosto) trata un documento de habilidad como un estado externo entrenable para un agente congelado: un modelo optimizador convierte ejecuciones puntuadas en ediciones acotadas de añadir/eliminar/reemplazar en un único archivo de habilidad, y una edición se acepta solo cuando mejora estrictamente una puntuación de validación reservada. En seis benchmarks, siete modelos objetivo y tres entornos de ejecución (chat directo, Codex y Claude Code), los autores informan que su método es el mejor o empata en las 52 celdas evaluadas (modelo, benchmark, entorno), elevando la precisión promedio sin habilidades de GPT-5.5 en +23.5 puntos en chat directo, +24.8 dentro del bucle de Codex y +19.1 dentro de Claude Code.

La conclusión que vale la pena recordar es el resultado de la transferencia: los artefactos de habilidad optimizados conservan su valor cuando se mueven entre escalas de modelos, entre entornos de ejecución de Codex y Claude Code, y a un benchmark matemático cercano sin optimización adicional. Un procedimiento entrenado en un entorno sigue funcionando en otro.

Dos advertencias antes de que esto se convierta en una tesis. Es un preprint, no un trabajo revisado por pares. Y el artículo es de mayo de 2026; la fecha de agosto es cuando circuló la cobertura, no cuando apareció la investigación. Lo genuinamente nuevo esta semana es el estándar de empaquetado; SkillOpt es la evidencia de que lo que se está estandarizando es, de hecho, transferible.

Por qué las habilidades no son memoria

Una es general, la otra es tuya

Una habilidad codifica un procedimiento repetible. Por eso precisamente se transfiere: nada en "cómo auditar una hoja de cálculo en busca de referencias rotas" depende de qué hoja de cálculo, qué empresa o qué trimestre sea. Si eliminas los detalles específicos, obtienes algo publicable, que es lo que un formato de paquete asume que tienes.

La memoria son los detalles específicos. Tu plan de cuentas, la convención de nomenclatura que aplicas, el proveedor cuya API devuelve 200 en caso de fallo, la decisión que tomaste en marzo y la razón detrás de ella. No existe ninguna versión de eso que sea útil para otra persona, ni ninguna versión que pueda escribirse una vez e instalarse. Tiene que capturarse a partir de tu trabajo, y crece.

Una se escribe, la otra se acumula

Escribes una habilidad deliberadamente y permanece estática. Puedes revisarla, versionarla, lanzar una versión 1.1. Es un artefacto con un autor.

La memoria no tiene un momento de creación. Se produce como un efecto secundario del trabajo: una corrección aquí, una decisión allá, una restricción descubierta a las 6 p. m. Lo que significa que el modo de fallo es completamente diferente: las habilidades fallan por ser incorrectas, la memoria falla por no escribirse nunca. Un formato de paquete no puede solucionar el segundo problema porque aún no hay nada que empaquetar.

Una habilidad le dice al agente cómo; solo la memoria le habla de este lugar

Aquí es donde la confusión sale cara. Instala una habilidad de revisión de código bien optimizada en tu agente y revisará bien el código, de forma genérica. Marcará la comprobación de nulos que falta y pasará por alto que tu equipo permite deliberadamente ese patrón en la capa del adaptador debido a una peculiaridad ascendente. El procedimiento fue excelente. El contexto estaba ausente.

Los equipos interpretan ese resultado como "la habilidad necesita ajustes" e iteran sobre la habilidad. La habilidad estaba bien. Lo que falta es la capa que habría dicho aquí lo hacemos de esta manera, y esta es la razón, que es también por lo que la recuperación sobre tus documentos no es lo mismo que la memoria: encontrar un documento que mencione la capa del adaptador no es lo mismo que el agente conozca la decisión vigente.

La portabilidad hace que la brecha sea más visible, no más pequeña

Esta es la consecuencia ligeramente contraintuitiva. Cuanto más fácil sea mover habilidades entre Claude Code, Cursor, Codex y los demás, más a menudo te mudarás realmente, y cada mudanza restablece el lado del conocimiento a cero mientras que el lado de la capacidad llega intacto. El estándar elimina la fricción de la mitad de la pila. La mitad que no toca es la mitad que tardaste seis meses en acumular.

Lo que la gente intenta

Poner el contexto del proyecto dentro de la habilidad. El paso obvio, y funciona hasta que deja de hacerlo. Ahora has hecho que la habilidad sea impublicable, no versionable entre proyectos y obsoleta en el momento en que cambia una decisión. Tampoco puedes compartirla, que era el propósito de un formato de paquete.

Meter todo en el archivo de instrucciones. AGENTS.md, CLAUDE.md, .cursor/rules: estos son realmente el hogar adecuado para las reglas vigentes, y la propia documentación de Cursor recomienda mantener las reglas por debajo de 500 líneas por una buena razón. Los archivos de instrucciones se cargan en cada tarea, por lo que son un impuesto por solicitud. Son para reglas, no para el registro acumulado.

Un plugin gigante por cliente. Algunos equipos resuelven la portabilidad manteniendo un paquete por herramienta con el contexto integrado. Eso son tres copias del mismo conocimiento distanciándose entre sí, lo cual es peor que una copia que nadie puede mover.

Volver a explicar al inicio de cada sesión. Universal, y se degrada: la versión que escribes el jueves es más corta que la del lunes, porque estás resumiendo de memoria y las exclusiones son la parte aburrida.

Dejar que la memoria integrada de cada herramienta se encargue. Razonable, y vale la pena habilitarlo donde exista. El inconveniente es que estos almacenes son por herramienta, generalmente por máquina, y no exportables, por lo que reproducen exactamente el problema que la especificación del plugin fue escrita para resolver, una capa más abajo, donde aún no existe ningún estándar.

La solución: distribuye la habilidad, conserva el contexto

Divide las capas a propósito y dale a cada una el almacenamiento que merece.

Las habilidades van en los plugins. Escríbelas de forma limpia y general, mantenlas libres de cualquier cosa que identifique tu base de código o tu cliente, versiónalas y deja que el nuevo formato las lleve a cualquier entorno que estés usando este trimestre. Para eso sirve y ahora funciona.

El contexto va en una capa de memoria que vive fuera de cualquier herramienta individual y que todas las herramientas leen. No un archivo de instrucciones más grande, sino un almacén que contiene los documentos, decisiones y restricciones que produjo tu trabajo, recuperados cuando son relevantes en lugar de cargarse en cada solicitud. MemoryLake está diseñado para ese lado de la división: un almacén del que tus agentes leen a través de MCP o la API, de modo que cambiar de entorno cambia una entrada de configuración en lugar de reiniciar tu conocimiento institucional.

Un límite honesto. Una capa de memoria no hace que un agente siga lo que lee; la atención y el seguimiento de instrucciones son comportamientos del modelo, y ninguna capa de almacenamiento garantiza el cumplimiento. Lo que cambia es que el contexto relevante está disponible y es breve en el momento en que importa, en lugar de estar ausente o enterrado en un archivo que crece hasta que el modelo deja de prestar atención a la mitad del mismo.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Guárdala en tu entorno o en un gestor de secretos; ten en cuenta que Agent Plugins v1 explícitamente no define ningún modelo de permisos, por lo que nada en el estándar de empaquetado va a proteger una credencial que hayas integrado en un paquete.

Crear una clave API de MemoryLake
Crear una clave API de MemoryLake

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que contienen los detalles específicos: las decisiones de arquitectura, el documento de convenciones con sus razones, el informe del cliente, el análisis post-mortem. Sube fuentes en lugar de resúmenes siempre que puedas. Este es exactamente el material que no puede ir en un plugin compartible, por lo que necesita su propio hogar.

Subir tus primeras memorias a MemoryLake
Subir tus primeras memorias a MemoryLake

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. Dado que los plugins ya agrupan servidores MCP con una ubicación de configuración fija, la capa de memoria se conecta en el mismo cableado que usan tus habilidades: la capa de capacidad y la capa de conocimiento llegan por la misma puerta, desde almacenes diferentes.

Conectar tu IA y agentes a través de MCP
Conectar tu IA y agentes a través de MCP

Qué cambia esto en la práctica

La habilidad que instalas comienza a comportarse como si la hubiera escrito tu equipo. El mismo procedimiento genérico, ahora aplicado a una base de código cuyas convenciones y excepciones son recuperables, por lo que la habilidad de revisión de código deja de marcar el patrón de la capa del adaptador que tu equipo permite deliberadamente.

Los cambios de herramienta se vuelven económicos en ambas direcciones. Las habilidades se mueven porque el formato las mueve; el contexto se mueve porque nunca estuvo dentro de la herramienta. Esta es la primera vez que ambas mitades de la configuración de un agente son portables a la vez, y es la razón práctica por la que ejecutar Codex y Claude Code en paralelo deja de requerir dos copias mantenidas de las mismas convenciones.

Tus archivos de instrucciones se vuelven más pequeños. Una vez que el registro acumulado tiene un lugar donde vivir, AGENTS.md vuelve a ser una lista corta de reglas vigentes en lugar de un archivo en constante crecimiento, lo cual es mejor para los costos y mejor para el cumplimiento, ya que un archivo de reglas de 500 líneas es algo a lo que el modelo presta atención de manera desigual.

Y las habilidades se vuelven compartibles. La mayoría de los equipos no pueden publicar sus habilidades internas hoy en día porque el contexto está soldado a ellas. Separa las capas y la habilidad será publicable por diseño.

Buenas prácticas para separar las habilidades de la memoria

Aplica la prueba de "¿podría usar esto un competidor?"

Escribe una habilidad y luego pregunta si una empresa de tu sector podría instalarla sin cambios y beneficiarse de ella. Si la respuesta es sí, es una habilidad: mantenla general y empaquétala. Si la respuesta es no, has escrito contexto disfrazado de habilidad, y pertenece a la capa de memoria, donde se puede actualizar sin lanzar una nueva versión.

Mantén los archivos de instrucciones para reglas, no para registros

Cualquier cosa que se cargue en cada solicitud debe ser breve, imperativa y estable. Las decisiones, el historial y el material de referencia pertenecen a un almacén que se consulta bajo demanda. Mezclarlos es la forma de obtener un archivo que resulta costoso en cada tarea y que, aun así, no contiene lo que necesitabas.

Versiona las habilidades, fecha las memorias

Las habilidades obtienen versiones semánticas porque son artefactos creados. Las entradas de memoria obtienen fechas de vigencia porque son registros de decisiones, y una decisión reemplazada debe seguir siendo legible, o no podrás interpretar el trabajo del trimestre pasado. Diferentes disciplinas de almacenamiento para diferentes modos de fallo.

No esperes a un estándar de memoria

MCP estandarizó cómo los agentes acceden a las herramientas; Agent Plugins estandarizó cómo se empaquetan las capacidades. No existe un acuerdo equivalente para la memoria de usuario portable, y la propia declaración de alcance de la especificación del plugin deja claro que no lo está intentando. Elegir un almacén que cualquier cliente pueda leer a través de MCP o una API es la respuesta disponible, y es la que sobrevivirá a cualquier estándar que llegue eventualmente.

Conclusión

El 6 de agosto fue un verdadero hito: que seis proveedores se pusieran de acuerdo en un formato de paquete único para habilidades y servidores MCP es la forma en que los ecosistemas dejan de depender de cada herramienta. Y la propia declaración de límites de la especificación es la frase más útil del anuncio: es un formato de paquete y nada más, lo que significa que la capa que contiene tus detalles específicos nunca estuvo dentro del alcance.

Así que trátalos como dos problemas. Escribe habilidades limpias y generales, y deja que el estándar las transporte. Mantén el registro acumulado (decisiones, convenciones, razones) en un almacén que tus agentes lean y que tú puedas editar, para que sobreviva al entorno que casualmente estés usando. La capa de capacidad acaba de volverse portable. Hacer que la capa de conocimiento sea portable sigue siendo tu decisión, y es la mitad que tardaste seis meses en construir.

Preguntas frecuentes

¿Cuál es la diferencia real entre una habilidad y una memoria?

La autoría y la especificidad. Una habilidad es un procedimiento que escribes deliberadamente, lo suficientemente general como para que otra persona pueda usarlo, y permanece estático entre ediciones. Una memoria es un registro producido como subproducto de tu trabajo: específico para tu proyecto, inútil para cualquier otra persona y en continuo crecimiento. Las habilidades fallan por ser incorrectas; las memorias fallan por no ser capturadas nunca.

¿Maneja Agent Plugins 1.0.0 la memoria o el estado?

No. La especificación establece que la v1 es un formato de paquete y nada más, definiendo explícitamente que no hay mecanismo de instalación, protocolo de distribución, modelo de permisos, requisitos de sandboxing, verificación de confianza o procedencia, ni experiencia de usuario. La memoria y el estado persistente no están dentro del alcance. Ese es un límite deliberado y razonable; simplemente significa que el problema del estado sigue siendo tuyo por resolver.

Si las habilidades se transfieren entre entornos, ¿no puedo poner el contexto de mi proyecto en una de ellas?

Puedes hacerlo, y dejará de ser una habilidad. Se vuelve imposible de compartir, tiene que volver a lanzarse cada vez que cambia una decisión y se duplica en proyectos que necesitan un contexto que se superpone pero es diferente. Los resultados de SkillOpt se refieren a que los procedimientos conservan su valor entre entornos; nada en ellos sugiere que integrar tus detalles específicos en el artefacto sea una buena idea.

¿Es MCP el estándar de memoria, entonces?

MCP es la forma en que un agente llega a un servidor, incluido un servidor de memoria, lo que lo convierte en el transporte, no en el almacén ni en el formato de lo que se recuerda. Esa distinción importa más desde la revisión de 2026 del protocolo, que movió el estado de la sesión fuera de la capa del protocolo y hacia las aplicaciones. Una infraestructura útil; no un acuerdo sobre lo que tu agente sabe sobre ti.

¿Sigo necesitando AGENTS.md o .cursor/rules si tengo una capa de memoria?

Sí, y hacen un trabajo diferente. Los archivos de instrucciones contienen reglas vigentes que deben aplicarse a cada tarea, viven en el control de versiones y tu equipo las hereda a través de la revisión de código. La documentación de Cursor sugiere mantener las reglas por debajo de 500 líneas, lo cual es una buena pista sobre para qué sirven. La capa de memoria contiene lo que es demasiado largo, demasiado específico o demasiado antiguo para cargarse incondicionalmente.

¿Hará una capa de memoria que el agente realmente siga mis convenciones?

No por sí sola, y vale la pena ser claros al respecto. El hecho de que un modelo actúe según lo que lee es un comportamiento del modelo; almacenar algo de manera más confiable no garantiza el cumplimiento. Lo que cambia una capa de memoria es la disponibilidad: la restricción relevante es recuperable en el momento en que importa y lo suficientemente corta como para competir por la atención, en lugar de faltar por completo o estar enterrada en medio de un archivo largo.