Coffee & Cake: Modelos, agentes y harnesses

El modelo, el agente y todo lo que ocurre alrededor

Un producto responde preguntas. Otro revisa una carpeta, abre un registro de errores, cambia un archivo, ejecuta una prueba y vuelve atrás cuando la prueba falla. Los dos aseguran que usan el mismo modelo de lenguaje. Puede que sea verdad. El salto entre contestar y actuar no tiene por qué venir de un modelo distinto. Muchas veces viene de la forma en que ese modelo está conectado con el resto del sistema.

Para verlo con claridad conviene separar tres piezas que suelen mezclarse cuando hablamos de inteligencia artificial: el modelo, el agente y el software que coordina su trabajo. No existe una frontera aceptada por todo el sector. Hay quien llama agente a un modelo que recibe instrucciones y herramientas. Otros reservan la palabra para sistemas en los que el modelo decide cómo avanzar. Aun así, podemos construir una distinción práctica preguntando qué función cumple cada pieza.

El modelo es la parte entrenada. Recibe una entrada y produce una salida. En un modelo de lenguaje, la entrada puede reunir la petición del usuario, instrucciones, mensajes anteriores y descripciones de las herramientas disponibles. La salida puede ser un texto para la persona. También puede ser una petición estructurada que diga, en esencia: lee este archivo, busca esta expresión o ejecuta esta prueba.

Pero pedir una acción no es realizarla. Si el modelo genera una petición para consultar el registro de errores, todavía no ha consultado nada. Solo ha producido una salida con la forma adecuada. Algún programa externo tiene que entenderla, enviarla a la herramienta correcta y devolver lo que ocurra. El modelo puede elegir la puerta. No es quien gira físicamente el picaporte.

Un agente se reconoce mejor en una secuencia que en una respuesta aislada. Recibe un objetivo, elige un paso, observa el resultado y adapta lo que hace después. El mismo modelo puede ser invocado muchas veces durante un encargo. Cada observación modifica el contexto de la siguiente invocación. El agente no es una personita digital escondida dentro del modelo. Es el comportamiento orientado a un objetivo que aparece cuando las decisiones y sus consecuencias forman un ciclo.

Imagina que el formulario de contacto de una página ha dejado de enviar mensajes. El encargo es encontrar la causa y arreglarla. El modelo puede empezar solicitando el registro de errores. A partir de una línea del registro, pide abrir cierto archivo. Propone un cambio y solicita una prueba. La prueba falla. Ese fallo vuelve al modelo como información nueva, así que descarta su primera hipótesis, examina otro archivo y propone una solución diferente.

Ahí aparece el comportamiento de un agente. El camino completo no estaba escrito de antemano. Nadie sabía qué archivo contenía el fallo, cuántos intentos harían falta ni qué revelaría cada prueba. El modelo decide el siguiente paso a partir de lo que acaba de observar. Puede cambiar de herramienta, hacer una pregunta, corregir su plan o detenerse porque necesita una decisión humana.

Esto no ocurre en todos los procesos que usan modelos. Un programa puede buscar siempre en una base de datos, resumir siempre los primeros resultados y enviar siempre un correo, en ese orden. Un modelo puede intervenir en cada etapa, pero el recorrido lo fija el código. Eso es un flujo de trabajo predefinido, también llamado workflow. Si el modelo decide, según los resultados, si debe buscar otra vez, cambiar de fuente o no enviar nada, el sistema es más parecido a un agente. Hay grados de autonomía, no un interruptor mágico.

Falta alguien que mantenga ese ciclo en marcha. Hace falta una capa de coordinación que prepare el contexto, invoque al modelo, interprete sus peticiones, las dirija a las herramientas y coloque cada resultado en la siguiente invocación. En el sector, esta capa suele recibir el nombre inglés agent harness, o simplemente harness. El término no designa otra inteligencia. Designa el mecanismo que convierte una serie de llamadas separadas al modelo en un proceso de trabajo continuo.

El harness puede ocuparse además de seleccionar las instrucciones y herramientas que verá el modelo, conservar el estado de la sesión, devolver los errores de una forma comprensible, pedir una confirmación o terminar después de demasiados intentos. El alcance exacto cambia entre productos. Por eso conviene entender primero la función y no aferrarse demasiado a la etiqueta.

Tampoco todo lo que rodea al modelo forma necesariamente parte del harness. Una herramienta es la que lee de verdad el archivo. Un entorno de ejecución es el que pone en marcha la prueba. Un registro de sesión puede conservar la historia de lo ocurrido. El harness organiza el intercambio entre esos elementos y el modelo. Algunas plataformas empaquetan todo junto, pero las tareas siguen siendo distintas.

Volvamos al formulario de contacto. El modelo solicita el registro. El harness envía esa solicitud a una herramienta. La herramienta hace la lectura y devuelve el contenido. El harness añade ese contenido al contexto de la siguiente invocación. Luego coordina la apertura de un archivo, la aplicación de un cambio y la ejecución de una prueba. Si la prueba falla, su resultado recorre el camino de vuelta. El agente que ve el usuario nace de todo ese intercambio, no de una única respuesta del modelo.

Esta es también la razón por la que dos agentes con el mismo modelo pueden rendir de manera muy diferente. En uno, las herramientas están descritas con ambigüedad, el contexto se llena de información irrelevante y un resultado importante desaparece antes del siguiente paso. En otro, las herramientas tienen límites claros y los fallos regresan en una forma útil. El modelo entrenado es el mismo, pero el entorno en el que intenta trabajar no lo es.

La relación funciona en ambos sentidos. Un harness puede acumular instrucciones y atajos para compensar una dificultad concreta de un modelo. Al sustituir ese modelo por otro más capaz, esas ayudas pueden convertirse en ruido. A la vez, algunos modelos se preparan específicamente para producir ciertos formatos de petición de herramientas. Conviene analizar el modelo y el harness como capas distintas, pero no son piezas completamente independientes que siempre puedan intercambiarse sin efectos.

Con esta imagen, varias confusiones pierden fuerza. Un agente no tiene por qué ser una clase especial de modelo. Un modelo capaz de nombrar una herramienta aún no la ha utilizado. El harness no es solo una instrucción larga al principio, porque mantiene el ciclo y enlaza el modelo con el entorno. Y no hace falta reunir un equipo de agentes. Un único modelo dentro de un ciclo sencillo puede constituir un agente.

El nombre del modelo tampoco basta para describir el producto final. Sin acceso a los archivos, no puede reparar el programa. Si el sistema no conserva el resultado de la prueba, quizá repita el mismo error. Para comparar agentes hay que saber también qué herramientas tienen disponibles, cómo se organiza su contexto, cuántos intentos pueden hacer y qué información obtienen cuando algo sale mal.

Más autonomía no significa automáticamente un resultado mejor. Para una tarea estable, cuyos pasos conocemos, un flujo fijo suele ser más rápido, barato y predecible. Dejar que el modelo elija el camino aporta flexibilidad frente a las sorpresas, pero exige más invocaciones y permite que una mala suposición se arrastre durante varios pasos. El diseño sensato no es el más abierto. Es el más sencillo que todavía puede afrontar la incertidumbre real de la tarea.

La próxima vez que alguien presente un agente de inteligencia artificial, puedes hacer tres preguntas. ¿Qué modelo propone los pasos? ¿Quién decide qué ocurre después: el código, una persona o el modelo tras observar un resultado? ¿Y qué pone el harness a su disposición: qué herramientas, qué contexto, qué observaciones y qué condiciones para detenerse?

El modelo aporta la capacidad aprendida. El agente usa esa capacidad a lo largo de una secuencia para perseguir un objetivo. El harness mantiene la conexión con las herramientas y con el entorno. Separar estas tres piezas permite mirar más allá del nombre del producto y entender qué puede hacer realmente, quién toma cada decisión y dónde se convierte una petición en una acción.