Prompteo

Unidad 1 · 2 min

Cuándo conviene un equipo

Lo que cuesta realmente pasar de un agente a varios, qué tareas lo justifican y por qué la recomendación documentada es exprimir primero un solo agente.

Cuándo conviene un equipo

Antes de diseñar topologías conviene una pregunta incómoda: ¿hace falta un equipo?

El sobrecosto es real

Anthropic midió su sistema de investigación: los agentes consumen alrededor de 4 veces más tokens que un chat, y los sistemas multiagente alrededor de 15 veces más. El uso de tokens por sí solo explicó el 80% de la varianza de desempeño, y pasar a un modelo más capaz rindió más que duplicar el presupuesto de tokens. Antes de comprometerte con un flujo de muchos agentes, mídelo sobre una porción pequeña: un directorio en vez del repositorio entero.

Qué tareas lo justifican

Los sistemas multiagente rinden con paralelización pesada, información que excede una sola ventana de contexto y muchas herramientas complejas. La escritura de código aparece como mal candidato: menos subtareas realmente paralelizables y agentes que todavía no coordinan bien entre sí en tiempo real. LangChain agrega tres motivaciones —gestión de contexto, desarrollo distribuido y paralelización— y tres condiciones: demasiadas herramientas que el agente elige mal, conocimiento especializado con contexto extenso, o restricciones secuenciales que hay que imponer.

Un solo agente primero

La recomendación general es maximizar primero un agente único, que escala agregando herramientas de forma incremental y mantiene simples la evaluación y el mantenimiento. Las señales para dividir son concretas: prompts llenos de ramas condicionales, herramientas que se superponen entre sí, y agentes que fallan al seguir instrucciones complicadas o eligen mal. La complejidad se agrega solo cuando mejora los resultados de forma demostrable.