¡Hola Devs! La solución contraintuitiva: dale menos trabajo a tu agente
Fíjate en cómo casi todos los equipos empiezan a construir agentes de IA en producción: un agente bien listo, cargado con todos los schemas, reglas y patrones que podría necesitar. En la demo funciona hermoso. En producción... empieza a alucinar.
En Meta, este modo de falla apareció justo así al automatizar el onboarding de columnas de datos en sistemas de recomendación: tres repositorios, tres lenguajes y hasta seis etapas de pipeline que tienen que mantenerse sincronizadas. El primer intento fue un solo agente con todo el conocimiento de dominio embebido. Pasado cierto umbral de contexto, más conocimiento empeoró el resultado, no lo mejoró. El agente empezaba a contaminar conceptos: aplicaba convenciones de nombres de un subsistema en otro, o usaba un patrón de generación de código pensado para una fuente de datos distinta.
Un preprint del Windreich Department of AI and Human Health de Mount Sinai lo confirma: sistemas multiagente orquestados alcanzaron 65.3% de precisión en lotes de 80 tareas, donde agentes únicos cayeron a 16.6%, reduciendo el uso de tokens hasta 65 veces. El mecanismo es el aislamiento de tareas evitando interferencia de contexto. Meta vivía lo inverso: un agente ahogándose en su propio conocimiento.
Este análisis se basa en el writeup publicado por Meta Engineering — checa el 근거자료 para ver los detalles completos de producción.
La arquitectura: router determinístico + especialistas aislados
El sistema se divide en dos capas con una frontera bien dura entre ellas:
- Un orquestador delgado (~1,300 líneas) que hace cero trabajo de dominio. Clasifica intención, junta campos obligatorios, corre gates de confiabilidad y delega. Nunca razona sobre código, nunca genera configs, nunca toca el repo.
- Catorce subagentes especialistas, cada uno un experto completo de dominio con ventana de contexto aislada. El agente de schema conoce los registries de config. El agente de population sabe generar código para las 10 fuentes de datos. El agente de validación conoce los build systems. Ningún agente ve el panorama completo — y eso es la feature, no el bug.
El orquestador sigue un protocolo fijo de 7 pasos en cada request:
# Protocolo fijo — pasos 1-5 y 7 son determinísticos, solo el paso 6 usa razonamiento de LLM
def handle_request(user_request):
# 1. Carga el archivo de instrucciones del subagente objetivo
instructions = load_subagent_instructions(classify_intent(user_request))
# 2. Chequeo de duplicados — ¿el objetivo ya existe?
if target_exists(user_request):
return early_exit("El objetivo ya existe")
# 3. Junta los campos obligatorios con el usuario
fields = collect_required_fields(user_request, instructions.checklist)
# 4. Auto-descubre lo que se puede inferir (tipo de repo, configs existentes)
inferred = auto_discover(fields)
# 5. Gate de confiabilidad: warnings activos, revisores obligatorios
gate = reliability_check(fields, inferred)
if not gate.passed:
return escalate(gate.reason)
# 6. Delega al subagente — el ÚNICO paso con razonamiento de LLM
result = subagent.execute(context=fields + inferred)
# 7. Devuelve resultado y errores de forma determinística
return confirm_or_report(result)
Workflow templates, no nuevos agentes
El segundo insight clave: separar qué tiene que pasar de cómo se hace cada paso. El orquestador define el orden de fases con máquinas de estado determinísticas que restringen el espacio de decisión del LLM:
| Workflow | Secuencia de fases |
|---|---|
| Column Onboarding | Schema → Validation → Population → Testing |
| Event Onboarding | Schema → Population → Validation → Testing → Event Processing |
| Pipeline Migration | Assessment → Planning → Population → Validation → Monitoring |
Cuando Meta necesitó pipeline migration — un caso de uso totalmente nuevo — escribió cero código de agente nuevo. Escribió un nuevo workflow template que reordenó los 14 subagentes existentes. Cada subagente sigue una estructura uniforme (fuentes de conocimiento, checklist de pre-recolección, workflow paso a paso, patrones de descubrimiento, troubleshooting), así que el subagente número 15 es estructuralmente idéntico al primero. Los archivos de conocimiento (25+) se cargan on demand al momento de ejecución, no van embebidos en el orquestador — una actualización aplica en la siguiente sesión, sin redeploy.
Los límites y cuidados
Este patrón no es gratis, y el writeup de Meta es honesto con los trade-offs:
- Cambias generalidad por profundidad. Cerca de dos tercios de los cambios entran sin edición humana significativa — pero eso es porque cada subagente está bien acotado. Un request fuera de cualquier workflow template no tiene camino hasta que escribas uno.
- El costo de diseño inicial es real. Definir 14 fronteras de dominio limpias, estructura uniforme de subagente y gates determinísticos es trabajo de arquitectura considerable. El retorno llega a escala, no el día uno.
- La frontera determinístico/probabilístico tiene que ser explícita. Para cada componente, decide: ¿es una decisión de ruteo (determinística) o una tarea de razonamiento (probabilística)? Mezclarlas es cómo fallan los orquestadores gordos — cuando un orquestador gordo alucina, el error se propaga: agente equivocado, campos equivocados, chequeos de confiabilidad saltados.
- No arregla subagentes malos. El aislamiento contiene fallas; no hace correcto a un especialista. Sigues necesitando validación y revisión humana en cualquier actualización automática de conocimiento.
¿Para dónde ir ahora?
La tesis composicional predice que escalar significa agregar workflow templates y archivos de conocimiento — no reconstruir agentes. Si construyes agentes en producción, empieza auditando tu orquestador: si está tomando decisiones de dominio, está haciendo demasiado. Empuja ese razonamiento a los subagentes aislados y mantén el ruteo determinístico. Para ver cómo una capa de data foundation sostiene sistemas agénticos, checa Beyond the Model: How Pantone Built an AI-Ready Data Foundation for Agentic Creativity.
Conclusión
El componente más importante del sistema de agentes de IA de Meta es el que hace menos trabajo. Un orquestador delgado deja poquísimo espacio para alucinaciones, porque ruteo y confiabilidad no dependen de razonamiento de LLM — siguen un protocolo fijo. La creatividad pasa downstream, en contextos aislados y acotados por dominio, donde el riesgo se minimiza y las fallas quedan contenidas.
Mantén tu orquestador delgado y tus especialistas profundos, y todo el sistema se vuelve más confiable. Y si andas tematizando componentes de UI mientras armas tus dashboards de agentes, la guía de theming con CSS relative colors y OKLCH combina bien con esta mentalidad arquitectural: tokens determinísticos, responsabilidades aisladas.