Grok Bot convirtió al Bot en el objeto principal, no al chat: una memoria por rol, no una por cuenta (2026)

Cinco primitivas, y el Bot ganó

El ensayo parte de la fatiga del vocabulario, lo cual es un diagnóstico acertado: "Chats, sesiones, modelos, ventanas de contexto, memorias, prompts del sistema, proyectos, habilidades, conectores, agentes, herramientas, entornos de prueba, permisos y automatizaciones describen partes reales de estos sistemas". Su conclusión: "exponer cada uno como un concepto de producto independiente pide a los usuarios que entiendan más de lo que necesitan".

Se quedaron con cinco. Citado textualmente:

• "Los Bots son agentes persistentes con su propia identidad, memoria, entorno de ejecución y herramientas".
• "Los Chats son la interfaz conversacional para trabajar con un Bot".
• "Los Prompts le dan contexto o instrucciones a un Bot. Se pueden usar una vez, guardar como Skills o activarse automáticamente como Routines".
• "Las Tools permiten a los Bots acceder a información y tomar medidas a través de software, APIs, conectores, la terminal o el uso de la computadora".
• "Los Artifacts son los documentos, diseños, código, datos y otros resultados duraderos que los Bots crean o modifican".

Nota dónde se ubica la memoria en esa lista. Es una propiedad de un Bot, junto con la identidad y el entorno de ejecución. No es una propiedad tuya.

El historial de chat se convirtió en una lista de Bots

La consecuencia en la interfaz se expresa claramente: "Así que los objetos principales en Grok Bot son los Bots, no las conversaciones. Un Bot tiene un nombre. Tiene un avatar y un título. Recuerda sus conversaciones contigo. Tiene su propia computadora y herramientas. Cuando regresas mañana, regresas al mismo Bot".

La barra lateral muestra una lista de Bots en lugar de hilos de conversación, y el avatar lleva la identidad a la vez que funciona como indicador de estado: "Un Bot puede estar inactivo, pensando, trabajando, esperando, bloqueado o terminado".

Cada Bot también tiene su propia máquina: "Cada Bot tiene su propia computadora, que puede usar para navegar por la web, trabajar con archivos y ejecutar software". El acceso se presenta en tres niveles, terminando en "Takeover: cuando el Bot necesita ayuda, el usuario puede abrir la computadora a pantalla completa, tomar el control y luego devolvérselo".

La división que importa: las capacidades se comparten, el contexto no

Aquí está el párrafo que vale la pena leer dos veces, y la razón por la que existe este artículo:

"Por lo tanto, las capacidades y el contexto siguen límites diferentes en Grok Bot. Las Tools y las Skills residen a nivel de cuenta porque muchos Bots pueden necesitar navegar por la web, trabajar con documentos o enviar correos electrónicos. La memoria y las Routines pertenecen al Bot porque reflejan lo que ese rol en particular sabe y hace a lo largo del tiempo. Dicho de otro modo, las capacidades se pueden compartir ampliamente mientras que el contexto permanece con el rol que lo necesita".

Dos alcances diferentes, a propósito. Y dan la razón:

"Un Bot legal puede necesitar el historial de una disputa en curso, mientras que un Bot de finanzas puede necesitar años de registros financieros. Combinar esos historiales en una sola gran memoria haría más difícil darle a cada Bot la información relevante para su trabajo".

Ese es un argumento explícito en contra de unificar la memoria, proveniente de un proveedor que acaba de reconstruir su producto en torno a la persistencia. Merece ser tomado en serio en lugar de ser ignorado.

Trabajo que comienza sin un prompt

Un detalle más, porque la persistencia sin iniciativa es solo la mitad de la idea: "La mayoría de las sesiones de agentes comienzan cuando un usuario envía un prompt. Eso deja incluso a un Bot persistente esperando a que alguien lo active". Las Routines son la respuesta —"una responsabilidad permanente que se ejecuta según un cronograma o en respuesta a un evento"— y fueron promovidas a mitad del diseño: "Inicialmente tratamos las Routines como una configuración secundaria. A medida que se volvieron más importantes para el trabajo autónomo, las movimos a la interfaz principal del Bot".

Las Routines están limitadas al Bot, al igual que la memoria. Las Skills y las Tools no.

La página para empresas, el mismo día

Junto con el ensayo, SpaceXAI puso Grok Bot a disposición de las empresas y describió a un Bot en términos de un trabajador: "Un Bot es un trabajador que creas dentro de Grok Bot para un trabajo específico. Cada Bot se ejecuta en su propia computadora en la nube y puede usar cada aplicación y sitio web de la misma manera que tú". Sobre el aislamiento: "El trabajo de cada usuario en Grok Bot se ejecuta en su propio entorno seguro y aislado, separado de todos los demás usuarios. Un Bot no tiene acceso por defecto y solo llega a las cuentas en las que inicias sesión".

La nota de lanzamiento es que los clientes de Grok y Cursor Enterprise obtienen uso gratuito "durante las próximas dos semanas" y pueden invitar a toda una organización, "incluidas personas que no tengan una licencia existente".

Sí traslada la unidad de persistencia fuera de la sesión. Eso es real y es la dirección correcta. Un elemento con nombre propio, con su propio estado, herramientas y responsabilidades permanentes es un mejor contenedor para el conocimiento acumulado que una conversación por la que tienes que hacer scroll hacia atrás.

No hace que la memoria sea portable. La memoria de un Bot es una propiedad de ese Bot dentro de ese producto. Nada en el ensayo sugiere que se transfiera, y la delimitación por rol hace que la transferencia sea más difícil, no más fácil, porque el conocimiento ahora está particionado tanto por rol como por proveedor.

No se fusiona, y eso es intencional. Si ejecutas un Bot legal y un Bot de finanzas, ninguno sabe lo que el otro ha aprendido. SpaceXAI considera esto una característica, y para la calidad de la recuperación dentro de un solo producto, tienen un buen punto.

Sí reconocen el problema del contexto compartido. El ensayo no pretende que los roles nunca se superpongan: "Los chats grupales proporcionan un contexto compartido para un proyecto o equipo, al tiempo que permiten que cada Bot conserve su memoria especializada". Así que también existe una capa compartida en su modelo: es una conversación, delimitada a un proyecto, en lugar de un almacén de datos.

No elimina la cuestión de la coordinación, la reubica. Su respuesta surgió del uso: "Algunos crearon un Bot de Jefe de Personal responsable de coordinar a varios especialistas". Un Bot que enruta el trabajo entre Bots es un patrón razonable, y también es un Bot con su propia memoria separada de ese enrutamiento.

"La memoria por Bot significa que la memoria está resuelta". Resuelta dentro de un producto, para un rol. Lo que antes era difícil —conocer tus convenciones al cambiar de herramienta— sigue intacto. Es la misma distinción que se analiza en qué es realmente la memoria persistente.

"Entonces, una sola gran memoria es un error". Esta es la mala interpretación que vale la pena corregir con cuidado, porque el argumento de SpaceXAI es más acotado de lo que parece. Están argumentando en contra de fusionar los historiales de roles en un solo bloque: volcar años de registros financieros y una disputa legal activa en un único almacén y esperar que la recuperación lo solucione. Ese es un problema real de recuperación y tienen razón al respecto.

Lo que no están argumentando en contra es de una fuente compartida de datos duraderos: tus decisiones de arquitectura, tu vocabulario de dominio, tus convenciones. Esos no son el historial de un solo rol; son los mismos para cada rol, y que cada Bot los vuelva a aprender por separado es un desperdicio, no higiene. Delimitar historiales y compartir datos son acciones diferentes, y el ensayo solo defiende la primera.

"Así que debería darle a cada Bot las mismas instrucciones". Copiar el mismo contexto en cinco Bots es el parche que parece una solución durante aproximadamente un mes. Luego, una copia recibe una corrección que las demás no, y terminas con cinco especialistas que discrepan con total seguridad sobre tus convenciones: el modo de fallo descrito en memoria multiagente.

"Las Routines lo hacen autónomo, así que puedo dejar de pensar en el contexto". Las Routines deciden cuándo actúa un Bot. No deciden qué sabe. Una Routine que se ejecuta cada mañana con un contexto desactualizado se ejecuta de forma incorrecta cada mañana.

"Takeover significa que puedo supervisarlo todo". Los tres niveles de acceso se diseñaron específicamente para evitar eso: "Cuanto más prominente hacíamos la computadora, más fomentaba el producto que los usuarios la supervisaran". Takeover es una vía de excepción, no un flujo de trabajo.

Paso 1: Clasifica tu contexto en historial y datos

Toma un Bot que uses habitualmente y lee lo que ha acumulado. Clasifica cada elemento en dos montones.

Historial. Lo que este rol hizo, decidió y se le dijo, en secuencia. El cronograma de la disputa. Los recibos recopilados. Los candidatos preseleccionados. Esto pertenece al Bot, y SpaceXAI tiene razón en que fusionarlo entre roles empeora la recuperación.

Datos. Lo que es cierto sobre tu organización independientemente de quién pregunte. Cómo se gestionan las versiones de tu API y por qué. Qué significan tus términos internos. Qué equipo es dueño de qué. Tus convenciones de redacción. Tus restricciones de cumplimiento.

El segundo montón es el que se duplica silenciosamente. Cada Bot que creas necesita parte de él, y la memoria por rol significa que cada Bot lo aprende de nuevo desde cero, o no lo hace y se equivoca.

Paso 2: Decide de dónde proviene el contexto compartido de cada Bot, antes de crear el quinto

Dos Bots son manejables a mano. Cinco es cuando las copias empiezan a desviarse.

Mira lo que SpaceXAI ya delimita a nivel de cuenta: las Tools y las Skills, porque "muchos Bots pueden necesitar navegar por la web, trabajar con documentos o enviar correos electrónicos". Ese es precisamente el razonamiento que se aplica a los datos. El límite de la capacidad se traza en "muchos Bots necesitan esto"; el mismo criterio aplicado al conocimiento te da la misma respuesta.

En la práctica: para cada Bot, escribe qué datos compartidos necesita y de dónde los obtiene actualmente. Si la respuesta es "lo que sea que escribí en su primera conversación", esa es la copia que se desviará.

Vale la pena usar los chats grupales de manera deliberada aquí. Estos "proporcionan un contexto compartido para un proyecto o equipo, al tiempo que permiten que cada Bot conserve su memoria especializada", lo cual es adecuado para la superposición específica de un proyecto y poco adecuado para las convenciones permanentes (un chat grupal es una conversación, y las convenciones deberían sobrevivir a ella).

Paso 3: Coloca los datos en una capa que ningún Bot posea

La solución estructural es la que el límite de las Tools a nivel de cuenta ya sugiere: las cosas que muchos Bots necesitan no deberían residir dentro de ninguno de ellos.

Una capa de memoria externa al producto hace exactamente eso con el conocimiento. Cada Bot conserva su propio historial —delimitado, especializado, tal como lo diseñó SpaceXAI— y lee los datos compartidos de un almacén que no es propiedad de ningún Bot. Crear un sexto especialista deja de significar una sexta explicación de tus convenciones, y una corrección se aplica una sola vez en lugar de cinco.

Además, sobrevive a lo que la memoria por Bot no puede: la siguiente herramienta que utilices. MemoryLake se configura en tres pasos.

Paso 1: Crea una clave de API

Inicia sesión y genera una clave de API desde tu panel de control. Te pertenece a ti en lugar de a un Bot, una cuenta o un producto, que es la propiedad que importa cuando tus roles están distribuidos en más de un proveedor.

Paso 2: Sube tus primeras memorias

Coloca aquí el segundo montón del Paso 1: decisiones de arquitectura y sus motivos, vocabulario de dominio, propiedad de servicios, preferencias permanentes y las restricciones que cada rol debe respetar.

Deja los historiales donde están. El registro de un Bot sobre su propio trabajo es exactamente lo que debe permanecer delimitado a ese Bot.

Paso 3: Conecta tu IA y agentes

Apunta tus agentes al almacén de datos. Un nuevo especialista comenzará a partir de los datos de tu organización en lugar de la nada, y los datos se mantendrán correctos en un solo lugar, que es el propósito de sincronizar la memoria entre tus herramientas en lugar de hacerlo por producto.

El primer cambio es que crear un especialista se vuelve económico. En este momento, el costo de un nuevo Bot incluye volver a enseñarle todo lo general, lo que desalienta silenciosamente los roles detallados para los que se creó el diseño.

El segundo es que las correcciones dejan de ser multidireccionales. Corrige una convención una vez y cada rol leerá la versión corregida, en lugar de la versión que se le dijo por casualidad.

El tercero es que la delimitación de roles se convierte en una opción de diseño real en lugar de una restricción que debes sortear. Cuando los datos compartidos provienen de una capa compartida, mantener acotado el historial de cada Bot no te cuesta nada, que es lo que SpaceXAI quería en primer lugar, y el mismo argumento detrás de guardar menos en la memoria del agente.

• Separa el historial de los datos antes de escalar. El historial pertenece al rol; los datos pertenecen a todos.
• Aplica el criterio de las Tools al conocimiento. Si muchos Bots lo necesitan, no debería residir dentro de ninguno de ellos.
• No copies el contexto compartido en cada Bot. Ese es el mecanismo de desviación y falla silenciosamente.
• Usa chats grupales para la superposición de proyectos, no para convenciones permanentes. Una conversación es el lugar equivocado para algo que debe sobrevivir a ella.
• Trata a un Bot coordinador como un enrutador, no como una memoria. Su propia memoria trata sobre el enrutamiento, no sobre tu dominio.
• Verifica lo que sabe una Routine antes de programarla. La autonomía amplifica cualquier contexto que tenga el Bot, incluido el contexto incorrecto.
• Mantén el Takeover como una excepción. El diseño desalienta deliberadamente la supervisión; usarlo constantemente significa que el Bot no está lo suficientemente informado.
• Vuelve a verificar a medida que cambie. Grok Bot es nuevo, la oferta para empresas tiene un límite de tiempo y las decisiones de diseño tan recientes tienden a cambiar.

Este es uno de los artículos sobre diseño de producto más reflexivos publicados por un proveedor de IA este año, y su afirmación central es algo con lo que estamos de acuerdo: la sesión nunca fue la unidad adecuada para nada que quisieras conservar.

Donde va más allá de lo que nosotros iríamos es al concluir que, por lo tanto, el contexto debe residir con el rol. Para los historiales, eso es correcto y está bien argumentado. Para los datos que cada rol necesita, convierte un problema compartido en un problema por cada Bot. Delimita los historiales de la manera en que SpaceXAI lo diseñó. Coloca los datos en algún lugar que ningún Bot posea.