Lo que revela la construcción de un agente en 10 minutos sobre la arquitectura real
Herramientas como TrueForge, que permiten crear agentes en diez minutos, ocultan las decisiones arquitectónicas a las que te enfrentan los Deep Agents o LangGraph: habilidades, herramientas MCP, estados y rutas de fallo.
Fuentes: I Built an Agent in 10 Minutes. Then I Understood Why Building One Takes So Long.
Lo que reveló el trabajo con LangGraph, Deep Agents y TrueForge sobre la abstracción, el control y cómo se comportan realmente los agentes.
Mientras desarrollábamos DEVIN, una gran parte del esfuerzo se destinó a tareas que nunca son visibles cuando alguien simplemente utiliza un agente de IA.
Conectar los componentes de Deep Agents.
Configurar Daytona como entorno de pruebas.
Utilizar Ingest para gestionar la transmisión en tiempo real y la ejecución en segundo plano.
Hacer que todas estas partes colaboren entre sí.
El progreso fue lento.
Pero en algún momento de ese esfuerzo constante, surgió una imagen más clara de lo que realmente constituye un sistema de agentes.
No solo el modelo en sí.
Todo lo que lo rodea.
El entorno de ejecución.
Las herramientas.
El entorno de pruebas.
La capa de orquestación.
La forma en que los agentes se comunican entre sí y transfieren tareas.
Luego apareció un hackathon, y con él, TrueForge.
Casi de inmediato, se hizo evidente cuánta de la infraestructura que se había construido meticulosamente a mano podía ser transferida a una plataforma.
Construir un agente funcional no tomó más de unos diez minutos: conectar los MCPs relevantes, agregar las herramientas necesarias, redactar un archivo SKILL.md que describiera su comportamiento y, finalmente, ejecutarlo.
Después de todo el tiempo invertido en construir la infraestructura desde cero, esto parecía casi demasiado fácil.
Y, honestamente, era impresionante.
Eso es exactamente lo que debería sentirse una buena abstracción.
Pero el compromiso oculto tras esa facilidad aún no era evidente.
El agente de 10 minutos
La primera reacción fue pura admiración por lo sencillo que resultó el proceso.
TrueForge se encargó de la infraestructura circundante, dejando la tarea principal de describir qué debe hacer realmente el agente en la definición de habilidades.
Esa es una abstracción realmente sólida.
Los MCPs que se añadían eran visibles.
Las herramientas también eran visibles.
El archivo SKILL.md era visible asimismo.
Todo resultaba legible y fácil de comprender.
Por eso se arraigó el hábito de recurrir a él constantemente.
Fue solo con el uso continuo cuando surgió un problema más sutil, uno que no se había detectado durante el propio hackathon.
La preocupación no era qué se podía inspeccionar.
La preocupación era dónde residía realmente la arquitectura.
Una habilidad por sí sola no constituye una arquitectura
El agente raíz lee el archivo de habilidades y lo utiliza para decidir cómo aplicar las capacidades que se le han asignado, incluyendo cómo y cuándo crear subagentes.
Eso significa que un único SKILL.md puede terminar definiendo, de forma sutil, una gran parte de la estructura de comportamiento del agente.
Imagínese querer construir algo similar a esto:
Root Agent
/ \
/ \
Researcher Coder
/ \
/ \
Searcher Tester
Solo decirle al agente raíz algo como: “Aquí están sus herramientas; cree los subagentes que necesite y haga el trabajo”, no es lo mismo que diseñar el sistema.
Lo que realmente importa es definir la arquitectura directamente:
- qué agentes existen
- de qué es responsable cada uno
- qué herramientas van a qué agente
- qué contexto recibe cada agente
- cuándo debe ocurrir la delegación
- cómo es el proceso de recuperación tras un fallo
Esa es la distinción que comenzó a destacarse.
Al trabajar con el enfoque de Deep Agents, la arquitectura es algo que se construye deliberadamente.
Al trabajar con TrueForge, el aspecto de infraestructura es mucho más simple, pero la arquitectura conductual acaba dependiendo de si el agente principal interpreta la habilidad de la manera que se pretendía.
Esa dependencia vincula el comportamiento de todo el sistema mucho más estrechamente al modelo subyacente.
Un modelo más capaz podría interpretar la habilidad exactamente como se suponía que debía hacerlo.
Un modelo más débil podría seguir un camino completamente diferente con las mismas instrucciones.
Mismo archivo de habilidad.
Mismas herramientas.
Comportamiento resultante diferente.
La arquitectura en teoría no ha cambiado.
Solo ha cambiado la interpretación que el modelo da a esa arquitectura.
Esa brecha es lo que hizo que este enfoque fuera más difícil de confiar plenamente.
Trabajar en AEGIS reforzó esta preocupación
Mientras desarrollaban AEGIS, el equipo se topó con un problema sencillo pero revelador.
El agente debía investigar casos de estrangulamiento del bucle de eventos de Node.js.
Tenía que inspeccionar el código, reproducir el problema, medir el comportamiento en tiempo de ejecución, diagnosticar la causa raíz, proponer una solución y confirmar que dicha solución realmente funcionaba.
Al principio, la fase de verificación consistía básicamente en una instrucción que indicaba al modelo qué hacer, más o menos así:
Ejecuta el experimento, compara las métricas resultantes y determina si la solución realmente resolvió el problema.
Pero dejar que un LLM decida por sí mismo si su propio parche tuvo éxito en realidad no se considera verificación.
Por lo tanto, la parte determinista de esa lógica se trasladó al código en lugar de al texto del prompt.
El modelo realiza el razonamiento.
El sistema lleva a cabo la medición.
El verificador realiza la llamada.
Esa experiencia generó un principio que ahora se aplica ampliamente al diseño de agentes:
Si algo no puede observarse, no se puede probar adecuadamente. Si no se puede probar, no se puede evaluar. Y si no se puede evaluar, no se puede mejorar de manera fiable.
Este es precisamente el motivo por el que la arquitectura es importante.
No porque un diagrama con más casillas y flechas sea intrínsecamente superior.
Porque se necesita una explicación clara de qué generó el comportamiento que se intenta mejorar.
"Funciona" versus "Entiendo por qué funciona"
Dos agentes diferentes pueden tener éxito técnicamente ambos.
Ambos pueden completar la tarea asignada.
Ambos pueden verse excelentes en una demostración en vivo.
La verdadera prueba surge cuando algo sale mal.
Con un tipo de agente, es posible rastrear el camino exacto de ejecución:
Root Agent
↓
Researcher
↓
Search Tool
↓
Result
↓
Root Agent
↓
Coder
↓
Sandbox
Cada punto de decisión puede ser examinado y cuestionado:
¿Por qué ocurrió este paso en particular?
Con otro tipo de agente, solo existe una habilidad que describe el resultado deseado, mientras que el modelo determina el camino por sí mismo.
Cuando funciona, parece increíblemente simple.
Cuando falla, la pregunta de depuración se vuelve mucho más difícil de responder:
¿La falla fue causada por el modelo, las instrucciones, la lógica de delegación, el contexto proporcionado o la arquitectura que el modelo improvisó por su cuenta?
Ese segundo escenario es un problema mucho más difícil de resolver.
Y eso es lo que enseñó TrueForge
Antes de trabajar con la plataforma, la suposición natural es que la parte más complicada de crear agentes reside íntegramente en la capa de infraestructura.
Trabajar con ella cambia esa visión. Resulta que la infraestructura es solo la mitad del desafío.
La infraestructura es algo que se puede abstraer.
El comportamiento resiste la abstracción.
Una plataforma puede proporcionar un entorno aislado.
Puede proporcionar MCP.
Puede proporcionar transmisión en tiempo real.
Puede proporcionar todo el entorno de ejecución.
No obstante, si estás creando un agente cuyas acciones realmente importan, aún debes responder por ti mismo a algunas preguntas:
¿Qué componente toma qué decisiones?
¿Qué se permite hacer y por qué?
¿Dónde ocurre exactamente la delegación?
¿Qué nivel de visibilidad tienes sobre el proceso?
¿Qué puedes medir o evaluar realmente?
¿Qué recursos existen para solucionar los problemas cuando surgen?
Estos son los aspectos que nadie debería transferir sin pensarlo dos veces.
¿Cuánto tiempo se necesita para entender por qué falló?
Construir un agente en diez minutos es realmente una hazaña impresionante.
Pero una pregunta más útil comienza a ser más importante que esa velocidad:
¿Cuánto tiempo se necesita para entender por qué falló?
Los entornos de producción no recompensan una primera demostración exitosa.
Lo que sí castigan es la décima falla.
La herramienta que devuelve resultados inesperados.
El modelo subyacente más débil.
El agente que transfiere el trabajo cuando no debería hacerlo.
El agente que falla al transferir el trabajo cuando debería hacerlo.
El agente que anuncia “Hecho”,
mientras en realidad no se ha logrado nada.
Es precisamente allí donde la arquitectura demuestra su valor.
Qué se aprendió realmente
Al reflexionar sobre el proyecto DEVIN, la verdadera lección no fue dominar Deep Agents, Daytona o Ingest como herramientas independientes.
Fue comprender cómo se conectan entre sí los componentes de un sistema de agentes.
Luego, TrueForge demostró cuán rápido se pueden abstractar esos mismos componentes para ocultarlos.
Y usarlo reveló el otro lado de esa conveniencia:
La infraestructura puede desaparecer de un flujo de trabajo sin que el comportamiento también lo haga.
Sigue siendo necesario que alguien controle ese comportamiento.
Aún hay alguien que necesita verlo en acción.
Aún hay alguien que debe evaluar si funciona o no.
Y aún hay alguien que tiene que decidir qué se cambiará cuando falle.
Esa responsabilidad es una que vale la pena mantener bajo control, no externalizarla.
Hacia dónde se dirige la arquitectura de agentes
Esta experiencia también transforma la forma en que se puede comprender más ampliamente la trayectoria de los sistemas agentes.
El campo ha progresado a través de distintas etapas:
modelos → herramientas → MCP → agentes → agentes avanzados
y en cada etapa, la infraestructura necesaria se vuelve cada vez más sencilla de obtener.
Según esta perspectiva, la capa más importante en el futuro es el entorno que rodea al modelo.
No solo la capacidad bruta del modelo, sino también el sistema que le proporciona:
contexto, herramientas, ejecución, permisos, orquestación, memoria, observabilidad, evaluación y control.
A medida que los modelos siguen mejorando, la calidad bruta del modelo por sí sola dejará de ser el factor decisivo.
La pregunta técnica importante que habrá que plantearse será cada vez más:
¿Qué entorno se ha creado alrededor del modelo, y qué grado de control existe sobre su comportamiento?
Esa es, sin duda, la lección central de la creación de DEVIN y posteriormente del montaje de un agente en diez minutos.
Cuanto más sencillo sea crear un agente, más crucial se vuelve comprender todo lo que lo rodea.
Lecturas relacionadas
- Qué realmente automatiza LangChain una vez que has creado un bucle de agente — Explica cómo LangChain, LangGraph y SDK similares envuelven el mismo bucle de agente básico construido desde cero, y cuándo recurrir a un framework ayuda o perjudica.
- Elegir un framework de agente AI en Python en 2026: Una comparación práctica — Compara cinco frameworks de agente AI en Python según su forma de manejar los fallos y la complejidad, ayudando a los lectores a elegir la herramienta adecuada para su flujo de trabajo.