LangGraph, CrewAI y los small language models son sexy pero over-engineered en el 90% de casos. La heurística que uso para decidir.
TL;DR — Multi-agente y SLMs se aplican en exceso. Regla práctica: empezá con un solo LLM. Si no basta, agregá tools. Si aún no basta, dividí en dos agentes con roles cualitativamente distintos. Solo cuando la tarea tiene etapas independientes que se benefician de verificación cruzada (ej. planner + executor + auditor), el multi-agente supera al modelo único. Los SLMs pagan su ahorro con fine-tuning y mantenimiento del eval set — sale más caro que la factura de un LLM grande con criterio.
El síntoma en LinkedIn
Cada vez que abro LinkedIn veo un nuevo tutorial de LangGraph con cinco agentes conversando entre sí para responder “hola”. Es hermoso ver los diagramas: un planner, un researcher, un writer, un reviewer, un supervisor. Cinco cajas con flechas. Un artefacto de ingeniería que impresiona.
Y en el 90% de los casos, un solo LLM (Claude, GPT-4, Gemini) con un buen prompt haría lo mismo — más rápido, más barato, más fácil de depurar.
He construido sistemas con múltiples agentes. Mi Consola SOS (sistema operativo interno de una fundación) está 100% orquestada por agentes de IA. Sé lo que aporta y sé lo que cuesta. Y por eso mi default es: empezar con uno.
Tres niveles antes de armar el grafo
Nivel 1 — Un solo LLM
Si tu tarea se describe en un párrafo — “clasifica este ticket en cinco categorías”, “extrae los datos de esta factura”, “responde esta pregunta usando estos documentos” — un solo LLM con instrucciones claras lo hace. No necesitás ni un agente. Ni siquiera necesitás tools. Un messages.create() responde bien.
Nivel 2 — Un solo LLM con tools
Si la tarea necesita datos que no están en tu prompt — mirar una base, consultar una API, ejecutar código — le das al LLM las tools y él decide cuándo llamarlas. Sigue siendo un solo modelo. El “agentic loop” es un while stop_reason == "tool_use". Diez líneas de Python.
Nivel 3 — Multi-agente
Solo cuando la tarea tiene etapas cualitativamente distintas que se benefician de contextos diferentes y verificación independiente. Ejemplo real: en la Consola SOS un agente escribe el spec, otro lo implementa, un tercero — sin ver el proceso — audita el resultado. Cada uno con su propio system prompt, su propia lente. Ahí sí — y solo ahí — el multi-agente supera al modelo único.
La regla que uso
Si los agentes van a ejecutar la misma tarea desde ángulos distintos, ganás. Si van a hacer pasos secuenciales que un solo modelo puede resolver de corrido, perdés.
Perdés en latencia (cada llamada suma segundos), en costo (cada agente factura), en debugging (cascadas de errores difíciles de trazar), y en resultados (los errores de un agente contaminan al siguiente).
El truco de los SLMs
Sobre los small language models — misma trampa, distinto disfraz. El argumento es “más barato en producción, ejecutable local, privacidad”. Todo cierto. Pero el 80% del tiempo el usuario los mete en tareas donde el modelo grande resolvía con menos código, menos tuning, menos evals.
Un SLM ganado se paga con un mes de fine-tuning y otro de mantener el eval set actualizado. Sale más caro que la factura de un LLM grande usado con criterio. Los SLMs valen cuando tienes volumen alto, latencia crítica, y una tarea muy específica que ya calibraste — no antes.
El principio
Los sistemas de IA se hacen simples primero, complejos después — no al revés. La complejidad tiene que ser una respuesta a un problema medido, no una decisión estética.
Empezá con un LLM. Si no basta, agregá tools. Si aún no basta, dividí en dos agentes con roles distintos. Si aún así no basta — con evidencia — armá el grafo.
¿Cuántos sistemas multi-agente en producción son honestamente un messages.create() disfrazado de arquitectura?
