Análisis: qué cambió realmente cuando los agentes de IA pasaron de la demostración a la producción
Las demostraciones de agentes de los últimos dos años fueron impresionantes y en su mayoría no se pudieron lanzar. Los despliegues que se mantuvieron comparten un pequeño conjunto de decisiones de diseño, y no son las que enfatizaron las demostraciones.
Respuesta rápida
¿Por qué funcionan las demostraciones de agentes de IA pero fallan las implementaciones en producción?
Las demos ejecutan un camino feliz corto una vez con un humano observando. La producción ejecuta miles de variaciones sin supervisión, donde las tasas de error por paso se acumulan y un alcance de permisos ilimitado convierte una decisión errónea en un incidente. Los despliegues que funcionan reducen el alcance, verifican cada paso de forma económica y controlan cada acción irreversible.
Claves
- Los despliegues exitosos de agentes son acotados: un dominio delimitado, un puñado de herramientas y una señal de éxito obvia.
- La verificación barata es el predictor más fuerte de éxito, por eso la codificación fue lo primero.
- La evaluación pasó de las impresiones a trayectorias grabadas reproducidas frente a los cambios.
- La estandarización de herramientas a través de MCP trasladó el trabajo de integración de código específico a servidores reutilizables.
Existe un arco familiar en los proyectos de agentes. Un prototipo hace algo sorprendente en la primera semana. Para la sexta semana, está produciendo sinsentidos plausibles ante entradas que nadie anticipó, y el equipo está discutiendo si añadir otro modelo o rendirse.
Los proyectos que salieron al otro lado no encontraron un mejor modelo. Cambiaron la forma del problema.
La aritmética que mata las demostraciones
Toma una tarea descompuesta en pasos, cada uno de los cuales el agente completa correctamente el 95% de las veces. Esa es una buena tasa para un paso abierto que implica juicio.
Encadena tres pasos y aproximadamente el 86% de las ejecuciones tienen éxito. Encadena veinte y alrededor de un tercio lo hacen. Encadena cincuenta y estás en el 8%.
La demostración te mostró una ejecución de una tarea de cinco pasos, y un humano reinició silenciosamente los dos intentos que salieron mal. La producción ejecuta la versión de veinte pasos diez mil veces sin que nadie la observe.
Todo lo que sigue es una respuesta a esta aritmética.
Lo que tienen en común los despliegues que funcionan
Un dominio estrecho. No "gestionar operaciones" sino "conciliar estos dos sistemas de facturación". Menos ramas, menos herramientas, menos formas de equivocarse. Casi todos los agentes que sobrevivieron al contacto con la producción son menos ambiciosos que la demostración que los justificó.
Verificación barata. Este es el predictor individual más fuerte. Los agentes de codificación funcionaron primero porque las pruebas proporcionan una señal objetiva y automática: el agente puede intentar, comprobar y reintentar sin un humano. Donde la verificación es costosa —una opinión legal, una decisión de precios— la salida del agente tiene que ser revisada por una persona, lo que limita la influencia y cambia el caso de negocio.
Un límite de permisos fuera del modelo. Leer ampliamente, escribir de forma limitada. Puertas de aprobación para gastar dinero, contactar clientes, eliminar datos, desplegar. Esto se aplica en el tiempo de ejecución, nunca por instrucciones en un prompt: un agente que lee contenido no confiable es un agente cuyas instrucciones pueden contaminarse.
Presupuestos. Pasos máximos, tiempo de reloj máximo, tokens máximos. Un agente que se queda en bucle con una respuesta de herramienta mal formada es un incidente de facturación sin fin natural.
Un registro reproducible. Cada llamada a herramienta y resultado, almacenado. Cuando algo sale mal, "qué hizo realmente" debe poder responderse inmediatamente, tanto para arreglarlo como, cada vez más, para satisfacer a un auditor.
La evaluación maduró
El cambio más consecuente es el menos visible. El trabajo temprano de los agentes se evaluaba viéndolo. Eso no escala y no detecta regresiones.
La práctica actual es registrar trayectorias —la secuencia completa de pasos, llamadas a herramientas y resultados de ejecuciones reales— y reproducirlas contra cada cambio en el prompt, el modelo o el conjunto de herramientas. Cada trayectoria lleva una afirmación sobre cómo se ve una ejecución correcta. Una nueva versión del modelo no se adopta porque obtenga mejores resultados en un benchmark público; se adopta porque no rompe el conjunto registrado.
El segundo cambio es la puntuación por paso. Las tasas de éxito de extremo a extremo te dicen que algo está mal. La puntuación a nivel de paso te dice que la herramienta de recuperación devuelve resultados obsoletos los lunes.
Las herramientas se convirtieron en infraestructura
Durante un tiempo, cada producto de agente escribía sus propios conectores. El Protocolo de Contexto de Modelo convirtió la exposición de herramientas en una interfaz estándar: un servidor describe lo que ofrece, y cualquier cliente compatible puede usarlo. Eso ha trasladado el trabajo de integración de pegamento a medida en cada aplicación a servidores reutilizables mantenidos una vez.
El efecto práctico es mundano y grande: la pregunta interesante pasó de "¿cómo conecto mi agente a este sistema?" a "¿qué se le debería permitir hacer a mi agente con este sistema?". Esa es una pregunta de gobernanza, y es la correcta.
Donde no ha funcionado
Vale la pena decirlo claramente, porque los fracasos se publicitan menos:
- Operación autónoma a largo plazo. Los agentes que se dejan ejecutar durante horas con objetivos abiertos todavía se desvían, y el costo de un giro equivocado se acumula silenciosamente.
- Tareas con verificación costosa. Si un humano debe leer toda la salida para saber si es correcta, el agente ahorró mecanografía, no trabajo.
- Entornos de alta varianza. Sitios web que cambian de diseño, sistemas que devuelven errores inconsistentes, procesos con excepciones no documentadas.
- Enjambres por sí mismos. Las arquitecturas multiagente ayudan cuando las subtareas necesitan herramientas y contextos genuinamente diferentes. Aplicadas a una tarea que un solo agente podría hacer, añaden fallos de coordinación.
El resumen honesto
Los agentes funcionan hoy donde el objetivo es claro, el dominio es estrecho, el resultado es barato de comprobar y el radio de explosión está limitado por algo más que el buen juicio del modelo. Esa es una categoría real y creciente —y es más pequeña de lo que implica la palabra "agente" en un anuncio de producto.
Los equipos que lanzan con éxito son, sin mucha excepción, los que aceptaron eso primero.
Preguntas frecuentes
- ¿Qué casos de uso de agentes están funcionando realmente en producción?
- Tareas de ingeniería de software con pruebas, triaje y redacción de soporte al cliente, investigación y recopilación de documentos, y reconciliación de datos entre sistemas. Las cuatro comparten una verificación económica del resultado.
- ¿Qué tan autónomos son los agentes de producción en la práctica?
- Menos de lo que sugiere el marketing. El patrón común es un acceso de lectura amplio con una puerta de aprobación para cualquier cosa que gaste dinero, contacte a un cliente o elimine datos.
- ¿Cuál es el principal riesgo técnico?
- Inyección de indicaciones a través del contenido que lee el agente. Un agente que procesa correos electrónicos, páginas web o comentarios de solicitudes de extracción está procesando texto controlable por el atacante, y ninguna indicación puede inmunizarlo de manera confiable. La mitigación es limitar lo que se le permite hacer al agente.
- ¿Los sistemas multiagente superan a un agente único?
- Solo cuando las subtareas realmente necesiten herramientas o contextos diferentes. De lo contrario, la sobrecarga de coordinación y los modos de fallo adicionales empeoran los resultados, no los mejoran.