Por qué los agentes de IA fallan en producción

La demo es un entorno controlado

Una demo delimita el problema. Selecciona entradas, hace accesibles las herramientas y permite observar una secuencia de comportamiento. Es útil para explorar una capacidad y comprobar si merece seguir investigándose.

La dificultad aparece cuando las condiciones que hicieron posible esa secuencia quedan fuera de la arquitectura. En producción, las entradas pueden ser incompletas, los sistemas responden con retraso y el estado de una operación puede cambiar mientras el agente decide su siguiente paso. Otras personas y otros procesos actúan sobre el mismo entorno.

Esto introduce una exigencia distinta: el sistema debe conservar un comportamiento aceptable en condiciones variables. Necesita reconocer qué sabe, qué ha dejado de ser válido y cuándo una decisión requiere información adicional. También debe poder detenerse sin perder el trabajo realizado ni dejar sus efectos sin identificar.

La transición a producción obliga, por tanto, a hacer explícitos los supuestos. Qué dependencias deben estar disponibles. Qué información necesita estar actualizada. Qué límites de tiempo y coste son aceptables. Qué parte del trabajo puede continuar si una dependencia falla.

Un sistema capaz de completar una secuencia una vez ha demostrado una posibilidad. La confianza operativa exige entender en qué condiciones puede repetirla, cómo se comporta fuera de ellas y quién se hace cargo cuando no puede terminar. La arquitectura empieza a adquirir profundidad precisamente donde acaba el recorrido previsto.

Capacidad no es autoridad

La capacidad describe lo que un agente puede hacer. La autoridad define lo que tiene permitido hacer en una situación concreta. Confundir ambas convierte el acceso a una herramienta en una delegación de poder que quizá nadie haya decidido conceder.

El mandato de un agente necesita un objetivo, un ámbito de actuación y límites reconocibles. Debe quedar claro qué puede consultar, qué puede modificar y qué decisiones conserva una persona. Esa distinción debe existir también en las integraciones y los permisos efectivos; una instrucción escrita no sustituye a un control de acceso.

La autonomía tampoco es una propiedad uniforme. Puede ampliarse en tareas reversibles y acotarse cuando una acción compromete recursos, afecta a terceros o resulta difícil de corregir. Su alcance debería responder a las consecuencias de la decisión y a la capacidad real de supervisarla.

Introducir una aprobación humana no resuelve automáticamente esa responsabilidad. Para que la revisión tenga valor, quien decide necesita información suficiente, tiempo y autoridad. Debe entender qué está aprobando y qué efectos tendrá. De lo contrario, el sistema conserva la apariencia de supervisión mientras traslada al revisor una decisión que apenas puede evaluar.

La autoridad sigue perteneciendo a la organización que delega. Diseñar un agente implica expresar esa delegación con suficiente precisión para que pueda aplicarse, revisarse y revocarse. A medida que aumenta su capacidad, esa precisión adquiere más importancia.

El contexto tiene un responsable

Un agente trabaja con la representación del entorno que recibe. Esa representación reúne instrucciones, documentos, resultados de herramientas, historial y estado de la tarea. Su calidad condiciona qué puede interpretar y qué decisiones puede tomar.

Disponer de información no significa disponer del contexto adecuado. Un documento puede explicar una política y haber quedado desactualizado. Una conversación puede conservar una decisión que después se revocó. Un resultado correcto puede corresponder a un momento que ya no describe la operación actual.

El contexto necesita procedencia, vigencia y una jerarquía de autoridad. El sistema debe distinguir las reglas que gobiernan su comportamiento de los datos que está procesando. También necesita criterios para resolver contradicciones y reconocer cuándo la información disponible no permite continuar.

Esta responsabilidad atraviesa la tecnología y la organización. Alguien mantiene las fuentes. Alguien define qué información prevalece. Alguien decide qué cambios deben reflejarse en los sistemas y cómo se comunica una excepción. Si esas funciones quedan indefinidas, el agente hereda una ambigüedad que su capacidad de razonamiento no puede resolver por sí sola.

El paso del tiempo añade otra dificultad. En trabajos prolongados, el sistema tiene que conservar decisiones relevantes sin tratar todo el historial como igualmente válido. La memoria necesita selección y actualización: recordar una afirmación no la convierte en un hecho vigente.

Anthropic documentó un problema concreto al desarrollar su agente para SWE-bench: las rutas relativas provocaban errores cuando cambiaba el directorio de trabajo. Exigir rutas absolutas en la herramienta corrigió ese comportamiento. El detalle ilustra cuánto puede depender la ejecución de que el entorno esté representado sin ambigüedad.

Por eso, diseñar el contexto forma parte del diseño operativo. Su propósito es mantener una representación suficientemente fiable del trabajo para decidir qué hacer a continuación, con una responsabilidad identificable sobre la información que sostiene esa decisión.

Ejecutar una acción no equivale a completar el trabajo

Una herramienta puede aceptar una petición sin haber terminado de procesarla. Una operación puede ejecutarse parcialmente. Un agente puede producir una explicación coherente de su trabajo mientras el estado del sistema externo cuenta una historia distinta.

Para evaluar el resultado hay que distinguir la intención, el intento de ejecución y el efecto comprobado. El registro de lo que el agente hizo aporta evidencia, pero no sustituye a la verificación del estado que debía alcanzar.

Esto exige definir qué significa terminar. Los criterios de finalización pertenecen al proceso: qué debe haber cambiado, qué condiciones deben mantenerse y qué evidencia permite considerar el trabajo resuelto. Si esos criterios son ambiguos, el agente puede detenerse demasiado pronto o seguir actuando cuando ya debería haber terminado.

El estado de una operación también debe poder persistir más allá de una conversación. Un trabajo pendiente sigue pendiente aunque cambie la sesión, intervenga otra persona o se reinicie un componente. La continuidad depende de conservar sus decisiones y efectos de forma que el sistema pueda recuperar una situación comprensible.

La observabilidad permite examinar esa continuidad. Interesa saber qué información estaba disponible, qué acción se solicitó, qué devolvió la herramienta y qué resultado se confirmó. Registrar más datos sin relacionarlos con el trabajo puede producir abundancia de trazas y poca capacidad de diagnóstico.

La finalización necesita evidencia proporcional a las consecuencias de la operación. Cuando esa evidencia falta, la incertidumbre debe permanecer visible. Una respuesta convincente no debería cerrar un trabajo cuyo resultado sigue sin conocerse.

Las excepciones forman parte del diseño

El comportamiento de un sistema ante las excepciones forma parte de su funcionamiento normal. Las dependencias dejan de responder, los permisos cambian y algunas operaciones quedan a medio camino. La arquitectura necesita representar esas situaciones y ofrecer una salida comprensible.

No todos los fallos permiten la misma recuperación. Una interrupción temporal puede admitir un reintento. Un rechazo por permisos requiere otra decisión. Un resultado incierto obliga a averiguar qué ocurrió antes de repetir la operación. Reintentar una acción con efectos externos sin esa distinción puede duplicarlos; la idempotencia y la reconciliación de estado son mecanismos relevantes para controlar ese riesgo.

Stripe incorpora claves de idempotencia en su API para reconocer reintentos de una misma petición y evitar que repitan sus efectos, dentro de las condiciones documentadas del servicio. Una integración utilizada por un agente necesita respetar ese contrato. La capacidad del modelo para decidir un reintento no reemplaza la garantía que debe proporcionar la operación.

La recuperación tiene límites. Necesita un presupuesto de intentos, tiempo y recursos, además de condiciones de parada. Si el sistema continúa buscando una salida sin reconocer que ha agotado su margen, su autonomía puede prolongar el problema.

También debe contemplar qué hacer con los efectos parciales. Algunas acciones pueden revertirse; otras requieren una compensación o una intervención posterior. No conviene asumir que cualquier secuencia puede deshacerse de forma limpia.

Cuando el trabajo pasa a una persona, la transferencia debe conservar su contexto: qué se intentó, qué cambió, qué permanece incierto y qué decisión falta. Una excepción sin responsable, prioridad o información suficiente se convierte en trabajo abandonado entre sistemas.

La capacidad de detenerse, conservar el estado y transferir la responsabilidad es parte de una autonomía bien delimitada. Permite que el proceso continúe bajo otra forma de control sin obligar a reconstruir desde cero lo que ha sucedido.

La evaluación empieza antes del despliegue y continúa después

Evaluar un agente exige observar el sistema completo. La calidad del modelo influye en el resultado, pero también intervienen las herramientas, el contexto, la orquestación y las reglas que delimitan sus acciones. Una mejora aislada no garantiza una mejora del conjunto.

Las pruebas previas permiten definir comportamientos aceptables y comprobarlos en condiciones conocidas. El seguimiento en producción aporta información sobre el uso real y situaciones que esas pruebas no cubrieron. Ambos necesitan complementarse con revisión e interpretación humana.

El criterio de éxito debe incluir la corrección del resultado y las condiciones bajo las que se obtuvo. Importa si el sistema respetó los permisos, si reconoció sus límites y si dejó una operación en un estado recuperable. Completar más tareas a costa de actuar fuera de su mandato no representa una mejora.

También importa la carga que deja alrededor. El tiempo hasta la resolución, el coste de ejecución y la intervención humana necesaria ayudan a entender si el sistema está cumpliendo su función. Una automatización que desplaza el esfuerzo hacia revisiones continuas puede reducir el trabajo visible del agente y aumentar el de la organización.

La evaluación necesita continuidad porque el sistema cambia. Se modifican modelos, instrucciones, herramientas y fuentes de información. Cada cambio relevante requiere evidencia de que el comportamiento sigue siendo aceptable y de que no se han perdido capacidades anteriores.

Ninguna batería de pruebas elimina toda incertidumbre. Su valor consiste en hacer explícito qué se ha comprobado y con qué límites. Junto con la observación del servicio, permite sustituir impresiones generales por decisiones fundamentadas sobre qué mantener, qué corregir y qué autonomía conceder.

No todos los flujos necesitan un agente

La decisión de incorporar autonomía debe responder a la naturaleza del trabajo. Hay procesos cuyo recorrido puede definirse con reglas claras. Otros necesitan interpretar situaciones abiertas, elegir herramientas o adaptar sus pasos a información que aparece durante la ejecución.

Una arquitectura puede combinar ambos. Puede reservar al modelo la interpretación y mantener bajo lógica explícita las operaciones que requieren mayor previsibilidad. También puede permitir decisiones dinámicas dentro de un tramo acotado, sin extender esa libertad a todo el proceso.

El criterio de diseño es cuánto margen de decisión necesita el sistema para cumplir su propósito. Conceder más autonomía introduce más comportamiento que observar, evaluar y gobernar. Esa complejidad debería estar justificada por una utilidad que la organización pueda reconocer.

Antes de ampliar el papel del agente, conviene entender si el obstáculo es realmente la falta de capacidad para decidir. Una responsabilidad sin asignar, una fuente de datos que nadie mantiene o un proceso contradictorio siguen requiriendo decisiones organizativas. Automatizarlos no resuelve su indefinición.

El diseño gana solidez cuando cada componente asume una función clara y el conjunto conserva límites comprensibles. La sofisticación de la arquitectura debe estar al servicio del trabajo que necesita sostener.