La evaluación de habilidades de Amazon Bedrock AgentCore expone lo que los agentes fluidos ocultan

Amazon presentó la evaluación de habilidades de Amazon Bedrock AgentCore el 22 de septiembre, incorporando tres comprobaciones que examinan el comportamiento de los agentes más allá de su respuesta final pulida. El lanzamiento aborda un punto ciego persistente en las pruebas. Un agente puede parecer correcto tras elegir la habilidad equivocada, omitir pasos obligatorios o improvisar en torno a un procedimiento empresarial.

Los nuevos evaluadores separan dos preguntas que los equipos a menudo condensan en una sola puntuación. ¿Seleccionó el agente una habilidad adecuada y la siguió después de cargarla? Strands Evals añade una tercera comprobación determinista para equipos que ya saben qué habilidad con nombre debe invocar una prueba.

Esta distinción cuestiona los sistemas de evaluación centrados únicamente en la calidad de la respuesta. La utilidad, la relevancia y la corrección siguen siendo importantes, pero no pueden revelar todos los fallos de enrutamiento o ejecución. La verdadera competencia ahora es entre la puntuación de la respuesta final y la evidencia a nivel de trayectoria sobre cómo un agente llegó a esa respuesta.

La evaluación de habilidades de Amazon Bedrock AgentCore divide un fallo en tres

AWS está convirtiendo el uso de habilidades en una secuencia medible, en lugar de tratar la respuesta final como evidencia suficiente de éxito.

Una habilidad es un paquete reutilizable de instrucciones que enseña a un agente un procedimiento especializado. Normalmente incluye un archivo SKILL.md que contiene su propósito, orientación para su activación y los pasos obligatorios. Un entorno de ejecución presenta las habilidades disponibles, mientras el agente decide cuál cargar para una solicitud.

Esta estructura permite a los desarrolladores trasladar procedimientos detallados fuera de un prompt de sistema cada vez más extenso. Una empresa podría crear habilidades separadas para la conciliación de facturas, la redacción de contratos, la escalada de incidentes o la revisión de pull requests. El agente carga las instrucciones pertinentes cuando las necesita, en vez de arrastrar cada procedimiento en cada interacción.

La portabilidad forma parte de su atractivo. El formato abierto Agent Skills ofrece a los entornos de agentes compatibles una forma compartida de empaquetar instrucciones especializadas. Por tanto, una habilidad puede servir como un artefacto operativo, no solo como un fragmento de prompt vinculado a una llamada de modelo.

Sin embargo, las instrucciones modulares introducen una cadena de decisiones. El agente debe reconocer la intención del usuario, encontrar una habilidad adecuada, invocarla, leer su contenido y completar los pasos prescritos. Un buen párrafo final no demuestra que esta cadena haya funcionado.

AWS y el equipo de Strands ahora dividen esa cadena entre tres evaluadores, según el lanzamiento de la evaluación de habilidades del 22 de septiembre.

Skill Selection Accuracy pregunta si cada habilidad invocada era apropiada para la tarea. Devuelve un resultado binario para cada habilidad invocada. Esto hace visibles los errores de enrutamiento cuando un agente carga instrucciones destinadas a otro flujo de trabajo.

Skill Instruction Following examina hasta qué punto el agente realizó los pasos prescritos de una habilidad invocada. Sus cinco calificaciones son Fully Followed, Mostly Followed, Partially Followed, Minimally Followed y Not Followed. Sus valores numéricos documentados van de 1.0 a 0.0 en incrementos de un cuarto de punto.

Skill Invoked proporciona una afirmación más limitada y determinista dentro de Strands Evals. Comprueba si el agente cargó correctamente una habilidad con nombre. A diferencia de los otros dos evaluadores, no pide a un modelo que juzgue la idoneidad o el cumplimiento.

Estas medidas responden a preguntas distintas. Puede que una habilidad obligatoria de nóminas nunca se cargue, lo que produciría un fallo de enrutamiento. Podría cargarse para una solicitud de viajes no relacionada, lo que produciría un fallo de selección. Podría cargarse correctamente, pero omitir un paso de aprobación, lo que produciría un fallo de seguimiento de instrucciones.

Esa separación es el cambio central. Los equipos ya no tienen que interpretar cada resultado débil como un problema impreciso de calidad del agente. Pueden asociar cada patrón con un componente distinto y una corrección más específica.

Una invocación ausente apunta a reglas de descubrimiento, descripciones o lógica de enrutamiento. Una invocación inapropiada sugiere ámbitos de habilidad solapados. Una habilidad seleccionada correctamente con bajo cumplimiento dirige la atención a sus pasos, estructura, herramientas disponibles o al modelo subyacente.

El lanzamiento no sustituye la evaluación de calidad existente. Añade otra capa diseñada para agentes cuyo comportamiento depende de procedimientos cargados dinámicamente. La precisión de la salida sigue siendo esencial, pero pasa a ser una parte de un registro de pruebas más amplio.

Las respuestas fluidas ya no son evidencia suficiente

El argumento más sólido a favor de la evaluación de trayectorias es sencillo: diferentes fallos internos pueden producir una prosa igual de convincente.

Pensemos en un empleado que pide a un agente redactar un contrato antes de compartirlo externamente. El agente podría eliminar nombres evidentes y devolver un documento de aspecto limpio. Sin embargo, la habilidad aprobada también podría exigir comprobar metadatos, comentarios ocultos, cambios controlados y referencias a archivos adjuntos.

Un revisor que solo ve el documento final puede pasar por alto esas comprobaciones omitidas. La respuesta puede parecer competente mientras incumple el procedimiento real de gestión de la organización. Skill Instruction Following está diseñado para comparar el comportamiento registrado con cada paso prescrito.

El mismo problema aparece en las operaciones financieras. Un agente de conciliación de facturas podría producir el total correcto mediante razonamiento informal. Si la habilidad exige validar la identidad del proveedor y la autorización de compra, el resultado sigue siendo procedimentalmente incompleto.

El cumplimiento normativo hace que esta distinción sea especialmente importante. A las organizaciones rara vez les importa solo que una respuesta concreta haya sido aceptable. También necesitan evidencia de que se aplicaron controles repetibles en el orden y contexto requeridos.

Las pruebas de software tradicionales ofrecen expectativas exactas para funciones deterministas. Los agentes se comportan de otra manera porque el mismo prompt puede producir lenguaje, llamadas a herramientas y trayectorias de razonamiento variados. AWS ya había sostenido que una sola ejecución aprobada muestra lo que puede ocurrir, no lo que suele ocurrir.

Esa variabilidad hace tentadoras las puntuaciones agregadas de respuesta. Un equipo puede promediar la corrección o utilidad en un conjunto de datos y seguir si el número aumenta. Sin embargo, un promedio oculta dónde falló un flujo de trabajo y si el mismo paso sigue desapareciendo.

Los resultados por habilidad ofrecen una unidad de diagnóstico más útil. Cuando un agente invoca varias habilidades durante una sesión, los evaluadores devuelven resultados para cada invocación. Por ello, un agregado débil puede rastrearse hasta la habilidad específica que lo redujo.

El enfoque también cambia la forma en que los equipos escriben habilidades. Un párrafo vago puede ser comprensible para un autor humano, pero difícil de evaluar de forma consistente. Los pasos numerados y observables proporcionan al evaluador evidencia más clara y facilitan la identificación de omisiones.

Esto no significa que cada pensamiento interno pase a estar disponible. La evaluación se basa en trayectorias y rastros registrados, incluidos mensajes visibles, acciones de carga de habilidades y llamadas a herramientas. El razonamiento privado del modelo no se requiere ni se expone.

La evidencia pertinente es operativa. ¿Cargó el agente la habilidad? ¿Qué habilidad eligió? ¿Las acciones registradas muestran que completó las comprobaciones prescritas? Esa evidencia es más accionable que especular sobre un razonamiento oculto.

Este cambio se parece a la diferencia entre comprobar un cálculo terminado y auditar los controles que lo rodean. Ambas perspectivas importan, pero responden a preguntas distintas. Una mide el artefacto, mientras la otra mide el proceso que lo produjo.

Para los equipos que desarrollan agentes internos, el proceso suele conllevar un riesgo organizacional mayor. Una respuesta fluida puede satisfacer a un usuario una vez. Un paso omitido de aprobación, divulgación o validación puede socavar el flujo de trabajo cada vez que se repitan las mismas condiciones.

Los nuevos evaluadores facilitan nombrar esa brecha procedimental. También presionan a otras plataformas de agentes para que expongan trayectorias compatibles. Sin eventos de habilidad observables, un equipo no puede distinguir con confianza una invocación ausente de una extracción fallida.

Strands Evals incorpora las comprobaciones al desarrollo

Strands Evals ofrece a los desarrolladores una capa de pruebas local para el enrutamiento y la ejecución de habilidades antes de que el tráfico de producción se convierta en el conjunto de pruebas.

Strands Evals es un marco de código abierto para evaluar agentes y aplicaciones de modelos de lenguaje. Sus capacidades publicadas incluyen puntuación de resultados, análisis de trayectorias, evaluación de herramientas, simulaciones, experimentos y evaluación basada en rastros.

El repositorio de evaluación del proyecto ahora documenta las tres comprobaciones de habilidades. Los desarrolladores pueden ejecutar Skill Selection Accuracy y Skill Instruction Following contra una sesión registrada o una trayectoria de mensajes sin procesar.

Los evaluadores basados en jueces leen la trayectoria en lugar de volver a ejecutar el agente. Esto permite investigar después de un fallo y comparar sesiones guardadas. También separa la costosa ejecución del agente del análisis repetido del mismo registro.

Skill Invoked cubre una necesidad de prueba distinta. Si un caso de regresión tiene un requisito de enrutamiento conocido, los desarrolladores pueden afirmar que se cargó la habilidad esperada. La comprobación es determinista y no requiere un modelo juez.

Esto la hace adecuada como puerta de lanzamiento. Una solicitud de atención al cliente relacionada con el cierre de una cuenta debería cargar de manera consistente la habilidad de cierre aprobada. Si una descripción revisada impide la invocación, la prueba de regresión puede fallar antes del despliegue.

La precisión de selección sigue siendo útil cuando puede aplicarse razonablemente más de una habilidad. Pregunta si una habilidad invocada encaja con la tarea en vez de compararla únicamente con un nombre fijo. Esa flexibilidad admite catálogos con procedimientos relacionados y variaciones legítimas de enrutamiento.

El seguimiento de instrucciones prueba entonces la siguiente etapa. El evaluador identifica los pasos prescritos en la habilidad cargada y etiqueta cada uno como cubierto, parcial u omitido. Utiliza esos juicios para producir la calificación general de cinco niveles.

La combinación crea una matriz de pruebas compacta.

Una puntuación alta de selección con un seguimiento de instrucciones débil significa que el enrutamiento funcionó, pero la ejecución no. El agente encontró el procedimiento correcto y luego omitió o solo completó parcialmente sus requisitos.

Una selección débil con un seguimiento de instrucciones sólido significa que el agente siguió el procedimiento cargado, pero ese procedimiento era incorrecto para la solicitud. Mejorar la redacción interna de la habilidad no resolvería ese error de enrutamiento.

Una invocación ausente requiere un tratamiento especial. AWS señala que los dos evaluadores basados en jueces no devuelven una puntuación cuando no se invocó ninguna habilidad. Los equipos deberían combinarlos con Skill Invoked cuando una habilidad con nombre sea obligatoria.

Este comportamiento evita un éxito engañoso. Un evaluador no puede juzgar el cumplimiento de instrucciones que nunca se cargaron. Sin embargo, un resultado vacío puede desaparecer dentro de un panel a menos que el conjunto de pruebas trate explícitamente la falta de invocación como un fallo.

Strands también impone una carga de instrumentación al entorno de ejecución. Su extractor debe reconocer las habilidades disponibles y seleccionadas a partir de la trayectoria. El proyecto admite varios entornos conocidos, además del patrón genérico de leer un archivo SKILL.md.

Los desarrolladores deberían verificar la extracción antes de confiar en una puntuación. Un entorno con señales de habilidad no reconocidas puede producir resultados vacíos incluso cuando el agente utilizó una habilidad. Se trata de una brecha de observabilidad, no de evidencia de comportamiento correcto.

Esta salvedad importa para los equipos que integran capas de orquestación personalizadas. La calidad de la evaluación depende del registro fiel de los eventos. Un atributo de rastro ausente puede parecerse a una acción ausente del agente, a menos que los equipos validen primero el contrato de telemetría.

Por tanto, el flujo de trabajo de desarrollo tiene dos etapas. Primero, confirmar que el evaluador puede ver el catálogo, la invocación, el contenido de la habilidad y las acciones posteriores. Segundo, medir si esas acciones se ajustan a la tarea y cumplen las instrucciones.

Para los equipos de ingeniería que mantienen flujos de trabajo técnicos locales, el cambio también refuerza el valor de una base de conocimientos de ingeniería con capacidad de búsqueda. Las habilidades pueden codificar procedimientos, mientras que el material fuente mantenido aporta los hechos sobre los que operan esos procedimientos.

AgentCore Lleva la Evaluación de Habilidades a las Trazas de Producción

AgentCore amplía las mismas preguntas sobre enrutamiento y cumplimiento, pasando de pruebas seleccionadas a sesiones preparadas y muestras de tráfico real.

Amazon Bedrock AgentCore Evaluations es un servicio gestionado para evaluar el comportamiento de agentes durante el desarrollo y en producción. Consume trazas de OpenTelemetry, que registran eventos estructurados como llamadas a modelos, uso de herramientas y operaciones de agentes.

OpenTelemetry importa porque reduce la dependencia de un único framework de agentes. La documentación de AgentCore indica que el servicio admite integraciones como Strands y LangGraph mediante instrumentación de OpenTelemetry y OpenInference.

Esta arquitectura otorga al lanzamiento un papel más amplio que el de una función exclusiva de Strands. Strands Evals gestiona casos de prueba y trayectorias de desarrollo registradas. AgentCore puede evaluar trazas compatibles de agentes desplegados, incluidas sesiones producidas fuera del framework Strands.

AWS ofrece tres modos de evaluación. La evaluación bajo demanda investiga sesiones seleccionadas o valida un cambio reciente. La evaluación por lotes procesa múltiples sesiones almacenadas para establecer una referencia o comparar una revisión del catálogo.

La evaluación en línea toma muestras continuamente del tráfico de producción. Los equipos eligen evaluadores, una fuente de datos, filtros y una tasa de muestreo. AgentCore aplica entonces esas evaluaciones a medida que llegan las trazas coincidentes.

Los modos de evaluación admiten distintas preguntas operativas. Un desarrollador puede inspeccionar una sesión fallida, puntuar una población almacenada o supervisar comportamientos que solo aparecen entre usuarios reales.

Esa progresión aborda una brecha habitual en las pruebas de agentes. Los prompts seleccionados reflejan lo que los diseñadores esperan que las personas pregunten. Las solicitudes de producción contienen abreviaturas, contexto ausente, formulaciones inusuales y combinaciones que un autor de pruebas no anticipó.

Los catálogos de habilidades también cambian con el tiempo. Una habilidad nueva puede solaparse con una descripción más antigua y modificar el enrutamiento aunque los pasos internos de ninguna de las habilidades hayan cambiado. AWS denomina a esto deriva del catálogo.

La evaluación en línea puede revelar esa deriva mediante descensos en las puntuaciones de selección. Los equipos pueden entonces examinar qué habilidad comenzó a atraer solicitudes inadecuadas. La corrección podría consistir en acotar una descripción o aclarar los límites entre habilidades cercanas.

Las sesiones largas plantean otra preocupación. Un agente podría seguir una habilidad de forma fiable al inicio de una conversación, pero perder de vista los pasos a medida que se acumula el contexto. Las trazas de producción exponen esas condiciones de forma más natural que los prompts de prueba aislados.

El servicio gestionado también admite muestreo dirigido. La documentación de AWS indica que los equipos pueden evaluar un porcentaje de sesiones o aplicar filtros condicionales. Eso permite a los operadores centrarse en flujos de trabajo sensibles sin procesar cada interacción.

Sin embargo, el muestreo cambia el significado del panel. Una evaluación de bajo volumen o con filtros muy estrechos puede pasar por alto fallos poco frecuentes. Los equipos deben registrar qué tráfico cumplía los requisitos y evitar presentar una puntuación muestreada como cobertura completa.

La ruta de producción también depende de una telemetría correcta. AgentCore organiza las interacciones en sesiones, trazas y spans. Una sesión contiene una conversación, una traza cubre un intercambio y los spans representan operaciones individuales.

La evaluación de habilidades necesita suficiente información para reconstruir qué estaba disponible, qué se cargó y qué ocurrió después. Si la instrumentación omite el contenido de la habilidad o la señal de invocación, el evaluador carece de la evidencia necesaria para un resultado defendible.

La guía de AgentCore de AWS describe un formato de trazas unificado que se puntúa con evaluadores basados en modelos. Esa estandarización simplifica las operaciones, pero no puede recuperar eventos que la aplicación nunca registró.

Los equipos de seguridad también deberán examinar el contenido de las trazas. El texto de las habilidades puede contener procedimientos internos, y los registros de conversación pueden incluir datos sensibles de usuarios. La evaluación amplía el valor de la telemetría al tiempo que eleva la importancia de los controles de acceso y las decisiones de retención.

El resultado es un modelo de ciclo de vida, no una prueba única. Los desarrolladores pueden establecer controles deterministas localmente, comparar sesiones almacenadas antes del lanzamiento y observar comportamientos muestreados después del despliegue. Cada capa detecta una clase distinta de fallo.

Las Nuevas Puntuaciones También Necesitan su Propia Evaluación

Los evaluadores basados en modelos aportan detalle diagnóstico, pero no convierten el cumplimiento procedimental en un hecho objetivo.

Skill Selection Accuracy y Skill Instruction Following dependen de un modelo evaluador. El evaluador lee la tarea, la evidencia disponible y las instrucciones de la habilidad antes de emitir una calificación. Su resultado sigue siendo una interpretación de la trayectoria registrada.

Esa interpretación puede variar ante pasos ambiguos. Una habilidad podría indicar: “verifica el estado del cliente antes de continuar”, sin definir qué evidencia de verificación es aceptable. Un evaluador puede considerar suficiente una consulta a la base de datos, mientras que otro espera una confirmación explícita.

La escala de cumplimiento de cinco niveles aporta matices, pero también puede crear una falsa precisión. Una calificación de 0,75 parece exacta incluso cuando la distinción subyacente entre Mostly Followed y Partially Followed depende del criterio.

Por tanto, los equipos deberían calibrar el evaluador frente a ejemplos revisados por personas. El objetivo no es lograr una concordancia perfecta en cada caso límite. Es disponer de una rúbrica estable que refleje las prioridades procedimentales reales de la organización.

Las habilidades deberían hacer observables los pasos importantes. “Considera la política pertinente” es difícil de verificar. “Recupera la política vigente, compara la solicitud con tres condiciones de elegibilidad y registra el resultado” crea evidencia más clara.

Los casos negativos importan tanto como los positivos. Un benchmark de selección debe incluir solicitudes que se parezcan al ámbito de una habilidad, pero que no deberían invocarla. De lo contrario, una descripción amplia puede obtener buena puntuación al activarse para toda tarea cercana.

Las pruebas a nivel de catálogo también son esenciales. Evaluar una habilidad de forma aislada dice poco sobre el enrutamiento cuando aparecen juntas diez opciones similares. El entorno de prueba relevante debe parecerse al catálogo que los agentes realmente verán.

La comprobación determinista Skill Invoked tiene su propia limitación. Demuestra que se cargó una habilidad con nombre, no que cargarla fuera apropiado o útil. Un equipo puede lograr una invocación perfecta y aun así seleccionar la habilidad para solicitudes equivocadas.

Del mismo modo, un fuerte seguimiento de instrucciones no garantiza una respuesta correcta. Una habilidad defectuosa puede prescribir los pasos equivocados. El agente puede ejecutar esos pasos fielmente y aun así producir un resultado inseguro o inexacto.

Por eso la evaluación a nivel de respuesta debe seguir acompañando a la evaluación de habilidades. Los equipos aún necesitan comprobaciones de corrección, fidelidad, daño, parámetros de herramientas y validación específica del dominio. El cumplimiento del procedimiento es una dimensión de la fiabilidad.

Las plantillas de prompts oficiales hacen que la lógica de puntuación sea examinable. Muestran que el evaluador de cumplimiento identifica pasos, etiqueta la evidencia de respaldo y asigna el resultado a una de cinco calificaciones.

La transparencia ayuda a los equipos a entender el evaluador, pero no sustituye la validación. Las organizaciones deberían comparar los resultados del evaluador con revisiones de expertos antes de utilizar las puntuaciones para decisiones de lanzamiento sensibles.

El coste y la latencia también condicionan el uso en producción. La evaluación basada en evaluadores requiere procesamiento adicional del modelo tras la ejecución original del agente. El muestreo y los filtros pueden controlar esa carga, pero también reducen la cobertura.

Los equipos deberían evitar condensar todos los evaluadores en una única puntuación principal. Un único número compuesto recrea la ambigüedad que este lanzamiento está diseñado para eliminar. La selección, la invocación, el cumplimiento y la calidad de la salida deberían seguir siendo señales separadas y visibles.

El lanzamiento también deja fuera de su alcance cuestiones de gobernanza. No decide quién puede crear una habilidad, aprobar una revisión o definir un procedimiento obligatorio. La evaluación solo puede revelar desviaciones después de que una organización establezca una referencia autorizada.

Un flujo de trabajo maduro versionará las habilidades junto con los cambios en las pruebas y las rúbricas. De lo contrario, los equipos no podrán determinar si una puntuación cambió porque cambió el agente, las instrucciones o el evaluador.

Amazon presenta las comprobaciones como herramientas de diagnóstico, no como prueba independiente de cumplimiento. Ese es el límite adecuado. Hacen que el comportamiento de los agentes sea más revisable, mientras la responsabilidad sigue recayendo en las personas que definen y validan el flujo de trabajo.

Tres Señales Mostrarán si Funciona la Evaluación de Habilidades

La siguiente prueba es si los equipos pueden convertir la evidencia por habilidad en lanzamientos más seguros, diagnósticos más rápidos y mejores catálogos de habilidades.

La primera señal es la adopción de controles deterministas de enrutamiento durante el desarrollo. Los equipos deberían identificar flujos de trabajo en los que una habilidad específica es obligatoria y añadir aserciones de Skill Invoked a las suites de regresión.

Si esos controles detectan cambios en el catálogo antes del despliegue, el argumento a favor de pruebas conscientes de las habilidades será más sólido. Si los problemas de extracción producen resultados vacíos con frecuencia, la instrumentación seguirá siendo el obstáculo inmediato.

La segunda señal es si las puntuaciones de selección en producción revelan deriva del catálogo. Las habilidades nuevas suelen llegar con descripciones amplias porque sus autores quieren que se activen de forma fiable. Esas descripciones pueden arrebatar solicitudes a procedimientos existentes.

Un sistema de producción útil debería mostrar qué invocaciones pasaron a ser inapropiadas tras una actualización del catálogo. Los equipos deberían entonces poder vincular el descenso a una descripción, solapamiento o patrón de solicitud específicos.

La evidencia de diagnósticos repetibles reforzaría la afirmación central de AWS. Los paneles que solo muestran un agregado inferior sin identificar la habilidad afectada la debilitarían.

La tercera señal es la concordancia entre Skill Instruction Following y la revisión de expertos. Las organizaciones deben comparar las etiquetas del evaluador a nivel de paso con los juicios de personas que entienden el procedimiento.

Una concordancia consistente justificaría un uso más amplio en controles de lanzamiento y supervisión en línea. Los desacuerdos frecuentes sugerirían que los pasos de la habilidad, la evidencia de las trazas o la rúbrica del evaluador necesitan más trabajo.

Los equipos deberían comenzar con un catálogo pequeño y un conjunto de pruebas deliberadamente variado. Incluyan coincidencias claras, casos casi coincidentes, solicitudes que no requieren ninguna habilidad y flujos de trabajo con varias habilidades. Ejecuten cada escenario más de una vez, porque el comportamiento de los agentes sigue siendo no determinista.

Registren por separado cuatro resultados: si se cargó la habilidad esperada, si cada invocación fue apropiada, si se siguieron los pasos obligatorios y si el resultado final fue correcto. Esta estructura preserva el valor diagnóstico de los nuevos evaluadores.

Después, examinen los desacuerdos en lugar de promediarlos. Una respuesta correcta con pasos omitidos puede revelar un riesgo operativo latente. Una respuesta deficiente tras una ejecución fiel puede revelar una habilidad defectuosa en vez de un modelo débil.

La supervisión de producción debería comenzar con flujos de trabajo sensibles o de gran volumen. Utilicen filtros y muestreo de forma deliberada, y documenten qué excluye la población puntuable. Mantengan disponible la revisión de expertos para fallos graves y calificaciones cuestionadas.

La evaluación de habilidades de Amazon Bedrock AgentCore importa porque cambia qué se considera evidencia. Una salida fluida sigue siendo valiosa, pero ya no resuelve por sí sola si un agente siguió el procedimiento de la organización.

La pregunta práctica ahora es suya: ¿puede su equipo explicar qué skill seleccionó un agente, por qué esa elección fue adecuada y qué pasos obligatorios demuestra haber completado la traza? Si no es así, incorpore esa evidencia en el próximo ciclo de pruebas antes de añadir más skills.