Nuestro bucle de agente tiene 239 líneas. Framework y runtime no son la misma capa.

La expresión plataforma de agentes se ha tragado al menos tres capas distintas: la biblioteca con la que escribes un agente, el motor que lo ejecuta y el plano que lo gobierna. Casi toda discusión sobre herramientas de agentes son dos personas respondiendo a preguntas diferentes. Una dice que montó un agente funcional en tres líneas; la otra quiere saber quién autorizó la llamada que salió ayer a las tres de la tarde. Ambas tienen razón y ninguna habla de la misma capa.

No vamos a juzgar las tripas de nadie más, porque ser justo con eso exigiría leer su código lo bastante a fondo como para merecer la opinión. Así que este artículo hace otras dos cosas: describe de qué responde normalmente la capa de framework, que no es polémico, y usa nuestro propio repositorio como muestra para la capa de runtime, donde cada afirmación viene con un fichero y un número de línea. La muestra es github.com/soit-ai/soit, Apache 2.0, en el commit 3a57ae1.

Empecemos contando nuestro propio bucle de agente. El planificador, el ejecutor y el verificador suman 239 líneas. El servicio que envuelve esas 239 líneas tiene 1.617, y su lista de imports delata en qué las gasta: un guardián de espacio de trabajo, un libro de aprobaciones, un limitador de tasa, un servicio de ejecución de herramientas con concesiones y claves de idempotencia, un escritor de trazas, una regla de aprobación y un resolutor de herramientas. El bucle en sí es un único while. Una línea de bucle, mil seiscientas alrededor, y casi ninguna trata de cómo piensa el agente.

La frontera entre ambas capas no es un diagrama, es un puerto. Cada llamada a herramienta atraviesa una pasarela de políticas de 475 líneas antes de llegar a un adaptador, y ahí viven las preguntas incómodas. No si la lógica del agente se lee bien, sino si un reintento abre dos veces el mismo ticket cuando el sistema de destino no respeta una clave de idempotencia. Por eso las llamadas en esa frontera son como mucho una vez.

Podrías objetar, con razón, que simplemente empujamos el código de gobierno aguas abajo de nuestro bucle. La respuesta es el segundo modelo de ejecución del mismo repositorio: un motor de flujos DAG de 6.269 líneas, estructuralmente nada parecido a un bucle de agente. Llega a las herramientas por el mismo puerto de herramientas y a los modelos por el mismo puerto de modelos. Dos modelos de ejecución sin relación entre sí y un único conjunto de garantías: esa es la definición operativa de una capa. El gobierno es una propiedad del puerto y no del bucle, así que cambiar lo que hay encima no quita ninguno de los diez controles de debajo.

La separación en capas suele escribirse en la documentación y pudrirse en el código, así que esta la vigila una herramienta. El primer contrato de imports del repositorio prohíbe que el núcleo importe la API, los módulos, los adaptadores, la infraestructura o el cableado. Cuando el núcleo necesita datos de producto o de infraestructura, tiene que pasar por interfaces de proveedor registradas desde la capa de cableado. Ese es el coste corriente de mantener viva una frontera, y lo paga la integración continua en vez de la disciplina.

La parte honesta: ese motor de flujos sí se solapa con los frameworks de orquestación, y fingir lo contrario sería absurdo. Tiene compilador, resolución de variables, ejecutores de nodo, una vía de reanudación y un recolector. La afirmación exacta no es que no construyamos maquinaria de framework, sino que construimos solo la parte necesaria y luego la sometemos a las mismas reglas que a cualquier otro que llame.

Entonces, ¿qué significa en la práctica que esto no sea un framework competidor? Las herramientas escritas para un framework pueden registrarse vía MCP y, a partir de ahí, cada llamada suya pasa por los mismos controles. Los servicios pueden engancharse como plugins HTTP. El frontend no tiene que cambiar, porque la interacción es un flujo de eventos AG-UI. Lo que falta importa más que todo eso: no hay ningún punto de entrada que tome el agente que escribió otra persona y lo aloje entero. Tu bucle sigue corriendo en tu proceso. Lo que se gobierna es la mano que ese bucle extiende, la llamada a herramienta, la llamada al modelo y la petición de salida, no el razonamiento que hay detrás.

El framework decide cómo piensa un agente; el runtime decide si cuenta el instante en que extiende la mano. No compiten, porque ni siquiera actúan en la misma escala de tiempo: una se aplica a los días que pasas escribiendo el código, la otra a cada ejecución posterior. La única competencia real es por la atención, y el desplazamiento de la primera a la segunda suele llegar tarde, es decir, después del primer incidente.