Company Brain en acción: cómo Meteor gobierna colecciones, herramientas y trazabilidad

La pregunta útil ya no es si una empresa puede conversar con sus documentos. La pregunta es qué ocurre entre el mensaje y la respuesta: qué contexto entró, qué fuente se consultó, qué permiso se aplicó, qué herramienta se ejecutó y qué evidencia quedó disponible.

Ese recorrido es lo que hace operativo al Company Brain de Meteor. Las partes ya existen dentro de la plataforma y trabajan juntas. La implementación de cada empresa consiste en decidir su alcance, conectar las fuentes correctas y probar los límites antes de ampliar la autonomía.

Si necesitas la definición y la comparación con un segundo cerebro o RAG, empieza por la guía qué es un Company Brain. Este artículo responde otra intención: cómo funciona hoy dentro de Meteor.

El recorrido completo, desde una conversación

Una conversación de WhatsApp puede activar este recorrido:

1. Meteor reúne el historial reciente, los datos disponibles del contacto, los adjuntos procesados y los resultados anteriores de herramientas que ayudan a conservar continuidad.
2. El canal entrega al Met un catálogo de colecciones de negocio. Si existe una lista permitida, solo aparecen las colecciones incluidas en ella.
3. Cada colección permitida puede operar en lectura o en lectura y escritura. El permiso no es solo una instrucción para el modelo: las herramientas de mutación se rechazan cuando la colección está marcada como solo lectura.
4. Cuando la respuesta necesita un dato vivo, el Met puede usar una herramienta MCP de la tienda, el CRM, el ERP, la agenda u otro sistema conectado.
5. La ejecución puede conservar eventos, pasos y resultados que permiten inspeccionar qué ocurrió y continuar el proceso con contexto.

El resultado no es una respuesta generada sobre un bloque indiscriminado de información. Es una secuencia en la que el canal, la colección y la herramienta reducen la superficie disponible.

La matriz de controles que ya existe

Capa	Qué hace hoy	Qué no demuestra por sí sola
Contexto del contacto	Incorpora campos, historial reciente, adjuntos procesados y memoria de herramientas al turno	Que todos los datos sean correctos, vigentes o suficientes
Colecciones del canal	Permite usar todas las colecciones de dominio o una lista seleccionada	Que una configuración amplia sea apropiada para todos los procesos
Lectura o escritura	Rechaza herramientas de mutación sobre una colección marcada como solo lectura	Que toda herramienta externa sea de solo lectura
Colecciones internas	Oculta colecciones del sistema a los Mets de canal	Que un contacto externo sea un miembro autenticado
MCP	Expone herramientas nombradas para consultar o actuar en sistemas conectados	Que conectar un sistema copie toda su información a Meteor
Scopes de API	Separa permisos como lectura, escritura, ejecución de agentes y uso de integraciones	Que una clave deba recibir todos los scopes disponibles
Trace de ejecución	Puede exponer pasos y eventos para revisar una ejecución	Que exista una certificación de cumplimiento o una auditoría legal

Esta tabla importa porque evita una promesa vaga de “acceso por roles”. Meteor tiene varias fronteras concretas y no son intercambiables. Los roles de miembros gobiernan a personas autenticadas. La lista de colecciones gobierna al Met de un canal. Los scopes gobiernan una clave de API. Las credenciales y herramientas gobiernan el acceso a cada sistema externo.

El permiso de colección se aplica al ejecutar

Una limitación escrita únicamente en el prompt depende de que el modelo la respete. Meteor añade un control en la ejecución de las herramientas de colección.

Cuando un canal usa una lista permitida, una colección puede marcarse como lectura o lectura y escritura. Si está en lectura, el Met puede consultar su estructura y buscar registros, pero no puede crear, actualizar o eliminar items, vistas o bloques de contenido. El control rechaza esas operaciones aunque el modelo intente llamarlas.

También hay dos límites adicionales:

• una colección interna del sistema no queda disponible para un Met de canal;
• un canal restringido a una lista no puede crear una colección nueva para ampliar su propia superficie.

Hay que decir también el límite de esta capacidad: si una colección está incluida sin un permiso granular, el comportamiento histórico es escritura. Por eso una implementación gobernada debe configurar el permiso de forma explícita y probarlo con una operación que deba ser rechazada.

MCP lleva la pregunta a la fuente que posee el dato

Un manual y un ERP no cumplen la misma función. El manual explica una política; el ERP conserva inventario, cartera o estado operativo. Copiar periódicamente el segundo dentro de un repositorio puede dejar una respuesta vieja.

Las herramientas MCP permiten que el Met consulte el sistema conectado cuando el dato cambia. Cada ficha del catálogo de integraciones publica herramientas, requisitos y límites. Esa precisión es más útil que decir que Meteor “se conecta con todo”: permite revisar cuál operación existe antes de incorporarla al recorrido.

En la API pública, los scopes también separan capacidades. Leer colecciones, escribir items, ejecutar agentes y usar integraciones son permisos distintos. Esto permite emitir una clave para el trabajo que necesita realizar, aunque la selección final sigue siendo responsabilidad de quien administra el workspace.

El contexto vuelve a la operación

Un Company Brain deja de ser una búsqueda cuando el resultado permite continuar el trabajo. El Met puede usar el contexto de la conversación, consultar una colección o sistema y devolver una respuesta. Si el recorrido autoriza una actualización, el nuevo estado queda disponible para la siguiente interacción.

El caso de Mega Alfa Trans muestra una forma concreta: su equipo describe notificaciones, recepción de documentos de trabajadores e información de mantenimiento reunida desde WhatsApp. El testimonio no prueba todos los controles descritos en este artículo, pero sí documenta que el canal ya participa en un proceso operativo y no únicamente en una respuesta informativa.

Qué revisar antes de ampliar la autonomía

Una implementación seria no empieza conectando todo. Empieza con pruebas que puedan fallar de forma visible:

1. Colección fuera de lista: el Met no debe verla ni consultarla.
2. Colección en lectura: una búsqueda debe funcionar y una edición debe ser rechazada.
3. Dato vivo: la respuesta debe venir del sistema propietario y no de una copia antigua.
4. Acción sensible: el flujo debe detenerse para aprobación cuando el proceso lo exige.
5. Evidencia: el equipo debe poder revisar los pasos disponibles y entender dónde falló.

Después se puede ampliar el alcance por proceso, no por entusiasmo. Esa es la diferencia entre un demo que responde preguntas y un Company Brain que participa de forma controlada en la operación.