Las evaluaciones de Amazon AgentCore afrontan el fallo que la supervisión tradicional pasa por alto
Amazon publicó un marco de nueve etapas para las evaluaciones de Amazon AgentCore tras descubrir que una infraestructura sana puede ocultar el deterioro de las respuestas de los agentes. La latencia puede mantenerse normal. Las tasas de error pueden permanecer estables. El agente sigue respondiendo, pero su respuesta segura de sí misma puede citar la cifra o el cliente equivocados.
Ese conflicto importa porque la supervisión tradicional detecta principalmente fallos de software que dejan evidencia técnica visible. Los agentes autónomos introducen fallos semánticos: la aplicación funciona mientras su razonamiento, sus elecciones de herramientas o sus conclusiones se vuelven menos fiables.
AWS construyó el marco en torno a un sistema interno multiagente utilizado por vendedores y líderes de ventas. Agentes especializados responden preguntas sobre rendimiento, clientes y datos estructurados mediante una experiencia conversacional compartida. Una herramienta o subagente degradado puede contaminar la respuesta final sin bloquear la aplicación.
El marco representa un cambio: pasar de evaluar a un agente antes de su lanzamiento a evaluar su comportamiento de forma continua. Conecta experimentos de desarrollo, puertas de despliegue, canarios de producción, comprobaciones adversariales, detección de deriva, observabilidad y recomendaciones automatizadas.
El verdadero adversario no es otro proveedor de nube. Es la suposición conocida de que el tiempo de actividad, la latencia y las solicitudes exitosas aportan evidencia suficiente sobre la salud del agente. El caso de Amazon sostiene que esas señales describen disponibilidad, no corrección.
Las evaluaciones de Amazon AgentCore convierten la calidad en una condición de lanzamiento
El cambio significativo es que AWS trata la calidad de las respuestas como un control operativo, no como un ejercicio final de pruebas.
AWS publicó el marco el 16 de octubre de 2026, basándose en su trabajo con un sistema interno de producción. El sistema incluye los agentes Performance Insights, Customer Insights y Data Insights, que atienden distintas preguntas de negocio.
El agente Performance Insights gestiona preguntas sobre ingresos y rendimiento delimitadas por territorio. El agente Customer Insights combina señales de uso del producto, soporte, contratos e interacción. El agente Data Insights convierte preguntas en lenguaje natural en consultas SQL sobre conjuntos de datos estructurados.
Estos agentes operan tras una única interfaz, pero sus superficies de fallo siguen siendo distintas. Una herramienta de resolución de clientes puede elegir la filial equivocada. Un componente de recuperación puede devolver contexto débil. Un orquestador puede enrutar una solicitud correctamente y, aun así, distorsionar los hallazgos de los subagentes durante la síntesis.
Por ello, AWS evalúa el sistema en tres niveles. Las comprobaciones a nivel de herramienta examinan capacidades como la recuperación, la resolución de entidades y la generación de SQL. Las comprobaciones a nivel de agente puntúan a cada agente especializado desde la solicitud hasta la respuesta. Las comprobaciones multiagente evalúan el enrutamiento, la transferencia de contexto y la síntesis final.
Cada nivel recibe su propio conjunto de datos de evaluación, umbrales y criterios de promoción. Esta estructura importa porque un promedio favorable de extremo a extremo puede ocultar un componente que está fallando. El fallo puede afectar solo a un segmento de clientes, tipo de consulta o ruta de orquestación.
El marco también mide cinco dimensiones durante todo el ciclo de vida. Son seguridad, calidad, rendimiento, coste y control operativo. La calidad recibe el tratamiento más detallado, pero AWS afirma que la seguridad sigue siendo un requisito para el lanzamiento.
Las nueve etapas forman un ciclo cerrado: definir, experimentar, fusionar, establecer puertas, canario, adversario, deriva, pulso y mejorar. Las etapas abarcan desde el primer commit hasta la supervisión de producción y las revisiones posteriores.
AWS las conecta mediante AgentCore Evaluations, que admite modos de evaluación controlada y en vivo. La evaluación bajo demanda se ejecuta con conjuntos de datos, trazas o sesiones seleccionados. La evaluación en línea toma muestras continuamente de las interacciones de producción.
Esa continuidad es la afirmación importante del producto. Un equipo puede aplicar los mismos evaluadores antes del despliegue y después de que los usuarios interactúen con el agente. El estándar de evaluación no debería cambiar simplemente porque el software haya cruzado el límite hacia producción.
AWS también combina AgentCore con CloudWatch, S3, Redshift, Lambda y Amazon Quick. Esos servicios gestionan trazas, resultados de evaluadores, persistencia, puntuación personalizada, alarmas y paneles.
No se trata de un nuevo modelo fundacional ni de una nueva arquitectura de agentes. Es un modelo operativo para decidir si un agente sigue siendo apto para su uso. Ese cambio más acotado podría resultar más trascendental para las empresas que van más allá de las demostraciones.
El marco de nueve etapas comienza antes de la primera ejecución de pruebas
El marco de Amazon comienza definiendo el fallo en términos de negocio, porque un objetivo de calidad indefinido convierte en arbitraria cualquier puerta posterior.
La primera etapa establece el contrato de evaluación. Los equipos definen resultados de negocio, métricas de evaluación, umbrales de fallo, políticas de seguridad, presupuestos de latencia, objetivos de coste y respuestas operativas.
Para los vendedores de AWS, el éxito significa recibir inteligencia de cuentas actual y precisa con el nivel correcto de detalle. Los usuarios de liderazgo necesitan datos fiables para revisiones semanales y entre unidades de negocio sin una preparación manual extensa.
Después, esos resultados se traducen en categorías de fallo medibles. AWS identifica intercambios de métricas, períodos incorrectos, entidades equivocadas, cifras sin respaldo, símbolos incorrectos y cálculos no autorizados.
Esta taxonomía es más práctica que una única puntuación general de precisión. Una tasa de aprobados en descenso indica que algo ha cambiado. Un resultado por categoría indica si el problema está en la recuperación, la resolución de entidades, la interpretación temporal, el formato o el razonamiento generado.
AWS combina varios tipos de evaluador porque ningún método de puntuación único cubre todos los riesgos. Los evaluadores integrados abordan relevancia, fidelidad, utilidad, seguimiento de instrucciones y selección de herramientas. Los evaluadores personalizados se dirigen a errores específicos del dominio.
Las comprobaciones deterministas comparan los resultados con un resultado esperado exacto. Son adecuadas para identificadores de cuenta, fechas de contratos, valores de ingresos, resultados SQL y formatos estructurados. La evaluación LLM-as-a-judge utiliza un modelo y una rúbrica cuando varias respuestas podrían satisfacer razonablemente la solicitud.
Esta distinción es esencial. Pedir a otro modelo que verifique un identificador exacto añade incertidumbre cuando una comparación sencilla funcionaría mejor. Utilizar coincidencia exacta de cadenas para puntuar un razonamiento matizado crea el problema opuesto.
AWS también utiliza bibliotecas de evaluadores de terceros y un conjunto dorado, es decir, una colección versionada de consultas representativas con comportamiento esperado. Ese conjunto incluye ejemplos derivados de producción, fallos de lanzamientos anteriores y casos límite construidos.
A nivel de herramienta, el conjunto dorado prueba capacidades como la identificación de clientes. A nivel de agente, AWS cubre preguntas integrales, de informes, de razonamiento y ambiguas. Los fallos de producción pueden convertirse en casos de regresión permanentes.
La segunda etapa compara los cambios propuestos con el mismo contrato de evaluación. Las revisiones de prompts, sustituciones de modelos, incorporaciones de herramientas y actualizaciones de conjuntos de datos se someten a evaluación bajo demanda antes de fusionarse.
Esta comparación abarca calidad, latencia, coste y consumo de tokens. Un candidato que aumenta la precisión mientras incrementa considerablemente el tiempo de respuesta y el coste no gana automáticamente. El marco obliga a registrar esas compensaciones en la decisión.
AWS informa de que tres meses de iteración focalizada elevaron su tasa de aprobados del 93 % al 96 %. También afirma que las alucinaciones puras descendieron de 138 a menos de 52 por cada 10.000 respuestas.
Los cálculos no autorizados supuestamente descendieron de 59 a menos de 44 por cada 10.000 respuestas. Estas cifras proceden de la cuenta interna de AWS y no han recibido una auditoría independiente.
Esta salvedad es importante porque la fuente es tanto un estudio de caso técnico como un argumento de producto. Los resultados muestran lo que AWS afirma haber conseguido en un entorno. No establecen una referencia universal para la fiabilidad de los agentes.
Aun así, el diseño de evaluación sigue siendo útil fuera de AWS. Los equipos necesitan una definición compartida de comportamiento aceptable antes de poder comparar prompts, modelos, sistemas de recuperación o cambios de orquestación.
Documentar ese contrato también crea memoria organizativa. Los equipos que utilizan una base de conocimiento de ingeniería con capacidad de búsqueda pueden conservar definiciones de fallos, decisiones de evaluación y evidencia de incidentes junto con las notas de implementación.
Las puertas de CI y los canarios atacan ventanas de fallo diferentes
Las puertas previas al lanzamiento detienen regresiones conocidas, mientras que los canarios de producción buscan deterioros que ningún despliegue desencadenó.
La tercera etapa coloca un conjunto de datos centinela más pequeño dentro de la integración continua. AWS ejecuta este conjunto automáticamente después de los despliegues de staging, incluidos cambios en código, prompts, modelos, herramientas o configuración.
El centinela enfatiza escenarios de alto riesgo en calidad, seguridad, latencia y coste. Se ejecuta más rápido que el conjunto dorado completo, por lo que resulta adecuado para comprobaciones frecuentes. Un umbral superado puede bloquear el despliegue.
AWS mantiene centinelas separados para herramientas, agentes y flujos de trabajo multiagente. Un lanzamiento no puede aprobarse simplemente porque la puntuación final del agente parezca aceptable. Una regresión dentro de una herramienta crítica puede detener la promoción de forma independiente.
La empresa describe un cambio de normalización de datos que afectó a la resolución de nombres de clientes. La herramienta devolvía entidades sin resolver para determinados formatos, y el agente adivinaba un cliente coincidente. Ese comportamiento suponía el riesgo de devolver datos precisos sobre la cuenta equivocada.
Un caso determinista de resolución de entidades detectó el problema antes de producción. Este ejemplo refleja por qué las pruebas de agentes deben mirar más allá de la prosa final. Una respuesta fluida puede seguir siendo funcionalmente incorrecta.
La cuarta etapa amplía la comprobación de lanzamiento hasta convertirla en una puerta de calidad completa. AWS evalúa al candidato frente al conjunto dorado completo y utiliza respuestas de herramientas congeladas para aislar el comportamiento del agente.
Este diseño de repetición elimina de la comparación la disponibilidad de herramientas en vivo y los cambios en los datos de origen. Cada candidato recibe los mismos resultados validados de herramientas. Las diferencias de puntuación deberían reflejar entonces el razonamiento del agente en lugar de la variación del entorno.
AWS afirma que su puerta de extremo a extremo incluye 200 preguntas reservadas. Un candidato falla si su puntuación agregada empeora, no alcanza la referencia de producción o deja demasiadas preguntas individuales por debajo del umbral.
Esa última condición evita que los promedios oculten daños concentrados. Un modelo podría mejorar las preguntas comunes mientras se vuelve poco fiable para una región, tipo de cliente o formato de solicitud.
La quinta etapa cambia el entorno. Un canario se ejecuta en producción con tráfico en vivo y casos sintéticos, buscando fallos causados por dependencias externas o cambios de datos.
AWS eligió ventanas de evaluación de 30 minutos. Afirma que las ventanas de 15 minutos generaban demasiadas falsas alarmas, mientras que las de 60 minutos retrasaban la confirmación de un declive real.
Una ventana fallida sigue siendo una señal operativa. AWS avisa a su equipo de guardia solo después de que tres ventanas consecutivas superen el umbral. Una ejecución diaria independiente evalúa todo el conjunto dorado con los umbrales de la puerta de lanzamiento.
Este diseño busca equilibrar sensibilidad y fatiga por alertas. El canario debe detectar una pérdida sostenida de calidad sin enseñar a los ingenieros a ignorar notificaciones ruidosas.
AWS ofrece un ejemplo relacionado con la actualización de un índice de recuperación. La herramienta actualizada devolvía pasajes ampliamente relacionados en lugar del contexto preciso que requería la pregunta.
Las métricas de infraestructura parecían normales. La latencia se mantuvo dentro de lo previsto y la tasa de errores técnicos siguió en cero. El agente continuó generando respuestas pulidas basadas en evidencia más débil.
El canario detectó menor fundamentación y precisión de recuperación durante la primera ventana de evaluación. Luego, un rastro vinculó la baja puntuación con la herramienta de recuperación.
Esta es la inversión central del marco. Una solicitud exitosa puede representar un fallo del producto, mientras que una dependencia técnicamente saludable aún puede reducir la calidad de las respuestas.
Una implementación independiente de AWS y Motorway ofrece otra referencia concreta. Su plan de producción informa que los resultados de búsqueda incorrectos cayeron de una de cada ocho consultas a una de cada 50.
El agente de Motorway ayuda a los concesionarios a buscar inventario de vehículos mediante lenguaje natural. Su canalización de evaluación verifica el uso de herramientas, el razonamiento y la calidad de salida en ejecuciones repetidas. AWS afirma que la detección de problemas pasó de horas a minutos.
Los dos casos no son directamente comparables. Involucran usuarios, conjuntos de datos, definiciones de fallos y arquitecturas diferentes. Sin embargo, en conjunto muestran por qué las pruebas previas al lanzamiento y la evaluación en producción resuelven problemas distintos.
La evaluación en vivo revela los límites de los conjuntos de pruebas estáticos
Un conjunto dorado protege frente a fallos ya conocidos, pero los usuarios reales producen continuamente entradas que sus diseñadores no anticiparon.
La sexta etapa aborda el comportamiento adversarial. AWS aplica controles de entrada y salida para filtrar solicitudes, proteger datos sensibles y detectar intentos de manipular las instrucciones del agente.
El marco utiliza Bedrock Guardrails para el filtrado de contenido y la detección de ataques contra prompts. AWS afirma que estas comprobaciones cubren todo el tráfico de forma síncrona antes de que una respuesta llegue al usuario.
El modelo de amenazas incluye intentos directos de jailbreak e instrucciones ocultas dentro de documentos recuperados. También abarca intentos de extraer prompts internos o exponer datos fuera de la autorización de un usuario.
AWS señala acertadamente que la seguridad no se limita a una sola etapa. Las políticas se definen en la base, se prueban durante la integración y el despliegue, y luego se aplican en producción. La sexta etapa hace explícita la capa adversarial.
La séptima etapa se centra en la deriva, es decir, un cambio sostenido del comportamiento respecto de la línea base establecida. La deriva puede seguir a actualizaciones de datos, cambios en el comportamiento de los usuarios, supuestos obsoletos o solicitudes de cola larga ausentes del conjunto dorado.
AWS afirma que toma muestras del 10 por ciento del tráfico en vivo para la evaluación en línea. Las puntuaciones de calidad, latencia y coste alimentan un cálculo del estado de calidad que utiliza la misma estructura de ventanas de 30 minutos.
Un ejemplo interno involucró la identificación de clientes. Las pruebas sintéticas cubrían variaciones de nombres, filiales y abreviaturas. Los usuarios en vivo también proporcionaban símbolos bursátiles, nombres abreviados y errores tipográficos.
La precisión reportada cayó del 98 por ciento durante una ventana al 81 por ciento, y luego al 80 por ciento en las dos ventanas siguientes. CloudWatch alertó al equipo de guardia después de que se superara el umbral móvil.
AWS afirma que los rastros revelaron que el manejo de símbolos bursátiles y abreviaturas era la principal fuente de fallos. El equipo actualizó su lógica de normalización y promovió las sesiones de baja puntuación al conjunto dorado.
Según los informes, la precisión volvió a la línea base en el siguiente ciclo de evaluación. De nuevo, se trata de un resultado operativo comunicado por AWS y no de un hallazgo reproducido de forma independiente.
La séptima etapa también admite una exposición controlada al tráfico en vivo. Después de que una candidata supera la puerta de evaluación offline, una pasarela enruta una parte de las solicitudes entre las versiones actual y propuesta.
La candidata debe igualar o superar a la versión de producción en las dimensiones elegidas. La evaluación offline prueba casos conocidos, mientras que la comparación en vivo introduce redacciones y comportamientos desconocidos.
Este proceso se parece a los canarios de software y la supervisión de modelos ya consolidados, pero los agentes amplían el objeto medido. Los equipos deben evaluar trayectorias, llamadas a herramientas, contexto recuperado, respuestas finales y resultados de sesión.
Esa superficie más amplia crea un problema de medición. Los jueces basados en LLM pueden discrepar, heredar sesgos del modelo o premiar rasgos estilísticos que no reflejan la corrección empresarial. Las rúbricas también pueden quedar desactualizadas a medida que cambian los productos y los usuarios.
El muestreo introduce otra limitación. Evaluar el 10 por ciento del tráfico reduce el gasto de procesamiento, pero los fallos raros y perjudiciales podrían quedar fuera de la muestra. Las puntuaciones agregadas también pueden ocultar grupos de usuarios con poco volumen.
La privacidad y la gobernanza de datos requieren la misma atención. Los rastros de producción pueden contener prompts, documentos recuperados, salidas de herramientas, identificadores de cuentas y otro contexto sensible. Los controles de retención y acceso deben corresponderse con los datos involucrados.
El marco reconoce la seguridad y el control operativo, pero la calidad de la implementación sigue dependiendo de cada organización. AgentCore proporciona infraestructura de evaluación. No puede definir el comportamiento aceptable ni una verdad de referencia fiable en nombre del cliente.
Lo que el marco de Amazon aún no puede demostrar
El caso de Amazon respalda la evaluación continua, pero no demuestra que los evaluadores automatizados puedan medir plenamente la confianza.
La primera limitación es la independencia de la evidencia. El marco principal, la implementación y los resultados de rendimiento proceden de AWS. La empresa opera el sistema y vende la plataforma de soporte.
Esa relación no invalida los resultados. Sí implica que los lectores deberían considerar las mejoras reportadas como hallazgos de un estudio de caso, no como comparativas neutrales frente a plataformas de evaluación rivales.
La segunda limitación se refiere a la validez del evaluador. Una puntuación solo es útil cuando se correlaciona con el comportamiento que los usuarios realmente valoran. Un panel preciso puede generar una confianza falsa si su rúbrica mide el resultado equivocado.
AWS intenta reducir este riesgo empezando por los objetivos empresariales y combinando evaluadores deterministas, personalizados y basados en modelos. Los equipos aún deben validar cada juez frente a la revisión de expertos humanos.
El acuerdo entre evaluadores sería una señal valiosa. Si los evaluadores, expertos del dominio y usuarios discrepan con frecuencia, la puntuación automatizada no debería controlar por sí sola los despliegues. La publicación de AWS no proporciona esos datos de concordancia.
La tercera limitación es la cobertura. El marco prueba categorías de fallos conocidas e incorpora nuevos casos de producción con el tiempo. No puede garantizar la detección de cada comportamiento novedoso antes de que se produzca un daño.
Un conjunto dorado también corre el riesgo de optimizarse indirectamente. Cambios repetidos en prompts y modelos pueden mejorar las puntuaciones en ejemplos conocidos sin ofrecer una fiabilidad más amplia. Los casos reservados y los conjuntos de datos actualizados periódicamente pueden reducir ese riesgo.
La cuarta limitación es el coste. La evaluación continua añade llamadas al modelo, almacenamiento de rastros, procesamiento de datos, paneles y trabajo de ingeniería. AWS sigue el coste por consulta y el coste por respuesta exitosa, pero no publica un total completo de implementación.
Un equipo más pequeño quizá no necesite las nueve etapas de inmediato. Podría comenzar con una taxonomía de fallos específica del dominio, pruebas deterministas para hechos críticos, una puerta de lanzamiento y revisión de producción mediante muestreo.
La quinta limitación es la autoridad de remediación. La novena etapa puede generar recomendaciones sobre prompts del sistema y descripciones de herramientas a partir de rastros fallidos. Las recomendaciones no son lo mismo que cambios autónomos seguros.
Una revisión sugerida de un prompt puede corregir un fallo e introducir otro. Debe volver a pasar por la misma secuencia de experimento, integración, puerta de evaluación y canario antes de un despliegue amplio.
La reversión automatizada también necesita límites cuidadosos. Revertir un prompt o un modelo está relativamente acotado. Revertir una acción de un agente en un sistema empresarial puede implicar pagos, mensajes, registros o permisos.
Estas preocupaciones separan la evaluación de la gobernanza. La evaluación estima si el agente se comportó bien. La gobernanza determina qué puede hacer el agente, qué evidencia debe conservarse y dónde sigue siendo obligatoria la aprobación humana.
La guía más amplia de AWS sobre AgentOps sitúa la evaluación junto a la seguridad, los artefactos versionados, la observabilidad y la revisión humana. Ese enfoque es más creíble que tratar una sola puntuación como un certificado de confianza.
La confianza no es una propiedad que AgentCore pueda adherir a un agente. Es un juicio acumulado basado en resultados, controles, gestión de incidentes y transparencia. La evaluación aporta evidencia a ese juicio.
Para los compradores, por tanto, la pregunta adecuada no es si una plataforma ofrece evaluaciones. La pregunta más difícil es si sus mediciones cubren los costes reales de fallo de la organización y siguen siendo creíbles ante el cambio.
Tres señales mostrarán si el circuito cerrado funciona
El valor del marco dependerá de la credibilidad de los evaluadores, la adopción en producción y la evidencia de que la retroalimentación mejora los casos desconocidos.
La primera señal es la validación independiente de los evaluadores automatizados. Las empresas deberían estar atentas a comparaciones publicadas entre las puntuaciones de AgentCore, los juicios de expertos del dominio y los resultados reales de los usuarios.
Un alto grado de concordancia reforzaría la afirmación de AWS de que las evaluaciones pueden gobernar los lanzamientos. Un desacuerdo persistente debilitaría las puertas automatizadas y aumentaría la necesidad de revisión humana.
La comparación debería cubrir más que la utilidad general. Debería probar resolución de entidades, límites de autorización, selección de herramientas, cálculos fundamentados, resultados de sesión y síntesis multiagente.
La segunda señal es la adopción más allá de los ejemplos redactados por AWS. Los informes de producción de sectores regulados, grandes proveedores de software y equipos de ingeniería más pequeños revelarían hasta qué punto es portable el modelo de nueve etapas.
Los informes útiles deberían revelar la construcción de los conjuntos de datos, las tasas de muestreo, falsas alarmas, incidentes no detectados, tiempo de remediación y sobrecarga de evaluación. Una mejora porcentual sin esos detalles ofrece una orientación limitada.
La configuración en línea de AgentCore puede procesar continuamente rastros procedentes de un endpoint de agente o de grupos de registros de CloudWatch seleccionados. Los controles de evaluación en línea también admiten evaluadores configurables, muestreo y estado de ejecución.
La métrica de adopción importante no es el número de configuraciones habilitadas. Es si los equipos detectan fallos semánticos antes de que los usuarios los informen y resuelven esos fallos sin crear nuevas regresiones.
La tercera señal es el rendimiento del circuito cerrado en tráfico no visto. AWS afirma que su sistema de recomendaciones puede analizar rastros y sugerir prompts revisados o descripciones de herramientas más claras.
En un ejemplo reportado, valores codificados de forma fija dentro de ejemplos few-shot aparecían en respuestas no relacionadas. AWS sustituyó esos valores por marcadores de posición y observó menos alucinaciones y una fundamentación más sólida.
La siguiente prueba es si recomendaciones similares mejoran las interacciones reservadas y en vivo, no solo los rastros que las generaron. Cada recomendación debería pasar por el ciclo de evaluación original.
La octava etapa proporciona la base operativa para esa prueba. AgentCore Observability registra datos de ejecución estructurados mediante OpenTelemetry, un estándar abierto para rastros, métricas y registros.
AWS afirma que sus paneles conectan una alarma con el rastro de agente pertinente, incluido el orden de las herramientas, entradas, salidas, latencia y uso de tokens. Los resultados de los evaluadores siguen una canalización independiente hacia CloudWatch y almacenamiento a más largo plazo.
La empresa informa que el tiempo medio de detección cayó de días o semanas a menos de cuatro horas. También busca lograr una detección automatizada antes de que las quejas de los usuarios se conviertan en la principal señal de incidente.
Estos resultados recogen la promesa más defendible del marco. Las evaluaciones de Amazon AgentCore no garantizan que un sistema autónomo responda siempre correctamente. Hacen que el deterioro silencioso sea lo bastante observable como para investigarlo, bloquearlo o revertirlo.
Los desarrolladores deberían empezar por identificar la respuesta equivocada que podría causar el mayor daño. Los compradores empresariales deberían preguntar a los proveedores cómo se mide ese fallo antes del lanzamiento y cómo se detecta después.
Los trabajadores del conocimiento deberían mantener la cautela cuando un agente parece seguro de sí mismo. Un lenguaje fluido sigue sin garantizar que la herramienta, el cliente, el período o la fuente correctos sustenten la respuesta.
La próxima generación de plataformas de agentes competirá por algo más que el acceso a modelos y la orquestación. Competirá por la capacidad de los equipos para explicar los fallos, reproducirlos y evitar que se repitan.
Si su organización ya utiliza agentes, revise el último incidente que llegó a un usuario. ¿Lo habrían detectado la supervisión de la latencia o de los errores? Si no es así, esa brecha es el punto de partida para un verdadero contrato de evaluación.
