Un agente de IA es igual a un modelo de IA más un arnés: qué hace el arnés y por qué.
Un agente es un modelo más un arnés. Vea cómo los arneses añaden herramientas, memoria, bucles y medidas de seguridad, cómo difieren los agentes de peso abierto y código abierto, y por qué son importantes las evaluaciones.
Por un tiempo, la historia del progreso de la IA se contó a través del lanzamiento de modelos: modelos base cada vez más grandes y capaces que aparecían cada pocos meses. Esa historia es incompleta. Un modelo de lenguaje, ya sea grande o pequeño, proporciona inteligencia bruta, pero cuánta de esa inteligencia llega al usuario depende del software que lo rodea. Ese software se denomina “harness”, y un número creciente de estudios sugiere que puede ser tan importante como el modelo en sí. Investigaciones recientes sobre cómo adaptar estos “harnesses” a modelos más pequeños argumentan que un “harness” ajustado cuidadosamente puede permitir que un modelo compacto recupere gran parte del rendimiento de un modelo avanzado en tareas empresariales, a un costo mucho menor. Consulte las cifras exactas en los artículos originales, pero la tendencia es coherente con lo que observan los profesionales: el modelo más potente no siempre genera el sistema más capaz.
Así que la competencia se centra cada vez más en quién construye el mejor arnés, y no solo en quién crea el modelo más grande.
Por qué un modelo inteligente aún necesita un arnés
Un modelo de lenguaje puede generar una respuesta. Por sí solo, no puede navegar por una carpeta, elegir entre herramientas, mantener la memoria de trabajo entre llamadas, verificar lo que escribió, recuperarse de un error o seguir avanzando hacia un objetivo. Esos vacíos son los que existen para ser llenados por los agentes. En un agente, el arnés rodea al modelo y convierte su inteligencia en acciones estructuradas, repetibles y orientadas a un objetivo.
Modelo versus agente
Un modelo recibe una entrada y genera una salida, y luego su trabajo ha terminado. Un agente sigue trabajando después de la primera respuesta. Lee archivos, utiliza herramientas, ejecuta comandos, recuerda resultados anteriores, toma decisiones y continúa a través de varios pasos hasta que la tarea se completa.
¿Cómo puede ocurrir eso si un modelo se crea únicamente para predecir la siguiente salida? A través del sistema de soporte, el entorno técnico que rodea al modelo. Este sistema decide qué contexto entra en el modelo, qué herramientas están disponibles, cómo se ejecutan las llamadas a las herramientas, qué se recuerda, cuándo se vuelve a llamar al modelo y qué acciones se rechazan o necesitan aprobación.
El sistema de soporte también crea el bucle de trabajo:
El ciclo funciona de la siguiente manera: el modelo lee lo que hay en su contexto, elige una acción, llama a una herramienta, examina el resultado obtenido, lo integra en su contexto y vuelve a comenzar.
Ese bucle es lo que diferencia responder de completar una tarea. También puede estar vinculado a un programador o a un disparador externo, de modo que el agente comience por sí mismo en un momento determinado o cuando ocurre un evento.
La ecuación: agente = modelo + sistema de soporte
El modelo es la parte que realiza las predicciones. Dependiendo del contexto con el que cuenta, genera la salida o acción siguiente más útil. El entorno es el software que lo rodea y que convierte esa capacidad bruta en un comportamiento controlado y multietapa.
Mire lo que sucede cuando se coloca el mismo modelo en diferentes entornos:
- Con un entorno de chat simple, funciona como asistente de conversación.
- Al añadir búsquedas en la web, recuperación de información, evaluación de fuentes y verificación de citas, se convierte en un agente de investigación.
- Si se le proporciona un repositorio, un editor, una terminal y herramientas para probar resultados, se convierte en un agente de programación.
- Al conectarlo con datos de clientes, reglas empresariales, herramientas de mensajería, disparadores y pasos de aprobación, se obtiene un agente operativo.
El modelo nunca cambió. El entorno de integración sí lo hizo. Eso también explica por qué dos productos basados en el mismo modelo subyacente pueden comportarse de manera muy diferente. Uno recupera las pruebas adecuadas, elige la herramienta correcta, se recupera de ejecuciones fallidas, mantiene su contexto organizado y verifica el resultado. Otro pierde información clave, sigue utilizando la herramienta equivocada o declara victoria sin verificar. La capacidad de un producto no puede juzgarse únicamente por su modelo: el modelo determina lo que el sistema puede comprender, mientras que el entorno de integración determina lo que puede lograr.
Diferenciando las capas
A menudo la gente utiliza los términos modelo, agente y entorno de integración de manera intercambiable, aunque se trata de capas separadas.
Codex y Claude Code ilustran bien este patrón entre los agentes de programación. Cada uno combina los modelos propios del proveedor con un conjunto de herramientas que gestionan el contexto del repositorio, el acceso a archivos, las herramientas, los comandos de shell, la memoria, la ejecución, los comentarios de las pruebas y los bucles de repetición. OpenCode, Goose, Pi, Letta y AutoGPT siguen el mismo patrón que los entornos de ejecución o frameworks, y difieren en cuanto a los modelos soportados, los conjuntos de herramientas, los diseños de memoria y el grado de apertura.
El agente es el sistema completo; el modelo aporta la inteligencia, y el conjunto de herramientas regula cómo esa inteligencia interactúa con el mundo exterior.
Los pesos abiertos y el código abierto son cosas diferentes
Productos como Codex y Claude Code son agentes listos para usar en los que el modelo y la estructura de control se desarrollan y ajustan juntos por una misma empresa. Un agente de tipo “open-weight”, en cambio, combina un modelo descargable con una estructura de control existente o personalizada. Esto brinda a los desarrolladores más control sobre el despliegue, las herramientas, la memoria, la privacidad, los costos y el comportamiento. Los pesos del modelo pueden ejecutarse en su propia infraestructura y, siempre que lo permita la licencia, pueden ser ajustados con mayor precisión. Una combinación típica es Goose con un modelo de tipo “open-weight” como gpt-oss-120b, o OpenCode con un modelo Qwen o Gemma.
Un agente de código abierto es algo diferente: el código de la estructura de control es público. Cualquiera puede leer y modificar cómo se envían las instrucciones al modelo, qué herramientas ofrece, cómo almacena la memoria, cómo funcionan sus bucles, con qué sistemas se integra y cómo maneja los permisos y el contexto. OpenCode, Goose y AutoGPT son ejemplos de estructuras de control de código abierto.
Las dos propiedades son independientes:
- Un framework de código abierto aún puede llamar a un modelo propietario a través de una API. OpenCode puede manejar modelos GPT o Claude, por lo que su interfaz, lógica de control y ejecución de herramientas son abiertos, mientras que el modelo en sí es cerrado.
- Un modelo de pesos abiertos no es un agente por sí mismo. Un modelo como gpt-oss-20b puede predecir y tomar decisiones, pero no puede navegar por carpetas, ejecutar herramientas, mantener el estado de una tarea ni completar un flujo de trabajo hasta que existe un framework como Goose, OpenCode o un marco personalizado que lo rodee.
En resumen: un agente de código abierto es un framework abierto más cualquier modelo compatible, y un agente de pesos abiertos es un framework más los pesos descargables.
Por qué son importantes los ecosistemas abiertos
Varios laboratorios ahora lanzan modelos de peso abierto asequibles junto con herramientas de agente de código abierto, formando ecosistemas abiertos híbridos. Dichos lanzamientos han convertido a estos stacks abiertos en competidores serios para los agentes de codificación propietarios en ciertos benchmarks de agencia, aunque no siempre son superiores en todos los aspectos. Las evaluaciones realizadas por los propios proveedores suelen mostrar que los modelos propietarios siguen liderando en varios tests de codificación. Lo importante no es que un modelo supere a todos los demás, sino que un modelo de peso abierto asequible, combinado con un entorno de trabajo cuidadosamente diseñado, pueda competir con sistemas cerrados costosos.
Qué contiene un buen entorno de trabajo
El rendimiento proviene de la combinación del modelo y del entorno de trabajo, y este último está formado por varias partes:
- Selección de contexto. Elegir qué se incluye en cada llamada al modelo para que esté presente el archivo, registro o documento relevante y no el ruido.
Elegencias de diseño que dan forma a un sistema
Cada framework toma decisiones que, de forma silenciosa, establecen un límite a lo que puede hacer el agente, y algunos merecen atención desde el principio.
Cuántas herramientas, y cómo están descritas. Proporcionar a un modelo veinte herramientas superpuestas suele ser más perjudicial que darle cinco claras. Los nombres, las descripciones y la estructura de los argumentos funcionan como indicaciones, por lo que definiciones poco claras de las herramientas causan llamadas incorrectas.
Qué tanto recordar. Historias largas ocupan espacio y dificultan el acceso al contexto útil. Los frameworks suelen resumir, condensar o almacenar notas fuera de la indicación inicial y recuperarlas cuando son relevantes. Lo que se mantiene y por cuánto tiempo afecta significativamente si el agente puede mantener la coherencia en tareas prolongadas.
Dónde colocar al humano. Algunas acciones, como leer un archivo, pueden automatizarse sin problemas. Otras, como eliminar datos o enviar dinero, requieren un paso de aprobación. Establecer esas reglas corresponde a la decisión del operador y no al modelo.
Qué se considera completado. Un bucle necesita una regla de detención, como superar pruebas, obtener una respuesta verificada o cumplir con un presupuesto de pasos. Sin ella, el agente o bien se detiene temprano o continúa funcionando.
Una forma práctica de comenzar
Si está creando un agente, comience con el conjunto más simple que pueda completar una tarea real de principio a fin: un modelo, dos o tres herramientas, un bucle con límite de pasos y una definición escrita de qué constituye el éxito. Luego recoja de diez a veinte tareas reales, ejecútelas, analice los registros y resuelva primero los fallos más comunes. El cambio de modelo se hará más adelante, una vez que se sepa que el conjunto de herramientas no es el factor limitante. Este orden evita que culpe al modelo por problemas que en realidad se encuentran en las herramientas que lo rodean.
Cómo funciona el acceso a archivos
Un modelo no puede acceder directamente a los archivos de una computadora. El conjunto de herramientas proporciona funcionalidades controladas que permiten listar directorios, buscar nombres de archivos, obtener contenido relevante, abrir y editar archivos, ejecutar código y guardar resultados. El modelo elige qué información o acción necesita a continuación. El conjunto de herramientas valida y ejecuta esa solicitud, devuelve el resultado y lo agrega al contexto. Este proceso se repite hasta que el modelo decide que la tarea está completada:
El modelo solicita una acción, el conjunto de herramientas la ejecuta, se devuelve el resultado y el modelo elige la siguiente acción.
Por ejemplo, si se le pide que corrija una prueba fallida, el modelo podría solicitar un listado de directorios, luego pedir que se abra el archivo de la prueba y el módulo a probar, proponer una edición y solicitar ejecutar la prueba. En cada paso, el conjunto de herramientas decide si la solicitud está permitida, la ejecuta e informa sobre lo que ocurrió.
El entorno de evaluación es igual de importante
Construir un entorno para un agente es solo la mitad del trabajo. La otra mitad es un entorno de evaluación que demuestra si el agente funciona. Este prueba, en condiciones similares a las reales, si el sistema completo puede elegir las herramientas adecuadas, recuperarse de fallos, mantener los costos bajo control, seguir las reglas de seguridad y completar las tareas de manera consistente. Eso es más que simplemente superar una prueba de referencia aislada.
Un entorno para un agente tiene muchas partes interconectadas, y cada una puede ser un lugar donde se pueda ocultar una regresión: instrucciones, reglas de contexto, herramientas, políticas de memoria, bucles de planificación, verificación, permisos y mecanismos de recuperación. Sin un conjunto de evaluación, un equipo no puede saber si cambiar uno de estos elementos ayudó o introdujo silenciosamente un nuevo fallo. Por lo tanto, los dos entornos forman un ciclo de retroalimentación:
- Recolectar tareas representativas, incluyendo flujos de trabajo realistas, casos difíciles y fallas ya observadas.
- Ejecutar el sistema completo, el modelo actual y el mecanismo de integración juntos.
- Inspeccionar los resultados: éxitos, registros de ejecución, llamadas a herramientas, errores, costos y latencia.
- Cambiar un componente, ya sea una instrucción de entrada, una herramienta, un modelo, una política de memoria, un bucle o una regla de enrutamiento.
- Ejecutar nuevamente las evaluaciones en tareas no utilizadas y casos de regresión.
- Mantener solo los cambios que mejoren de manera verificable el equilibrio necesario entre precisión, fiabilidad, seguridad, velocidad y costo.
En resumen: construir, evaluar, detectar fallas, mejorar el mecanismo de integración y volver a evaluar.
Leer un registro de ejecución
La evaluación es más sencilla cuando se puede leer lo que realmente hizo el agente. Un registro útil anota cada llamada al modelo, la herramienta solicitada, los argumentos, el resultado devuelto, los tokens utilizados y el tiempo empleado. Cuando una tarea falla, examine el registro en busca del primer paso incorrecto y no del último. Con frecuencia, la causa raíz se encuentra temprano: un archivo faltante en el contexto, una descripción vaga de la herramienta o una suposición errónea que se hereda en todos los pasos posteriores. Corregir ese único punto suele solucionar toda una serie de fallos, y por eso la revisión de los registros es uno de los hábitos más productivos que puede adoptar un equipo.
¿Todavía importa el modelo?
Sí. Los modelos más recientes siguen mejorando en razonamiento, programación, seguimiento de instrucciones, precisión al usar herramientas, capacidad de contexto, velocidad, eficiencia en costos y habilidades multimodales, y un framework no puede crear de manera fiable una capacidad que el modelo carezca. Pero el modelo ya no es el producto completo.
Cuando varios modelos son lo suficientemente buenos para una tarea, el framework puede explicar la mayor parte de la diferencia restante entre los productos. La recuperación que encuentra el archivo adecuado, las herramientas cuyas acciones son obvias, el manejo de estados que recuerda el trabajo completado, la verificación que detecta ediciones defectuosas, los permisos que evitan pasos peligrosos y la recuperación que permite superar fallos, todo esto suma importancia.
Eso sugiere una división simple del trabajo, que también sirve como lista de verificación útil para revisar cualquier proyecto de agente. Pregunte qué puede hacer razonablemente el modelo, qué debe añadir la estructura de soporte para que esa capacidad se manifieste de manera fiable, y qué evidencia proporcionan las evaluaciones de que así fue.
- El modelo define el límite máximo de lo que puede hacer el sistema.
- La estructura de soporte convierte ese límite en resultados fiables y reproducibles.
- La evaluación confirma si el sistema final realmente cumplió con lo esperado, lo cual es una cuestión distinta a si el modelo es inteligente.
Por eso tanto la ingeniería de aplicaciones se centra ahora en las estructuras de soporte y las evaluaciones. Es allí donde un equipo construye una ventaja duradera, a través de contextos privados, herramientas más seguras, flujos de trabajo específicos del dominio, gestión de la memoria, recuperación de errores y experiencia de usuario.
La respuesta a la pregunta central
¿Puede un modelo convertirse en un agente verdadero y funcional sin un soporte? No. Un modelo por sí solo carece del entorno necesario para ejecutar acciones, acceder a sistemas externos, recordar los pasos completados, observar el efecto de sus decisiones y seguir trabajando hacia un objetivo. El modelo es el cerebro y el motor de razonamiento. El soporte son el cuerpo, las herramientas, la memoria, los bucles de retroalimentación, los permisos y las restricciones que convierten las predicciones en acciones controladas.
O en una sola frase: un agente de IA es un modelo de IA más un soporte.