¿Por qué los frameworks de agentes de IA son tan complejos? Hace falta un framework revolucionario como Rails

Problemas principales de los frameworks actuales de agentes de IA

• Agotamiento de la ventana de contexto
  • En tareas complejas, el modelo olvida el objetivo original
  • Se producen alucinaciones y bucles infinitos
• El papel de envoltorio delgado del framework
  • Delega en el desarrollador la elección del modelo, el proveedor de embeddings, la estructuración de herramientas, etc.
  • Viola el principio de "no me hagas pensar"
• Confusión por exceso de herramientas
  • Evaluar opciones innecesarias desperdicia contexto

Solución propuesta: arquitectura centrada en subagentes

• Usar subagentes como ciudadanos de primera clase
  • Delegación natural, como en una llamada de función
  • Tienen contexto independiente → el agente padre mantiene el enfoque
  • Ejemplo: un subagente de búsqueda en el codebase → devuelve solo las rutas de archivos relevantes
• Efecto
  • Agente único: consume 90% del contexto
  • Con subagentes: el contexto del padre usa solo 25%

Aplicar la lección de Rails: Convention over Configuration

• Priorizar convenciones predeterminadas
  • Selección automática del modelo (según la complejidad de la tarea)
  • Herencia del presupuesto de contexto entre padre e hijo
  • Creación automática de checkpoints para tareas riesgosas
• Introducción de arquetipos (Archetype)
  • Searcher: solo herramientas de búsqueda
  • Writer: solo herramientas de escritura
  • Researcher: solo acceso web → evita el exceso de herramientas

Principios prácticos de diseño

• Diseño centrado en la tarea
  • En vez de "¿qué modelo uso?", priorizar la tarea real (ej.: validación de un formulario de registro)
• Naturaleza temporal del contexto de los subagentes
  • Solo se devuelve al padre un resumen del trabajo intermedio
• Diferencia entre herramienta y subagente
  • Herramienta: sin estado (formateo de fecha, parsing de JSON)
  • Subagente: requiere iteración y juicio (búsqueda, análisis)

Elección tecnológica: TypeScript

• Mayor seguridad de tipos (Branded types, discriminated unions)
• Compatibilidad con el ecosistema de herramientas de desarrollo (VS Code, etc.)
• Con Bun se pueden compilar ejecutables independientes

Retos aún no resueltos

• Compartir contexto entre subagentes (base de conocimiento del proyecto)
• Colaboración entre agentes pares (envío de mensajes)
• Evaluación de agentes (captura y reproducción de escenarios, criterios de éxito, consistencia y preferencia)

Conclusión

• Un framework no debe añadir complejidad, sino aportar la "complejidad correcta"
• Un framework revolucionario como Rails puede transformar el desarrollo de agentes
• Minimizar el trabajo de plomería → enfocarse en el problema central

[ahwjdekf]

Los frameworks de agentes... el nombre suena grandioso, pero al final no son más que herramientas que se lo pasan al LLM. Están vacíos por dentro.

[click]

Rails es conveniente porque impone convenciones y hace mucha magia bajo la capa de abstracción, aunque existe el trade-off de un rendimiento menor; pero eso no es un gasto inmediato.
En cambio, si el framework elige el modelo como se le da la gana, ¿quién se hace responsable cuando te explota el uso de tokens?

[nomak]

¿No aparecerá alguna herramienta nueva en 2026? Será distinta a Rails, pero más abstracta... Tengo expectativas.