Manus, adquirida por Meta en $300M, revela los principios clave del desarrollo de agentes junto a LangChain
Manus compartió las lecciones más duras detrás de construir agentes de IA en producción - desde la degradación de contexto hasta replantear la evaluación - en una presentación conjunta con LangChain.
La adquisición de Manus por parte de Meta en 300 millones de dólares acaparó titulares, pero la historia de fondo es lo que Manus reveló en una presentación conjunta con LangChain. La charla expuso los principios esenciales detrás de construir agentes de IA que realmente funcionan - y trazó una línea clara entre los errores típicos de startups y las estrategias que dan resultados.
La paradoja de la degradación de contexto
Los agentes necesitan herramientas. Más herramientas significan más capacidades. Pero hay una trampa: entre más herramientas usa un agente, más crece su contexto - y el rendimiento se degrada como consecuencia directa.
Manus llama a esto Context Rot (degradación de contexto). Es la paradoja central del desarrollo de agentes: lo mismo que hace a tu agente más poderoso también lo hace más torpe.
La solución es la Ingeniería de Contexto - mostrarle al modelo solo la información que necesita para el siguiente paso, nada más.
Manus detalló seis técnicas específicas:
- Descargar (Offload) - Mover datos que consumen muchos tokens al sistema de archivos en lugar de mantenerlos en contexto
- Reducir (Reduce) - Eliminar agresivamente la información obsoleta
- Compactar (Compact) - Comprimir de forma reversible datos recuperables (por ejemplo, quitar el contenido de un archivo pero conservar la ruta)
- Resumir (Summarize) - Comprimir información de forma irreversible, pero siempre a través de un esquema estructurado
- Recuperar (Retrieve) - Proveer información bajo demanda mediante búsqueda
- Aislar (Isolate) - Usar subagentes con sus propios contextos separados
El punto clave: la gestión del contexto no es una optimización opcional. Es una decisión arquitectónica fundamental que determina si tu agente escala o colapsa bajo su propio peso.
No hagas fine-tuning antes del product-market fit
Uno de los errores más comunes que Manus señaló en startups: construir modelos especializados antes de encontrar el product-market fit.
El razonamiento es directo. Un modelo de propósito general combinado con ingeniería de contexto sólida permite ciclos de iteración mucho más rápidos. Cuando haces fine-tuning temprano, te amarras a supuestos sobre el comportamiento del usuario que todavía no se han validado.
El punto más filoso: la velocidad a la que puedes mejorar tu modelo marca el techo de la velocidad de innovación de tu producto. El fine-tuning desacelera ese ciclo. La ingeniería de contexto lo mantiene rápido.
Guarda el fine-tuning para después de haber demostrado que el producto funciona. Antes de eso, es optimización prematura en su versión más costosa.
Patrones multiagente: dos enfoques distintos
Manus identificó dos patrones multiagente fundamentales, cada uno adecuado para distintos tipos de trabajo:
Patrón de Comunicación - Los subagentes arrancan con un lienzo en blanco. El agente principal envía una solicitud enfocada, el subagente la procesa de manera independiente y devuelve el resultado. Ideal para tareas de bajo contexto y paralelizables, como búsqueda de código o recuperación de datos.
Patrón de Memoria Compartida - Los subagentes comparten el historial completo de la conversación pero operan con prompts y conjuntos de herramientas diferentes. Ideal para tareas complejas e interdependientes, como investigación profunda donde cada paso se construye sobre hallazgos previos.
La elección entre uno y otro no es cuestión de capacidad - es cuestión de requisitos de contexto. Si la subtarea es autocontenida, usa Comunicación. Si necesita el panorama completo, usa Memoria Compartida. Equivocarse en esto significa desperdiciar tokens en contexto innecesario o dejar a los agentes sin la información que necesitan.
Un espacio de acciones en tres capas para evitar la sobrecarga de herramientas
Demasiadas herramientas confunden al modelo. La respuesta de Manus es una arquitectura por capas que limita lo que el modelo ve en cada momento:
Capa Atómica - De 10 a 20 capacidades básicas: leer, escribir, shell, navegador. Están siempre disponibles y el modelo las usa directamente.
Utilidades del Sandbox - Herramientas CLI preinstaladas como convertidores, linters y formateadores. El modelo las invoca a través del shell en lugar de tenerlas como herramientas dedicadas.
Paquetes y APIs - Scripts de Python con claves de API preautenticadas. Manejan las interacciones con servicios externos sin exponer toda la superficie de la API al modelo.
Esta estructura por capas mantiene manejable el espacio de decisión del modelo. En lugar de elegir entre 200 herramientas, elige entre 15 acciones centrales y delega todo lo demás al shell. El resultado es una selección de herramientas más confiable y menos llamadas confusas o alucinadas.
Replantear las métricas de evaluación
Los benchmarks públicos como GAIA no reflejan las preferencias reales de los usuarios. La postura de Manus es directa: el estándar de oro son las calificaciones de los usuarios sobre sesiones completadas, puntuadas del 1 al 5.
Surgieron tres principios de evaluación:
- Pruebas de ejecución sobre pruebas de preguntas y respuestas - ¿Puede el agente realmente completar la tarea en un sandbox? Eso importa más que si puede responder preguntas sobre la tarea.
- La calidad subjetiva requiere revisión humana - El acabado visual, el tono y la coherencia general no se pueden calificar automáticamente. Una persona necesita ver el resultado.
- Los puntajes de benchmarks son necesarios pero insuficientes - Demuestran capacidad base. No demuestran que el producto sea bueno.
La lección central
La sobreingeniería es el enemigo.
Las mayores ganancias de rendimiento no vienen de agregar complejidad - vienen de eliminarla. No le hagas el trabajo más difícil al modelo. Hazlo más simple.
Este es, probablemente, el motivo por el que Meta pagó 300 millones de dólares por Manus. No por funcionalidades llamativas, sino por una filosofía de diseño centrada en lo esencial. Quitar lo que no se necesita, gestionar el contexto sin piedad y construir sistemas donde el modelo pueda enfocarse en la tarea en lugar de ahogarse en su propio estado.
Los agentes que funcionan en producción no son los que tienen más capacidades. Son los que hacen que cada capacidad cuente.
Unite al boletín
Recibí actualizaciones sobre mis últimos proyectos, artículos y experimentos con IA y desarrollo web.