¿Acortarán los modelos más inteligentes el alcance de los agentes o harán que sea aún más importante?

Hace unos años, mejorar una función de IA significaba principalmente mejorar el modelo: elegir uno más potente, ajustarlo con precisión, alimentarlo con datos más limpios y exponerlo a través de una API. Hoy en día, un sistema en producción basado en un modelo puede incluir funciones de recuperación de información, memoria, herramientas, planificación, evaluación, capacidad de observabilidad, medidas de seguridad, intentos repetidos, gestión de contexto y varios agentes que colaboran entre sí. El término general para esa capa de soporte es el “arness”. Esto plantea una pregunta práctica para quienes deciden dónde invertir tiempo en ingeniería: si los modelos siguen mejorando, ¿esta capa se volverá menos importante o será la parte más crucial del sistema? Este artículo analiza ambos puntos de vista y termina con una forma de determinar qué partes de su propio “arness” es probable que disminuyan y cuáles crecerán.

Qué es el “arness” y qué no es

Un harness es el software que rodea a un modelo y que le permite completar una tarea de manera fiable. El modelo proporciona el razonamiento; el harness crea las condiciones en las que dicho razonamiento genera resultados útiles. En la práctica, agrupa varias funciones: acceso a herramientas y APIs; recuperación de datos, contexto y memoria; división del trabajo en pasos planificados y seguimiento del estado; verificación de resultados, retroalimentación de errores y reintentos; aplicación de permisos y restricciones; y medición y observación de lo que ocurre.

El punto importante es que un framework no intenta hacer que el modelo sea más inteligente. Su objetivo es crear un sistema que sea más capaz, más fiable y más seguro en su conjunto. Considere el caso de texto a SQL: un modelo ya puede saber cómo escribir una consulta. El framework le proporciona el esquema, le permite inspeccionar los metadatos de las tablas, ejecuta la consulta, captura errores, devuelve el resultado o el mensaje de error, activa un intento de repetición cuando es necesario y ayuda a determinar si la respuesta final es lo suficientemente buena. El modelo razona; el framework proporciona el ciclo que rodea ese razonamiento. Ese ciclo es de suma importancia una vez que el modelo hace algo más que generar texto.

Para conocer más a fondo cómo se distribuyen las responsabilidades entre el modelo y el soporte en un único agente, consulte de dónde proviene realmente el comportamiento fiable de la IA. El enfoque aquí es cómo cambia esa distribución con el tiempo.

El argumento a favor de un soporte más simple

Es completamente razonable esperar que los modelos mejores necesiten menos estructura de apoyo. Imagine un modelo que realice de manera fiable todo lo siguiente:

• Sigue instrucciones complejas.
• Mantiene lo que es relevante.
• Elegirá la herramienta correcta.
• Planifica tareas con muchos pasos.
• Sé recupera cuando algo falla.
• Revisa su propio resultado.
• Reconoce cuándo está incierto.
• Mantiene un registro del estado durante tareas prolongadas.

Con un modelo así, gran parte de la orquestación actual parece redundante. Un razonamiento más sólido reduce la necesidad de capas de planificación explícitas. Un uso mejor de las herramientas nativas disminuye la lógica manual para seleccionar herramientas. Un manejo más eficaz de contextos extensos reduce la necesidad de sistemas de memoria complejos. Una autoevaluación fiable disminuye la necesidad de pipelines de validación externa.

Esto podría ocurrir realmente, y ya está sucediendo en algunos casos: los trucos con prompts y las soluciones de análisis que eran esenciales para los modelos anteriores a menudo son innecesarios ahora. Es plausible que las mejores soluciones del futuro sean mucho más simples que muchas de las creadas hoy. Sin embargo, eso es solo la mitad de la historia.

La capacidad amplía el alcance

Cuando un modelo se vuelve mucho más capaz, los equipos rara vez utilizan esa capacidad solo para hacer el mismo trabajo de forma más económica. La dirigen hacia problemas más difíciles.

• Un modelo que puede resumir un documento pronto será solicitado para analizar cien.
• Un modelo que puede escribir una sola consulta SQL será encargado de investigar una pregunta empresarial que abarca varios sistemas.
• Un modelo que puede llamar a una API recibirá todo un entorno de software.

El alcance crece con la capacidad, y eso cambia la función del sistema que lo utiliza. La pregunta pasa de si el modelo puede responder a una solicitud a si el sistema permite que el modelo persiga un objetivo de manera segura y fiable. Se trata de problemas de ingeniería diferentes: el primero se refiere a la inteligencia, mientras que el segundo concierne al control, la confianza y la rendición de cuentas.

Los agentes capaces plantean preguntas sobre los sistemas

Supongamos que a un agente cada vez más capaz se le proporciona un navegador, una base de datos, APIs internas, archivos, capacidad para ejecutar código, herramientas de mensajería y memoria a largo plazo. La inteligencia ya no es el factor limitante. Ahora hay que responder a preguntas como:

• ¿Qué acciones está permitido que realice el agente?
• ¿Qué información puede leer?
• ¿Cuándo debe solicitar aprobación?
• ¿Qué sucede cuando una herramienta falla?
• ¿Cómo se evitan los bucles y las acciones duplicadas?
• ¿Cómo puede alguien reconstruir por qué tomó una decisión específica?
• ¿Cómo se evalúa un flujo de trabajo que dura 30 minutos en lugar de generar una sola respuesta?
• ¿Qué ocurre cuando el modelo está equivocado pero seguro de ello?

Ninguno de estos problemas se resuelve con un modelo más inteligente. Un modelo más capaz puede empeorar la última pregunta, ya que los errores cometidos con fluidez y confianza son más difíciles de detectar. Se trata de problemas del sistema, y es aquí donde el framework cobra importancia en lugar de perderla.

De la orquestación al diseño del entorno

Muchos frameworks de agentes actuales se centran en la orquestación: decidir qué sucede a continuación, qué herramienta se utiliza y qué se devuelve al modelo. A medida que los modelos mejoran en su capacidad para planificar por sí mismos, esa lógica de secuenciación es la parte que con mayor probabilidad disminuirá. Lo que permanece y crece está más relacionado con el diseño del entorno. El framework define:

• Herramientas: con qué puede interactuar el agente.
• Contexto: qué información se le muestra.
• Estado: lo que recuerda entre pasos.
• Permisos: qué puede modificar.

Feedback: cómo sabe que algo salió mal.

Evaluación: cómo se mide el éxito.

Límites: cuándo debe detenerse o transferir el control a una persona.

En este enfoque, el modelo adquiere autonomía mientras que el marco de control se convierte en el límite alrededor de esa autonomía. Dejas de definir el camino que sigue el agente y comienzas a dar forma al espacio por el que se mueve.

La complejidad tiende a moverse, no a desaparecer

La ingeniería de software sigue un patrón conocido: cuando una capa se vuelve más sencilla, la complejidad generalmente se relocaliza en lugar de desaparecer. Las abstracciones ocultan la complejidad; no la eliminan. Las bases de datos gestionadas no suprimieron la necesidad de comprender los índices, y las plataformas en la nube no eliminaron la necesidad de planificar la capacidad.

Es probable que los agentes sigan el mismo camino. Los modelos más avanzados podrían hacer innecesaria parte de la lógica de los agentes desarrollada manualmente, al tiempo que aumentan la demanda de una evaluación más sólida, mayor seguridad, mejor capacidad de observabilidad, gestión de la memoria, control de costos, ingeniería de fiabilidad y soporte para tareas que se ejecutan durante mucho tiempo. Este mecanismo podría volverse menos visible para los desarrolladores de aplicaciones, quizás porque los proveedores y frameworks se encargan de él, al tiempo que adquiere un papel más central en el funcionamiento del sistema. Una experiencia de desarrollo más sencilla no implica necesariamente una arquitectura más simple en su base.

La respuesta honesta es que no se trata de uno u otro. El framework pierde importancia como lugar para compensar manualmente a los modelos débiles. Gana importancia como la base que permite a los modelos capaces funcionar en el mundo real sin volverse inseguros, poco fiables o desperdiciadores. Los frameworks futuros podrían contar con una orquestación menos rígida y una evaluación, permisos, estado, retroalimentación, observabilidad y control ambiental considerablemente más sofisticados.

Una progresión aproximada sería la siguiente:

• Antes: el modelo estaba conectado casi directamente a la aplicación.
• Ahora: el modelo pasa por prompts, RAG, herramientas, agentes y evaluaciones antes de llegar a la aplicación.
• Próximamente: el modelo y el framework juntos formarán un sistema autónomo.

El paso final es el que realmente importa. Una vez que la IA pasa de generar respuestas a tomar acciones, la pregunta clave ya no es solo cuán inteligente es el modelo, sino qué tan bien está diseñado el entorno que lo rodea.

Una prueba práctica para su propio sistema

Para decidir dónde invertir, clasifique cada componente del sistema en uno de dos grupos:

• Existen partes compensatorias porque el modelo actual es deficiente en algo: planificadores rígidos paso a paso, lógica compleja de análisis y reparación de resultados, enrutamiento de herramientas basado en palabras clave, soluciones temporales para los prompts. Manténgalas simples y fáciles de eliminar, y vuelva a probarlas cada vez que actualice los modelos, ya que es muy probable que se conviertan en una carga innecesaria.

Existen componentes duraderos porque la tarea tiene consecuencias en el mundo real: permisos y aislamiento, controles de aprobación, registros de auditoría y seguimiento, límites de costo y bucles, conjuntos de evaluación y persistencia del estado. Invierta adecuadamente en ellos, ya que un modelo más capaz aumenta en lugar de disminuir su valor.

Una señal útil es preguntarse si un componente seguiría siendo necesario si el modelo fuera perfecto en su razonamiento. Si la respuesta es sí, como ocurre con el control de acceso, la auditabilidad y la medición del éxito, entonces forma parte del núcleo duradero del sistema.

Puntos clave

• Un sistema de integración no hace que el modelo sea más inteligente; hace que todo el sistema sea más capaz, fiable y seguro.
• Los modelos mejores probablemente reducirán la lógica de orquestación y las soluciones temporales, y eso merece ser planificado.
• Una mayor capacidad implica un alcance más amplio, lo que plantea preguntas sobre permisos, manejo de fallos, evaluación y rendición de cuentas a las que ninguna mejora del modelo puede responder.
• El marco de trabajo está pasando de programar cada paso por separado a diseñar el entorno completo: herramientas, contexto, estado, permisos, retroalimentación, evaluación y límites.
• Esperar que la complejidad desaparezca es inadecuado; debe trasladarse a la infraestructura, y las partes duraderas de su marco de trabajo deben construirse teniendo eso en cuenta.

Lecturas relacionadas

• Agente = Modelo + Marco de trabajo: De dónde proviene realmente el comportamiento fiable de la IA — Aprenda qué es un marco de trabajo para agentes de IA, por qué el estado, la autoridad y la verificación deben quedar fuera del modelo, y qué elementos serán menos relevantes a medida que los modelos mejoren.
• Interfaz de Chat o Bucle de Agente: Cómo decidir qué necesita tu función de IA — Aprende a distinguir entre un chatbot conversacional y un agente orientado a objetivos, qué aporta el bucle de agente y cómo determinar cuál es realmente necesario para tu función de IA.
• Más allá de la caja de chat: Arquitectura de un agente IA de WhatsApp en Google ADK — Cómo un asistente de WhatsApp en producción combina agentes especializados de Google ADK, RAG, herramientas deterministas, estado de sesión, transferencia a humanos y evaluación basada en trayectorias.