Audiencia: Ingenieros senior
Formato: Opinión + patrones de arquitectura
Contexto: Equipos lean en LATAM
TL;DR
- Muchos sistemas de agentes están sobreingenierizados
- Más abstracción ≠ más valor
- Una arquitectura simple basada en pipes + herramientas bien definidas suele ser superior
El problema: demasiada magia
En los últimos 12 meses, los “AI agents” pasaron de ser una idea interesante a convertirse en stacks complejos:
- Orquestadores
- Planificadores
- Memoria vectorial
- Tool routers
- Loops recursivos
Todo esto… incluso para resolver problemas relativamente simples.
Señales claras de sobreingeniería
Si tu sistema tiene esto, probablemente estás sobreconstruyendo:
- Más de 3 capas de abstracción para ejecutar una tarea
- Debugging difícil o no determinista
- Dependencia excesiva de “autonomous loops”
- Prompts difíciles de versionar o testear
La alternativa: arquitectura simple
En lugar de agentes complejos, considera este patrón:
1. Entrada estructurada
{
"task": "generate_summary",
"input": "texto largo"
}
2. Router explícito
if (task === "generate_summary") {
return summarize(input);
}
3. Herramientas deterministas
Cada función hace una sola cosa bien:
async function summarize(text: string) {
return llm.call({
prompt: `Resume esto: ${text}`
});
}
4. Sin loops innecesarios
Evita patrones como:
- “agent decides what to do next”
- ejecuciones recursivas sin control
En su lugar:
- flujos lineales
- pasos explícitos
Comparación directa
| Enfoque | Complejidad | Debugging | Control | Coste |
|---|---|---|---|---|
| Agente complejo | Alta | Difícil | Bajo | Alto |
| Arquitectura simple | Baja | Fácil | Alto | Bajo |
¿Cuándo SÍ usar agentes?
Hay casos donde los agentes tienen sentido:
- Tareas abiertas (research, exploration)
- Workflows no deterministas
- Sistemas multi-step con alta variabilidad
Pero incluso ahí:
Empieza simple, añade complejidad solo si es necesario
Perspectiva de equipos lean
Esto es relevante para cualquier equipo que busque moverse rápido sin sacrificar calidad.
Realidad:
- Equipos que priorizan foco y claridad
- Necesidad de iterar rápido
- Búsqueda de sistemas mantenibles
Implicación:
- Cada capa innecesaria añade fricción
- La simplicidad mejora velocidad, debugging y escalabilidad
Patrón recomendado
En lugar de “agent frameworks”, usa:
- Funciones explícitas
- Orquestación ligera
- Logs claros
- Inputs/output bien definidos
Piensa en:
“LLM as a function”
no en:
“LLM as an autonomous system”
Riesgos de simplificar demasiado
- Perder flexibilidad en casos complejos
- Reescribir lógica si el sistema crece
Pero en la mayoría de los casos:
Es un trade-off correcto
Veredicto
Los agentes no son el problema.
El problema es usarlos cuando no los necesitas.
Reflexión final
La mejor arquitectura de IA hoy no es la más sofisticada.
Es la que tu equipo puede:
- entender
- mantener
- escalar
Sin fricción.