El reto ya no consiste solamente en conseguir que los agentes sean más inteligentes, sino en construir el entorno adecuado para que puedan utilizar su inteligencia de forma efectiva.
El concepto clave es la Autonomía Estructurada, y está muy relacionado con ideas como Contexto Vivo, Software Adaptativo, memoria persistente y composición dinámica de habilidades, de las que ya hemos hablado en economiable.
La Autonomía Estructurada se consigue mediante una infraestructura que rodea a un modelo de inteligencia artificial y le permite trabajar. La ingeniería dedicada a construir esa infraestructura es lo que denominaremos Estructuración de la Autonomía de los agentes, conocida en inglés como Harness Engineering.
Imagina que tienes un modelo muy potente, como GPT, Claude o Gemini. El modelo puede razonar, interpretar instrucciones, planificar y decidir qué hacer, pero eso no significa que pueda ejecutar correctamente cualquier tarea en una organización.
Necesita un entorno que le permita conocer la situación, acceder a información, utilizar herramientas, recordar decisiones, comprobar resultados y corregir errores.
El modelo puede decidir cómo abordar un problema, con qué herramientas, en qué orden y qué comprobaciones necesita realizar, dentro de unos límites definidos. No se trata de darle libertad absoluta, sino de proporcionarle capacidades reales para actuar con autonomía controlada.
La diferencia fundamental es que dejamos de intentar programar cada comportamiento y empezamos a diseñar las condiciones que permiten que el comportamiento adecuado emerja del razonamiento del modelo.
Las partes de la Autonomía Estructurada
Para entenderlo, podemos imaginar que estamos desarrollando una aplicación que ayuda a una empresa de distribución de productos a gestionar su actividad. La aplicación debe analizar existencias, prever necesidades de reposición, evaluar proveedores, supervisar pedidos, identificar riesgos de desabastecimiento y proponer actuaciones.
En un software tradicional programaríamos distintos procedimientos para resolver cada necesidad. Con un modelo de razonamiento y una infraestructura de Autonomía Estructurada adecuada podemos construir un sistema capaz de abordar problemas diferentes utilizando una infraestructura común.
Veamos sus componentes fundamentales.
1. Contexto y conocimiento: saber qué está ocurriendo
El primer componente permite que el modelo disponga de la información necesaria para interpretar la situación.
Un modelo puede saber mucho sobre distribución y logística, pero desconoce qué productos tenemos disponibles, cuáles son nuestros principales clientes, qué pedidos están pendientes, cuáles son las condiciones de nuestros proveedores o qué criterios utilizamos para gestionar las existencias.
La infraestructura debe facilitarle ese conocimiento, seleccionando la información pertinente para cada tarea, evitando datos obsoletos y respetando los permisos de acceso.
Ejemplo. Preguntamos: «¿Podemos atender un pedido de 2.000 unidades de este producto para la próxima semana?».
El sistema proporciona al modelo las existencias disponibles en los distintos almacenes, las unidades comprometidas en otros pedidos, las entregas previstas de proveedores, los plazos de transporte y las condiciones comerciales del cliente.
Lo importante es que no necesita entregarle permanentemente toda la información de la organización. El sistema debe poder identificar y recuperar la que resulte relevante para ese problema.
Así, el modelo no razona sobre una situación imaginaria o genérica, sino sobre una realidad empresarial concreta.
2. Memoria y estado: mantener la continuidad del trabajo
El segundo componente permite que el modelo no tenga que empezar desde cero cada vez que interviene.
Aquí debemos distinguir dos cuestiones. El estado describe en qué punto se encuentra una tarea. La memoria conserva información que puede ser útil posteriormente.
Ejemplo. El sistema está realizando un análisis de diez referencias de productos con riesgo de desabastecimiento. Ya ha revisado seis, ha detectado tres posibles incidencias y está esperando confirmación de entrega de dos proveedores.
Si la ejecución se interrumpe, la infraestructura debe conservar ese estado para que el modelo pueda continuar sin repetir todo el trabajo.
Pero también puede recuperar una decisión tomada meses atrás: «Decidimos reducir los pedidos a este proveedor porque incumplía sistemáticamente los plazos de entrega».
Esa información histórica puede resultar útil cuando volvemos a estudiar la posibilidad de realizarle un pedido importante.
La continuidad no depende de que el modelo mantenga indefinidamente una conversación en su ventana de contexto. Depende de una infraestructura que conserva y recupera el conocimiento y el estado necesarios.
3. Herramientas y APIs: disponer de capacidades para actuar
Un modelo puede razonar sobre un problema, pero necesita herramientas para consultar datos, efectuar cálculos, modificar registros, generar documentos o interactuar con otros sistemas.
La infraestructura de Autonomía Estructurada pone esas herramientas a su disposición y establece cómo pueden utilizarse.
Ejemplo. Para determinar cómo atender un pedido, el modelo puede necesitar consultar el ERP, obtener las existencias de distintos almacenes, comprobar los pedidos pendientes, calcular costes de transporte, consultar los plazos de los proveedores, analizar un Excel con previsiones de ventas y generar una propuesta de suministro.
En lugar de programar una secuencia fija para todos los análisis, podemos ofrecerle herramientas especializadas y permitir que elija cuáles necesita.
Una herramienta puede limitarse a devolver las existencias disponibles. Otra puede calcular necesidades de reposición. Otra puede preparar una propuesta de pedido de compra. Otra puede generar un gráfico con la evolución de las ventas.
La inteligencia del modelo se combina así con capacidades de ejecución que no tiene por sí mismo.
El modelo no necesita saber hacerlo todo internamente. Necesita saber qué capacidades tiene disponibles, cuándo utilizarlas y cómo interpretar sus resultados.
4. Bucle de ejecución: razonar, actuar, observar y corregir
Una de las partes más importantes de la Autonomía Estructurada es el mecanismo que permite al modelo trabajar en varios pasos.
No basta con formular una pregunta y obtener una respuesta. Muchas tareas requieren una secuencia de decisiones, consultas y actuaciones.
La infraestructura gestiona ese ciclo: el modelo analiza la situación, decide una acción, ejecuta una herramienta, recibe el resultado y determina qué debe hacer a continuación.
Ejemplo. Le pedimos que identifique los productos con mayor riesgo de desabastecimiento.
Primero consulta las existencias. Después detecta que determinadas referencias tienen niveles de inventario inferiores a los habituales. Decide consultar su evolución de ventas. Descubre que la demanda de una familia de productos ha aumentado significativamente y solicita una comparación con periodos anteriores.
Al analizarla observa que el incremento coincide con una campaña comercial de varios clientes importantes. Entonces consulta los pedidos pendientes y las fechas previstas de recepción de mercancía para determinar si podremos atender la demanda.
No habíamos programado expresamente esa secuencia.
El modelo la ha construido a partir de los resultados que iba obteniendo.
Si una herramienta falla o falta información, el sistema puede permitirle probar otra vía, solicitar información adicional o comunicar que no dispone de evidencias suficientes.
Es aquí donde la autonomía deja de consistir en ejecutar órdenes y empieza a convertirse en una capacidad de actuación.
5. Permisos y límites: autonomía controlada
Que el modelo pueda determinar cómo actuar no significa que deba poder hacer cualquier cosa.
La Autonomía Estructurada establece las reglas que delimitan su actuación: qué información puede consultar, qué herramientas puede utilizar, qué operaciones están permitidas y cuáles requieren autorización.
Ejemplo. El modelo puede analizar necesidades de reposición, calcular cantidades óptimas de compra, comparar proveedores, proponer condiciones y preparar pedidos.
Sin embargo, no puede emitir una orden de compra de 200.000 euros ni comprometer a la empresa a realizar determinadas entregas sin la aprobación de una persona autorizada.
Incluso podemos establecer diferentes grados de autonomía. El sistema puede consultar información libremente, modificar ciertos registros bajo condiciones verificables y solicitar aprobación para cualquier operación que genere obligaciones económicas relevantes.
Estos límites deben aplicarse mediante mecanismos técnicos de autorización, no depender únicamente de que el modelo recuerde una instrucción.
La autonomía no consiste en eliminar el control, sino en permitir que el sistema decida y actúe dentro de un espacio de actuación bien definido.
6. Verificación y feedback: comprobar lo que se ha hecho
El último componente fundamental permite verificar los resultados y corregir los errores.
Los modelos de IA pueden equivocarse. Pueden utilizar una fuente desactualizada, interpretar incorrectamente las condiciones de un proveedor o cometer errores al combinar información.
Un sistema de Autonomía Estructurada incorpora mecanismos de comprobación antes de considerar terminado el trabajo.
Ejemplo. El modelo concluye que tenemos 1.800 unidades disponibles de un producto y que podemos atender un pedido de 1.500 unidades.
Antes de presentar el resultado, una función convencional recalcula la disponibilidad real utilizando las existencias registradas, las unidades reservadas, la mercancía en tránsito y los posibles bloqueos de inventario.
Si el cálculo no coincide, el sistema comunica la discrepancia al modelo, que debe revisar los datos y corregir su análisis.
En otro caso, puede verificar que los precios utilizados corresponden a tarifas vigentes, que los proveedores pueden cumplir los plazos previstos o que la propuesta final utiliza las referencias correctas.
También debe registrar las consultas realizadas, las herramientas ejecutadas y las verificaciones efectuadas para facilitar la trazabilidad y la supervisión humana.
La idea es especialmente importante: no construimos solamente mecanismos para que el modelo haga cosas, sino también para que pueda comprobar si las ha hecho correctamente.
Del software tradicional al Model First
Con los modelos de razonamiento estamos empezando a poder construir sistemas donde no es necesario anticipar todas las respuestas.
Podemos definir el entorno, aportar conocimiento, habilitar capacidades, establecer restricciones y dejar que el modelo determine buena parte del procedimiento.
Pasamos al enfoque Model First.
Significa diseñar el sistema a partir de las capacidades del modelo, en lugar de tratarlo como un componente al que obligamos a seguir un procedimiento completamente predefinido.
En la práctica supone cambiar algunas preguntas.
Enfoque tradicionalEnfoque Model First¿Qué pasos debe ejecutar el agente?¿Qué objetivo debe alcanzar?¿Qué instrucciones debo darle?¿Qué información necesita?¿Cómo programo el flujo?¿Qué herramientas debe poder elegir?¿Cómo evito que se equivoque con más prompts?¿Cómo puede verificar y corregir sus errores?¿Cómo construyo más agentes?¿Cómo aumento las capacidades del sistema?
Hay un matiz fundamental: esto no significa eliminar la programación convencional. Los cálculos, permisos u operaciones críticas deben seguir sujetos a mecanismos deterministas y verificables.
La IA decide donde aporta valor el razonamiento; el software convencional garantiza lo que debe cumplirse siempre.
Autonomía Estructurada, Contexto Vivo, semántica, memoria y composición dinámica de habilidades
Aquí aparece una conexión especialmente interesante con los conceptos que hemos venido desarrollando.
La Estructuración de la Autonomía de los agentes puede entenderse como una disciplina de ingeniería necesaria para hacerlos realidad.
La infraestructura de Autonomía Estructurada coordina y controla la ejecución. Pero podemos enriquecer ese entorno con sistemas que proporcionen información dinámica, conocimiento estructurado, memoria duradera y capacidades combinables.
Veamos cómo se relacionan.
1. Contexto Vivo: conocer la situación en cada momento
El Contexto Vivo proporciona al modelo la información relevante y actualizada que necesita para comprender una situación concreta.
La diferencia con un sistema que simplemente almacena documentos o proporciona información estática es importante.
No se trata únicamente de que la IA conozca nuestra empresa, sino de que sepa qué está ocurriendo en ella cuando debe tomar una decisión.
Volvamos a nuestro sistema de distribución.
Por la mañana, el modelo puede considerar razonable aceptar un pedido de 2.000 unidades de un determinado producto. La empresa dispone de existencias suficientes y puede cumplir los plazos de entrega.
Sin embargo, durante el día se produce una circunstancia nueva: uno de nuestros principales clientes realiza un pedido urgente de 1.500 unidades del mismo producto.
Cuando volvemos a preguntar si podemos aceptar el primer pedido, el sistema ya no debería responder utilizando exclusivamente el análisis anterior.
El Contexto Vivo debe permitirle incorporar ese nuevo compromiso de suministro, revisar las existencias disponibles y reconsiderar sus conclusiones.
También puede incorporar información sobre quién formula la consulta, qué decisión se está preparando, qué restricciones son aplicables y qué información se ha modificado desde el último análisis.
Esto no significa cargar continuamente toda la información disponible en el modelo. Significa construir mecanismos capaces de detectar, seleccionar y actualizar el contexto pertinente.
El contexto deja de ser un conjunto de documentos que acompañan a una consulta y se convierte en una representación dinámica de la situación en la que el sistema debe actuar.
2. Ontologías y Knowledge Graphs: comprender qué significa cada cosa y cómo se relaciona
Disponer de mucha información no significa comprender adecuadamente su significado.
Una empresa puede almacenar miles de documentos, contratos, registros comerciales y operaciones, pero los datos no siempre explican por sí solos qué representan ni cómo se relacionan.
Aquí intervienen las ontologías y los grafos de conocimiento.
Una ontología define los conceptos relevantes de un dominio, sus propiedades y las relaciones que pueden existir entre ellos.
Un Knowledge Graph representa entidades concretas y sus relaciones utilizando esa estructura semántica.
Por ejemplo, en nuestro sistema de distribución podemos definir conceptos como producto, referencia, fabricante, proveedor, cliente, almacén, pedido, familia de productos, equivalencia o condición comercial.
También definimos relaciones: un producto pertenece a una familia, un fabricante produce determinadas referencias, varios proveedores pueden suministrar un mismo producto, dos referencias pueden ser equivalentes o un cliente utiliza determinados productos en sus procesos.
Después, el grafo conecta los elementos reales de nuestro catálogo, nuestros proveedores y nuestros clientes utilizando esas relaciones.
Ejemplo. Preguntamos: «¿Qué alternativas tenemos para atender los pedidos de un producto que nuestro proveedor habitual no puede suministrar?».
Un sistema convencional podría buscar otros proveedores que vendan exactamente la misma referencia.
Pero una ontología y un grafo de conocimiento pueden permitir identificar relaciones más complejas.
El producto puede tener referencias equivalentes de otros fabricantes. Algunas pueden sustituirlo directamente y otras solamente ser compatibles bajo determinadas condiciones. Puede que uno de los proveedores habituales no comercialice la referencia original, pero sí una alternativa válida.
Además, esas referencias pueden encontrarse clasificadas en familias comerciales distintas o utilizar denominaciones diferentes según el fabricante.
El modelo puede identificar esas alternativas si el grafo contiene las relaciones y los datos necesarios.
El resultado es una comprensión del negocio que va más allá de consultar registros aislados.
Esto tiene implicaciones especialmente importantes para la composición de capacidades. Si el sistema comprende que dos referencias son equivalentes, que una está disponible en otro almacén y que el cliente admite esa sustitución, puede utilizar esas relaciones para determinar cómo atender el pedido.
La semántica no solamente ayuda a encontrar información. Ayuda a interpretar el significado de esa información y las relaciones que pueden justificar una actuación.
3. Memoria persistente: aprovechar lo que el sistema ha aprendido de su experiencia
La memoria persistente permite recuperar experiencias, decisiones, resultados y criterios anteriores para utilizarlos en nuevas situaciones.
No debemos confundirla con guardar todas las conversaciones indefinidamente.
Un sistema con memoria útil debe poder identificar qué información merece conservarse, relacionarla con los asuntos correspondientes, recuperarla cuando resulte pertinente y actualizarla si deja de ser válida.
Ejemplo. Hace seis meses estudiamos ampliar las compras a un determinado proveedor. Tras analizarlo, decidimos no hacerlo porque sus incumplimientos en los plazos de entrega estaban provocando problemas a nuestros clientes.
Esa decisión quedó registrada junto con sus razones y los datos utilizados.
Ahora el mismo proveedor presenta una nueva oferta con condiciones comerciales muy atractivas.
El modelo recupera la evaluación anterior y comprueba qué ha cambiado. Descubre que el proveedor ha reorganizado su sistema logístico y que sus indicadores de puntualidad han mejorado considerablemente durante los últimos meses.
La memoria le permite comprender qué preocupaba anteriormente y comprobar si el problema se ha resuelto.
No tiene que repetir todo el razonamiento desde cero, pero tampoco debe considerar inmutable la decisión pasada.
Podemos ir más lejos.
Imaginemos que, después de analizar numerosas operaciones, observamos que determinadas familias de productos experimentan incrementos de demanda cuando se producen ciertas circunstancias comerciales o estacionales.
El sistema puede conservar esa observación como antecedente y utilizarla para sugerir comprobaciones adicionales en futuras decisiones de aprovisionamiento. No debería convertirla automáticamente en una regla general sin evidencia suficiente.
Así, la memoria no sirve únicamente para recordar hechos. También puede conservar experiencias operativas, criterios utilizados, resultados obtenidos y explicaciones sobre decisiones anteriores.
La memoria proporciona continuidad al razonamiento y permite utilizar experiencias anteriores sin quedar atrapado en ellas.
4. Composición dinámica de habilidades: determinar qué capacidades utilizar en cada situación
La composición dinámica de habilidades permite seleccionar y combinar las capacidades necesarias para resolver un problema sin tener que establecer previamente todas las secuencias posibles.
Una habilidad puede incluir instrucciones especializadas, herramientas, procedimientos, código ejecutable y criterios de comprobación.
Por ejemplo, nuestro sistema de distribución puede disponer de habilidades para analizar ventas, calcular necesidades de reposición, comparar proveedores, consultar productos equivalentes, evaluar márgenes comerciales, optimizar existencias, planificar entregas y generar informes.
En el software tradicional diseñaríamos un flujo de trabajo para cada necesidad: uno para realizar pedidos de compra, otro para revisar existencias y otro para preparar ofertas comerciales.
Con composición dinámica, el modelo puede determinar qué habilidades necesita y cómo combinarlas para alcanzar un objetivo.
Ejemplo. Preguntamos: «¿Deberíamos aumentar las existencias de esta familia de productos?».
El modelo comienza recuperando la información de ventas y existencias. Detecta que la demanda ha crecido rápidamente, pero también que algunos productos presentan una rotación muy inferior a otros.
Selecciona una habilidad de previsión de demanda para evaluar la evolución esperada. Después utiliza otra de gestión de inventarios para determinar qué cantidades sería razonable mantener.
Al consultar las condiciones de nuestros proveedores, comprueba que algunos ofrecen descuentos importantes por volumen, mientras que otros permiten realizar pedidos más frecuentes con plazos de entrega reducidos. Por ello, incorpora una habilidad de análisis de aprovisionamiento.
Finalmente, utiliza una herramienta de simulación para evaluar cómo afectarían las distintas opciones a nuestros costes, márgenes y necesidades de almacenamiento, y una habilidad de generación de informes para presentar una propuesta razonada.
Pero supongamos que descubre que varios productos de esa familia tienen referencias equivalentes que ya mantenemos en nuestros almacenes.
El modelo puede detectar esa circunstancia e incorporar una habilidad de análisis de equivalencias que inicialmente no había considerado necesaria.
No hemos tenido que programar expresamente esta combinación.
El modelo construye un procedimiento utilizando las habilidades disponibles en función de las necesidades que descubre durante el trabajo.
Esto es especialmente relevante porque permite ampliar las capacidades de una aplicación incorporando nuevas habilidades, sin tener que reconstruir todos sus flujos de funcionamiento.
Si mañana desarrollamos una nueva habilidad capaz de optimizar la distribución de existencias entre almacenes, el sistema puede incorporarla a aquellos procesos donde resulte útil.
Naturalmente, determinadas actividades continuarán requiriendo secuencias obligatorias, validaciones previas o autorizaciones humanas. La composición dinámica no elimina esas restricciones: opera dentro de ellas.
De coordinar agentes a construir sistemas adaptativos
La infraestructura de Autonomía Estructurada conecta y coordina estas capacidades, pero no las sustituye.
Puede funcionar sin ontologías, sin grafos de conocimiento o sin memoria persistente avanzada. Sin embargo, incorporar estas capacidades puede aumentar sustancialmente su utilidad en entornos empresariales complejos.
También conviene distinguir sus funciones.
El contexto informa sobre la situación actual. La semántica aporta una interpretación estructurada del negocio. La memoria conserva antecedentes relevantes. Las habilidades proporcionan capacidades de actuación. Y la infraestructura de Autonomía Estructurada organiza su utilización, gestiona el proceso y establece mecanismos de control y verificación.
Podemos sintetizarlo de esta manera:
La semántica permite comprender; el contexto permite situarse; la memoria permite mantener continuidad; las habilidades permiten actuar; y la Autonomía Estructurada permite coordinar y verificar esa actuación.
La combinación de todas estas capacidades nos aproxima a lo que hemos denominado Software Adaptativo.
Un sistema que no se limita a ejecutar procedimientos previamente establecidos, sino que puede adaptar su funcionamiento a las circunstancias, seleccionar capacidades diferentes y construir procedimientos adecuados para necesidades que no se habían anticipado expresamente.
Volvamos por última vez al ejemplo de la distribución.
Una aplicación tradicional puede disponer de una función para consultar existencias, otra para analizar ventas y otra para generar pedidos de compra.
El usuario debe saber qué función necesita utilizar, introducir la información adecuada e interpretar los resultados.
En un sistema adaptativo, el usuario puede plantear directamente su necesidad: «Quiero saber qué productos deberíamos reponer esta semana y por qué».
El modelo, apoyado en su infraestructura de Autonomía Estructurada, puede recuperar información actualizada, identificar las relaciones entre productos y proveedores, recordar decisiones anteriores, seleccionar habilidades de análisis y construir una propuesta.
Si encuentra un problema de suministro, puede buscar referencias equivalentes. Si detecta una demanda excepcional, puede realizar simulaciones de inventario. Si necesita información que no está disponible, puede solicitarla.
La aplicación no se limita a ofrecer un conjunto de funciones. Es capaz de decidir qué funciones utilizar y cómo combinarlas para responder a una necesidad concreta.
De programar comportamientos a diseñar capacidades
Durante décadas hemos construido software intentando anticipar las situaciones y programar las respuestas adecuadas.
Con los modelos de razonamiento estamos empezando a poder construir sistemas donde no es necesario anticipar todas las respuestas. Podemos definir el entorno, aportar conocimiento, habilitar capacidades, establecer restricciones y dejar que el modelo determine buena parte del procedimiento.
Esto desplaza el esfuerzo de programación.
De programar comportamientos a diseñar capacidades y condiciones de actuación.
Y es especialmente relevante para la composición dinámica de habilidades: si el modelo dispone de una buena infraestructura de Autonomía Estructurada, no necesita que diseñemos previamente cada secuencia posible de herramientas. Puede construir una secuencia distinta para cada necesidad.
Esto no significa que desaparezcan los errores ni que debamos confiar ciegamente en la autonomía de los modelos. Una Autonomía Estructurada bien diseñada aumenta las posibilidades de obtener resultados fiables, permite detectar fallos y facilita su corrección, pero no garantiza que todos los razonamientos sean correctos.
La ingeniería convencional sigue siendo imprescindible. Lo que cambia es dónde se concentra una parte creciente del esfuerzo.
En lugar de invertirlo exclusivamente en desarrollar más procedimientos y programar más excepciones, podemos dedicarlo a construir mejores representaciones del conocimiento, ofrecer nuevas capacidades, facilitar la memoria, establecer mecanismos de control y mejorar los sistemas de verificación.
El futuro de los sistemas de IA no depende únicamente de conseguir modelos más inteligentes, sino de diseñar entornos donde esa inteligencia pueda convertirse en acciones útiles, verificables y adaptadas a cada situación.
Pasar de sistemas que ejecutan procedimientos que hemos previsto —software tradicional— a sistemas capaces de determinar cómo actuar ante situaciones que no hemos previsto expresamente —software adaptativo—.
Ese es, probablemente, uno de los cambios más profundos que la inteligencia artificial está introduciendo en la ingeniería del software.