Cómo Meta construyó un segundo cerebro IA para 60.000 empleados

El sistema que 63.000 empleados de Meta usan cada día

En febrero de 2026, una herramienta interna que empezó como el parche de un data scientist alcanzó 63.000 instalaciones dentro de Meta. Tres meses después, 10.000 personas la usan a diario. No es un asistente más. Es un segundo cerebro: un agente IA con acceso autenticado a las herramientas internas de la empresa y memoria estructurada del trabajo de cada empleado.

El problema que resolvió es universal. Meta lo describe sin rodeos: “las mismas explicaciones, los mismos enlaces, los mismos diez minutos de poner en contexto antes de que empiece el trabajo real.” Cada vez que abrías una conversación nueva con un asistente IA, repetías lo mismo. La información estaba fragmentada entre Slack, Quip, Workplace, Phabricator y veinte herramientas más.

La solución no fue construir una plataforma cerrada. Fue construir cuatro piezas que encajan y dejar que la comunidad interna las extienda.

Los 4 componentes del segundo cerebro de Meta

1. PARA: la estructura de carpetas que organiza todo

PARA es un método de organización creado por Tiago Forte en 2017 para humanos. Tiene cuatro categorías: Projects (proyectos con fecha de fin), Areas (responsabilidades continuas como “ventas” o “infraestructura”), Resources (referencias y documentación) y Archives (lo terminado o inactivo).

Meta tomó este método y lo aplicó al filesystem de cada empleado. La raíz contiene un archivo CLAUDE.md con la identidad del usuario y su portfolio activo. Cada proyecto tiene su propio CLAUDE.md con contexto específico. El agente carga el contexto raíz primero, ligero. Solo entra a leer un proyecto cuando lo necesita.

Esa decisión se llama progressive disclosure. Es opuesta al instinto de cargar toda la información al inicio. Cargar todo el contexto satura el modelo y degrada las respuestas. Lo confirmó la propia experiencia interna de Meta: tener demasiados archivos de contexto activos a la vez producía resultados peores.

2. La capa de infraestructura: MCPs y CLIs autenticados

Esta es la pieza que separa un asistente útil de un chatbot bonito. Sin acceso real a las herramientas que usas, un agente solo te puede hablar. Con acceso, puede leer un documento, escribir en él, asignar una tarea, ejecutar un script o publicar un comentario.

Meta construyó servidores MCP (Model Context Protocol) y CLIs internos que dan al agente acceso autenticado y con permisos limitados a sus herramientas: editores de documentos, plataformas de mensajería, sistemas de gestión de tareas, sistemas de revisión de código. El agente actúa con tu identidad, dentro de tus permisos, sobre las herramientas reales de tu día.

MCP es un protocolo abierto creado por Anthropic en noviembre de 2024. Cualquier empresa puede usarlo. La parte difícil no es el protocolo, es decidir qué herramientas conectar primero y con qué nivel de acceso.

3. El agent harness: Claude Code + el último modelo Anthropic

El agent harness es el “cuerpo” que ejecuta el cerebro. Meta eligió Claude Code, el agente de línea de comandos que Anthropic distribuye públicamente, corriendo sobre el modelo más reciente de la familia Claude.

Claude Code sabe navegar el sistema de archivos, llamar herramientas externas, integrar MCPs y recuperarse de errores. No es un wrapper minimal sobre la API. Es un agente con un loop de ejecución completo, capaz de planificar, ejecutar, observar resultados y ajustar.

La decisión importante aquí es que Meta no construyó su propio agent harness. Usó uno público y lo extendió con la capa interna de PARA, MCPs y skills. Esto reduce drásticamente la superficie de mantenimiento.

4. Skills: workflows reutilizables en markdown

Una skill es un archivo markdown con instrucciones para una tarea repetitiva. Meta tiene skills como /para-init (que arma la estructura PARA inicial del nuevo usuario), /start-project (que crea un nuevo proyecto con su contexto), /read-meeting-notes (que enruta automáticamente las notas de reunión al proyecto correcto) o /debrief:team (que genera un reporte para un manager con el estado de su equipo de diez personas).

El detalle clave: las skills son markdown plano. No son código compilado, no requieren un pipeline de deploy, no necesitan permisos especiales. Cualquier empleado puede escribir una skill, probarla, compartirla por Slack y otra persona la copia a su carpeta de skills.

Esto no es un detalle estético. Es la decisión que hizo viral el sistema. El umbral para crear una skill es tan bajo que cualquiera puede hacerlo en una tarde. La biblioteca interna de Meta llegó a miles de skills creadas por la comunidad, no por el equipo original.

Por qué Meta eligió “lean context + drill as needed”

La intuición ingenua es: si más contexto da mejores respuestas, voy a cargar todo. Es falsa. Pasado cierto punto, agregar contexto degrada la calidad de las respuestas, aumenta los costos en tokens y aumenta la latencia.

La regla que Meta documentó es simple. La raíz del PARA tiene contexto liviano: tu identidad, tus áreas activas, los nombres de tus proyectos. Eso le permite al agente entender de qué se trata tu vida laboral en menos de mil tokens. Cuando una tarea requiere detalles de un proyecto específico, el agente entra a leer ese CLAUDE.md puntual.

Es la diferencia entre tener todos tus archivos abiertos en el escritorio y tener una estantería con etiquetas. La estantería gana siempre.

Cómo se viralizó: de un parche de un data scientist a 10.000 DAU

Meta es explícito sobre esto: el creador original construyó la versión inicial. Casi todas las funcionalidades importantes que vinieron después fueron creadas por miembros de la comunidad interna, no por el equipo original.

Hubo nueve paquetes específicos por disciplina (uno para investigadores, otro para ingenieros de seguridad, otro para diseñadores, etc.). Cada paquete era un conjunto de skills relevantes para esa función. Y dentro de cada paquete, miles de skills creadas por individuos para resolver sus propios problemas.

El patrón es importante: la herramienta dejó de ser una herramienta y se convirtió en una plataforma. Cada extensión que alguien añadía hacía el sistema más útil para todos los demás. Esa dinámica solo funciona cuando el costo de añadir una skill es casi cero. Por eso markdown ganó sobre cualquier alternativa con compilación o deploys.

Qué puede replicar una empresa LATAM de 50 a 500 personas

La traducción es directa. Cada componente tiene una versión accesible para una PYME LATAM con presupuesto limitado.

PARA es gratis. Es una estructura de carpetas y archivos markdown. Cualquier persona puede armarla en una tarde leyendo el libro de Tiago Forte o un resumen.

Claude Code es gratis para uso básico y tiene planes pagos accesibles. Lo instala una persona en su computadora en cinco minutos. No requiere infraestructura propia.

MCPs públicos ya cubren probablemente el 80% del stack típico de una PYME. Hay MCP oficiales o comunitarios para Gmail, Google Calendar, Google Drive, Slack, Notion, Linear, Asana, Trello, GitHub, Stripe, HubSpot, Airtable, n8n, Supabase, Postgres y decenas más. La parte cara (construir conectores propios) ya está hecha.

Skills en markdown no requieren equipo de plataforma. Una persona escribe una skill como /cierre-mes, la guarda en una carpeta compartida, y el resto del equipo la copia a la suya. Si alguien la mejora, la versión nueva se difunde por Slack o por el README compartido.

En Kreante, cada colaborador construyó su propio segundo cerebro IA usando exactamente esta arquitectura. La escala es muchísimo menor que Meta, pero el patrón funciona idéntico. Cada uno tiene su PARA, sus MCPs conectados a sus herramientas, su Claude Code, y un puñado de skills propias. Las skills útiles se comparten entre el equipo y se vuelven parte del estándar.

Las 3 decisiones técnicas que importan más que el modelo

La elección del modelo IA es secundaria comparada con tres decisiones de arquitectura.

Infrastructure-first. Sin acceso autenticado a las herramientas internas, un agente es un chatbot caro. La inversión que más rinde es conectar MCPs a las herramientas que tu equipo realmente usa. El modelo IA importa menos que el inventario de tools accesibles.

Markdown sobre pipelines de deployment. Si para crear una skill nueva alguien necesita un PR, una review y un deploy, nadie va a escribir skills. Si solo necesita guardar un archivo .md en una carpeta, va a escribir cinco esta semana. La fricción de creación define la velocidad de la plataforma.

Progressive disclosure. Más contexto no es siempre mejor. La raíz del sistema debe ser ligera, fácil de cargar, suficiente para entender el contexto general. El detalle se carga cuando hace falta. Esta sola decisión te ahorra dinero en tokens y mejora la calidad de las respuestas en cualquier tamaño de organización.

Errores que cometen las empresas que intentan copiar este modelo

Visto desde fuera, parece tentador construir una plataforma cerrada bonita con UI personalizada, sistema de permisos granular y deploy automatizado. Es lo opuesto a lo que funcionó en Meta.

Las empresas que intentan copiar el resultado sin entender el principio cometen tres errores recurrentes.

Primero, copiar la complejidad sin la disciplina del progressive disclosure. Cargan todo el contexto de la empresa en cada sesión, el agente se vuelve lento y las respuestas empeoran.

Segundo, ignorar el onboarding low-friction. Si el primer día con el sistema requiere dos horas de configuración manual, la mayoría de empleados nunca llega al segundo día. El equivalente al /para-init de Meta es la diferencia entre adopción y abandono.

Tercero, querer una plataforma cerrada en vez de markdown viral. La tentación es construir un sistema con UI propia donde solo los admins pueden crear automatizaciones. Mata el efecto comunidad. La biblioteca de skills de Meta no existió porque la decretaron, existió porque cualquiera podía contribuir en quince minutos.

En resumen

Replicar el sistema de Meta no requiere su escala ni su presupuesto. Requiere cuatro decisiones simples: adoptar PARA como estructura de archivos, instalar Claude Code, conectar dos o tres MCPs a tus herramientas más usadas y permitir que cualquier persona del equipo escriba skills en markdown.

No esperes a tener “la plataforma perfecta”. Empieza con un PARA mínimo y diez skills. La adopción se construye desde una persona a la vez, y la utilidad crece con cada skill que alguien comparte.