Evaluación de flujos de trabajo de IA agéntica

Los agentes y las tuberías agénticas se están construyendo y lanzando a un ritmo acelerado como nunca antes. Pero, ¿cómo podemos determinar qué tan buenos son?

Por qué importa evaluar a los agentes de IA

Piensa en un agente de inteligencia artificial como una pulsera de actividad física. El dispositivo siempre funciona, nunca dice “No se pudieron obtener datos precisos” y siempre te dará una lectura cuando presiones el botón, pero la mayoría de las veces, estas lecturas difícilmente son precisas. Lo mismo ocurre con los agentes; cada equipo tiene uno para su caso de uso específico y siempre generan una respuesta. Pero muy pocos saben qué tan bien se desempeñan en escenarios del mundo real. Asumimos que funcionan, sin saber realmente qué tan bien lo hacen.

El desarrollo de marcos sólidos de evaluación de agentes de IA se ha vuelto esencial por varias razones convincentes:

1. Calidad seguridadA medida que los agentes de IA se vuelven más autónomos y manejan tareas críticas, la evaluación sistemática garantiza que cumplan con los estándares de confiabilidad antes de su implementación
2. Rendimiento bevaluación comparativaLas métricas objetivas permiten un seguimiento consistente del rendimiento a través de las iteraciones del modelo y la comparación con los estándares de la industria.
3. Dirigido mejoraEl análisis detallado identifica debilidades específicas, lo que permite una asignación eficiente de los recursos de desarrollo.
4. Alineación verificaciónGarantiza que los agentes actúen de acuerdo con las intenciones de diseño y no desarrollen comportamientos inesperados en casos límite
5. Cumplimiento y riesgo gestiónFacilita la documentación de las capacidades y limitaciones de los agentes para los requisitos reglamentarios y legales
6. Inversión justificaciónProporciona evidencia cuantitativa del valor y la mejora del sistema de IA a las partes interesadas y tomadores de decisiones.

Desglose del proceso de evaluación de agentes

Evaluar a un agente, ya sea un chatbot, un sistema de generación aumentada por recuperación (RAG) o un LLM que utiliza herramientas, requiere un enfoque sistemático para garantizar que tu modelo sea preciso, confiable y sólido. Veamos los pasos típicos de cómo se puede evaluar un flujo de trabajo agéntico:

1. Prepara la verdad de referenciaUsa conjuntos de datos públicos si se ajustan a tu caso de uso, o preferiblemente, genera datos sintéticos adaptados a la funcionalidad de tu agente
2. Ejecuta el agente en el conjunto de datosAlimenta cada entrada/consulta del conjunto de datos al agente
3. Registrar toda la actividad del agente: respuestas finales, llamadas a herramientas, resultados y pasos de razonamiento si corresponde
4. Crea y realiza un experimentoEvaluar las respuestas del agente. Comparar las respuestas del agente con las respuestas esperadas/de referencia. Manejar coincidencias parciales, salidas anidadas o datos estructurados utilizando lógica de comparación personalizada si es necesario. Agregados los resultados y calcular las métricas de evaluación (exactitud, tasa de éxito, etc.).
5. Persistir los resultadosGuarde los resultados de la evaluación para poder reproducirlos y consultarlos más tarde. Identifique los puntos de falla a partir de las métricas.

Prepara la verdad de referencia

Uno de los mayores desafíos al evaluar sistemas agénticos es la disponibilidad de datos de referencia (ground truth), es decir, las referencias con las que se comparan las respuestas del agente para evaluarlo. Para evaluar eficazmente un agente típico, se necesitan datos de referencia integrales que cubran las llamadas a herramientas, los parámetros de las herramientas, las salidas de las herramientas y las respuestas finales. Recopilar y etiquetar todos estos datos de referencia llevará mucho tiempo y requiere una gran cantidad de contribución humana.

Si no tenemos los recursos para preparar datos de referencia seleccionados para la evaluación, tenemos dos opciones. O podemos aprovechar conjuntos de datos de evaluación disponibles públicamente o podemos generar datos sintéticos que puedan usarse como los datos de referencia.

Un generador de datos sintéticos se encarga de crear datos de referencia (ground truth) seleccionados a partir de documentos sin procesar; aquí, documentos sin procesar se refiere a cualquier documento que contenga información sobre el caso de uso del agente. Por ejemplo, si el agente es un planificador de viajes, se puede proporcionar como entrada al generador de datos un documento que contenga todas las ubicaciones junto con información sobre ellas, el cual genera un conjunto de pares de preguntas y respuestas que se pueden utilizar para evaluar dicho agente. Puede generar consultas de salto único (consultas que se pueden responder a partir de una sola instancia de datos) o consultas de salto múltiple (que solo se pueden responder a partir de múltiples fuentes).

Una muestra de la salida del generador:

{
        "question": "¿Cómo varían las reglas de la casa sobre los niveles de ruido entre las opciones de alquiler disponibles en Hell's Kitchen, Manhattan?",
        "answer": [
            "Las reglas de la casa sobre los niveles de ruido entre..."
        ]
}

Pero esta solución viene con sus propias desventajas; los datos generados no son deterministas y siempre contendrán ruido en cierta medida. Además, se requiere un LLM muy bueno para generar las mejores muestras, y estos LLMs consumen muchos recursos y son costosos.

Ejecutar el agente en los datos reales

Una vez establecida la verdad fundamental, el siguiente paso es ejecutar el agente en este conjunto de datos. Ejecute el agente en los pares de preguntas y respuestas creados por el generador, o en las verdades fundamentales de referencia anotadas manualmente y recupere la salida del estado, donde cada estado del agente tiene el siguiente formato (este estado se registra de forma predeterminada si está utilizando marcos populares como LangGraph):

{
        "pregunta": "¿Cuál es el precio del cobre?",
        "respuestas_del_agente": [
            "El precio actual del cobre es $0.0098 por gramo."
        ],
        "agent_tool_calls": [
            {
                "name": "get_price",
                "args": {
                    "item": "copper"
                }
            }
        ],
        "agent_tool_outputs": [
            "$0.0098"
        ],
},

Pasa esta salida del agente al modelo de datos (Conjunto de datos de evaluación) para crear una estructura conjunto de datos de referencia (el conjunto de datos de referencia aquí se refiere al conjunto de datos que contiene todos los datos necesarios para la evaluación, es decir, la combinación de la salida del agente y la verdad fundamental sobre la cual se ejecutó el agente). El framework incluye una clase LoadOperator para envolver y persistir estos datos. Esto garantiza que los conjuntos de datos sintéticos sean:

• Validado contra el esquema
• Versionado automáticamente
• Almacenado en Couchbase con un sentido descripción del conjunto de datos

Un componente clave en la recuperación y almacenamiento de datos es el Operador de carga. Se encarga de la ingesta, el almacenamiento y la recuperación de conjuntos de datos de evaluación, abstrayendo los detalles del almacenamiento en Couchbase y exponiendo una interfaz limpia al resto del framework. Puede cargar y recuperar el conjunto de datos de evaluación hacia y desde el almacén KV de Couchbase utilizando el id_de_conjunto_de_datos.

Crea y realiza un experimento

Una vez que tengamos las respuestas del sistema agéntico (el conjunto de datos de referencia), iniciamos un experimento (una única instancia administrada de evaluación realizada en el conjunto de datos de referencia) utilizando el marco con los datos de evaluación y un conjunto de opciones de experimentos que constan de las métricas (más información sobre las métricas en la siguiente sección) a utilizar y otra información relacionada con su sistema agéntico.

La gestión de experimentos en nuestro marco va más allá de simplemente registrar resultados; proporciona un sistema integral y automatizado para rastrear cada aspecto de una ejecución de evaluación. Cada experimento está asociado a un conjunto de datos identificado de manera única, cargado y versionado con metadatos descriptivos y marcas de tiempo. Esto garantiza que cada conjunto de datos, ya sea sintético o real, pueda rastrearse y reutilizarse con total transparencia. Los parámetros configurables (por ejemplo, puntos de control del modelo, versiones de *prompts*, cadenas de herramientas) también se almacenan junto con los resultados, lo que crea un rastro de metadatos para cada ejecución.

El administrador de experimentos también te brinda la capacidad de iniciar una cadena de experimentos, donde cada experimento sucesivo realiza un seguimiento de los cambios en el agente a partir de su experimento principal. Los experimentos se versionan mediante Git; confirma tu código y ejecuta el experimento para desarrollar iterativamente sus agentes y comparar las evaluaciones realizadas en el mismo agente a lo largo de las versiones. Los metadatos de cada experimento contienen registros de diferencias de código, métricas promediadas y configuraciones que se pueden utilizar para analizar si un cambio mejoró o no el sistema basado en agentes. Además, todos los conjuntos de datos y experimentos utilizados en nuestro marco de trabajo están versionados, se pueden consultar y son escalables. Podemos almacenar grandes conjuntos de evaluación, recuperar subconjuntos para análisis dirigidos y realizar un seguimiento de metadatos como marcas de tiempo y descripciones de conjuntos de datos, lo que representa una mejora enorme en comparación con los flujos de trabajo basados en archivos planos, hojas de cálculo o documentos en memoria.

Persistir resultados en Couchbase

El resultado de un experimento consta de archivos json y csv con instancias de datos y las puntuaciones correspondientes. A continuación, se muestra un resultado de muestra para una conversación de un solo agente (instancia de datos individual):

[
    {
        "user_input": "¿Cuál es el precio del cobre?",
        "retrieved_contexts": null,
        "response": null,
        "reference": null,
        "respuestas_del_agente": [
            "",
            "El precio actual del cobre es $0.0098 por gramo."
        ],
        "llamadas_a_herramientas_del_agente": [
            {
                "name": "get_metal_price",
                "args": {
                    "metal_name": "cobre"
                }
            }
        ],
        "agent_tool_outputs": [
            "0.0098"
        ],
        "reference_tool_calls": [
            {
                "name": "get_metal_price",
                "args": {
                    "metal_name": "cobre"
                }
            }
        ],
        "gt_answers": [
            "",
            "El precio actual del cobre es $0.0098 por gramo."
        ],
        "gt_tool_outputs": [
            "0.0098"
        ],
        "fidelidad_de_la_respuesta": 3,
        "coherencia_lógica": 1.0,
        "corrección_de_la_respuesta_del_agente": 0.5
    },
]

Los resultados se almacenan en el almacén KV de Couchbase con un ID de experimento. Los experimentos se pueden recuperar usando el Operador de carga, lo que le permite consultar y comparar experimentos realizados durante una sesión diferente.

En resumen, con el framework, ejecutar un experimento no es solo la ejecución de un script único. Es un proceso gestionado:

1. Cargas o generas un conjunto de datos de verdad fundamental, el cual está versionado y descrito
2. Configuras tu agente y tus parámetros de evaluación, todo lo cual queda registrado
3. Ejecutas la evaluación y el marco de trabajo almacena automáticamente los resultados, junto con todos los metadatos relevantes
4. Más tarde, puedes recuperar cualquier experimento, ver exactamente cuáles fueron los cambios realizados en el sistema y compararlo con otras ejecuciones
5. Este nivel de gestión de experimentos es lo que convierte la evaluación de una “caja negra” en un proceso transparente, repetible y colaborativo

¿Cómo funciona?

En el núcleo del marco, hay cuatro componentes clave que trabajan juntos para producir los resultados finales.

Generador de datos sintéticos

El generador de datos crea pares de preguntas y respuestas sintéticas a partir de documentos. Estos pares de preguntas y respuestas se pueden utilizar como la verdad fundamental (ground truth) para evaluar su sistema agéntico utilizando nuestro marco de trabajo. El generador de datos recibe documentos (CSV, JSON o texto plano) y aprovecha un indicación de pocos ejemplos LLM ajustado para generar los pares. El proceso de generación es el siguiente:

1. Los documentos ingeridos se limpian y preprocesan
2. A REBELDE se utiliza el modelo para extraer relaciones de entidades de cada documento. REBEL, un seq2seq modelo basado en BART que realiza extracción de relaciones de extremo a extremo para más de 200 tipos de relaciones diferentes
3. Se crea un mapa de entidad-relación para cada documento. Cada uno de estos mapas de entidad-relación se incrusta utilizando el modelo de incrustación MiniLM-V2 (incrustaciones de 384 dimensiones),
4. Los embeddings de cada documento se agrupan utilizando algoritmos de agrupamiento de embeddings como HDBSCAN para obtener n grupos de documentos semánticamente similares
5. Estos grupos de documentos se proporcionan al LLM para generar pares de respuestas a consultas de múltiples saltos

También se puede proporcionar información adicional e instrucciones personalizadas si el usuario desea generar la consulta y las respuestas en un formato o estilo específico.

Conjunto de datos de evaluación

Estructura de datos principal para gestionar datos de verdad de terreno. La Conjunto de datos de evaluación La clase recibe datos de verdad terrestre y las salidas del agente (llamadas a herramientas, respuestas del agente, etc.) y estructura los datos sin procesar en un formato fácil de procesar para el proceso de validación posterior. Transforma el conjunto de datos de referencia (el conjunto de datos que contiene la verdad terrestre y las respuestas del agente para el mismo) en una lista de atributos que son importantes para la evaluación y que el motor de validación puede procesar fácilmente. El conjunto de datos de evaluación creado tiene un ID de conjunto de datos que se puede utilizar para extraer el conjunto de datos del almacén clave-valor de Couchbase, eliminando la necesidad de almacenar y gestionar el conjunto de datos localmente.

Motor de validación

Procesa el conjunto de datos de evaluación y realiza la evaluación del mismo. Está conectado con un catálogo de métricas que proporciona a los usuarios un conjunto completo de métricas para evaluar todas y cada una de las partes del sistema agéntico/RAG. El catálogo de métricas también está integrado con RAGAS, lo que brinda a los usuarios la flexibilidad de utilizar métricas de RAGAS si lo requieren. El motor de validación calcula las métricas para el conjunto de datos de evaluación y combina los resultados para formar un marco de datos (dataframe) interpretable junto con un índice promediado que ofrece a los usuarios una idea de qué tan bueno es el sistema en general.

Gerente de experimentos

Módulo central que conecta todos los demás componentes. Crea y gestiona experimentos de evaluación. Un experimento es una instancia individual de evaluación, que consta de una salida detallada y metadatos, junto con capacidades de seguimiento de código para proporcionar a los usuarios una perspectiva sobre los cambios que han realizado en su sistema agéntico entre dos experimentos.

El administrador de experimentos recibe los datos de evaluación y un conjunto de opciones de experimento que consisten en las métricas a utilizar y otra información sobre su sistema agéntico, y se conecta al motor de validación para evaluar el conjunto de datos y obtener las puntuaciones calculadas. A continuación, las puntuaciones se procesan y formatean para producir un informe de evaluación junto con los metadatos del experimento que le permiten inferir la evaluación y comparar diferentes experimentos.

El administrador de experimentos también ofrece a los usuarios la capacidad de iniciar una cadena de experimentos, donde cada experimento sucesivo realiza un seguimiento de los cambios en el agente a partir de su experimento padre. Permite a los usuarios desarrollar iterativamente sus agentes y comparar las evaluaciones realizadas en el mismo agente a lo largo de las versiones. Los metadatos de cada experimento contienen registros de diferencias de código, métricas promediadas y configuraciones que se pueden utilizar para analizar si un cambio mejoró el sistema agéntico o no.

Elegir las métricas correctas para tu sistema agéntico

Al evaluar un sistema agéntico, seleccionar las métricas correctas es fundamental para evaluar con precisión su rendimiento. La elección de la métrica influye directamente en cómo se interpreta el resultado y se realizan mejoras iterativas. Para los sistemas de IA, las métricas deben elegirse en función de las siguientes consideraciones:

Sistema Escribir

• Sistemas RAGEnfocarse en las métricas de recuperación (precisión, exhaustividad) y las métricas de generación (fidelidad, corrección de respuestas)
• Sistemas agénticosPriorizar la precisión en la llamada de herramientas, la coherencia lógica y la fidelidad de las respuestas

Usar Caso Requisitos

• Respuesta a preguntasEnfatizar la corrección y relevancia de las respuestas
• Recuperación de informaciónEnfocarse en la precisión y la recuperación del contexto
• Tareas de razonamientoPriorizar la coherencia lógica y la fidelidad

Técnico Consideraciones

• Costo de computaciónLas métricas basadas en incrustaciones son más pesadas que las basadas en tokens.
• Dependencias de la APILas métricas de LLM como juez requieren acceso a la API
• Procesamiento por lotesAlgunas métricas admiten la evaluación por lotes eficiente

Para facilitarle el proceso anterior, estas son cinco métricas que ofrecen el mejor resumen de qué tan bien funciona su sistema agéntico:

1. Herramienta ctodo exactitud: Evalúa si el agente utiliza las herramientas correctas con los parámetros adecuados.
2. Herramienta exactitudCompara las salidas de las herramientas con las salidas reales de referencia (ground truth). Mide qué tan precisas son las herramientas.
3. Agente respuesta exactitudEvalúa la exactitud de las respuestas del agente en comparación con la verdad fundamental. Mide la calidad de la respuesta general del agente.
4. Lógico coherenciaEvalúa el flujo lógico y el razonamiento en las respuestas de los agentes, ayuda a analizar la cadena de mando entre los agentes en un sistema y qué tan bien trabaja cada agente con los demás para responder a la consulta del usuario.
5. Responder fidelidad: Comprueba si la respuesta del agente es coherente con los resultados de las herramientas obtenidos por el agente.

La etapa final es el análisis: agregar resultados, calcular métricas y, de manera crucial, comprender dónde y por qué falló el agente. Aquí es donde la falta de estandarización y automatización en los pasos anteriores vuelve a atormentar al desarrollador. Depurar discrepancias, rastrear errores hasta su origen e iterar en el agente o en los datos es lento y propenso a errores.

Profundizando: interpretación eficaz de resultados

Ahora que has seleccionado las métricas adecuadas, ejecutado el experimento y obtenido los resultados, ¿qué sigue? ¿Cómo le das sentido a los números aparentemente aleatorios que has recopilado? Interpretar estos resultados es un paso crucial para comprender el comportamiento y el rendimiento de tu sistema. Existen varias estrategias eficaces para analizar el resultado, descubrir información y evaluar el impacto de los cambios que has realizado. Este paso transforma las métricas sin procesar en conocimiento procesable sobre las fortalezas, debilidades y áreas de mejora de tu agente.

Técnicas de análisis comparativo

Al comparar dos implementaciones o versiones de agentes diferentes:

Comparación de métricas lado a lado

• Promediar cada métrica en todos los casos de prueba para ambos agentes
• Calcula la mejora relativa entre los sistemas (por ejemplo: “El agente B muestra una mejora de 12% en la precisión de las llamadas a herramientas en comparación con el agente A”).
• Use gráficos de radar para visualizar el panorama de rendimiento multidimensional
• Identificar fortalezas complementarias (por ejemplo, “El Agente A se destaca en la selección de herramientas mientras que el Agente B produce respuestas más fieles”)

Análisis emparejado

• Comparar el rendimiento en consultas idénticas para identificar diferencias sistemáticas
• Calculate the percentage of queries where one agent outperforms the other
• Identify query types where performance differences are most pronounced

Example interpretation: “While Agent B has higher average tool call accuracy (0.87 vs 0.79), Agent A performs better on complex multi-step reasoning tasks, suggesting Agent B might use simpler but more reliable patterns.”

Distribution analysis approaches

Understanding the distribution of metric scores provides deeper insight than averages alone:

Histogram analysis

• Plot the distribution of scores for each metric
• Identify whether performance follows normal distribution or shows clustering/bimodality
• Compare the spread (variance) between different implementations

Quartile analysis

• Examine the 25th, 50th (median), and 75th percentiles
• A large gap between median and 75th percentile indicates inconsistent performance
• Focus improvement efforts on raising the bottom quartile

Example interpretation: “Agent A’s tool call accuracy has a bimodal distribution with peaks at 0.4 and 0.9, indicating it performs very well on some query types but struggles significantly on others. Agent B shows a narrower distribution centered at 0.75, indicating more consistent but less exceptional performance.”

Threshold-based analysis

Setting performance thresholds helps quantify success rates:

Success rate calculation

• Define acceptable thresholds for each metric (e.g., tool call accuracy > 0.85)
• Calculate the percentage of samples exceeding each threshold
• Identify which thresholds are most challenging to meet

Multi-criterion analysis

• Define success as meeting thresholds across multiple metrics simultaneously
• Calculate the percentage of samples meeting all criteria
• Identify the most common failing points

Example interpretation: “While 78% of Agent A’s responses meet our tool accuracy threshold of 0.9, only 62% simultaneously meet our answer faithfulness threshold of 0.85. This suggests the agent occasionally produces correct outputs through incorrect reasoning paths.”

By applying these analytical approaches to agentic metrics, you can develop a reasonable understanding of your system’s performance, make improvement decisions, and establish reliable quality standards for deployment. This systematic analysis helps move beyond simple metrics to truly understand the agent’s capabilities and limitations in different contexts.

Example: evaluating a data analysis agent

We tested this framework on a conversational agent designed to answer queries based on data stored in Couchbase. The agent takes in user questions, forwards the question to a NL2SQL++ tool that generates SQL++ queries to fetch the corresponding documents from the store, and generates a detailed answer and an analysis report for the user question using the retrieved documents.

For our evaluation, the agent was run on an AirBNB listings dataset which contains the details of AirBNB listings across the United States. Generated questions and reference answers on the data instances using the Synthetic Data Generator. Below given is a sample set of query answer pairs generated by the synthetic data generator:

[
  {
    "question": "What type of room is offered in the "Clean and quiet apt home by the park?"
    "answer": "The room type offered in the "Clean and quiet apt home by the park" is a Private room. This conclusion is based on the data retrieved from the Airbnb listings, where the specific entry for this listing name was queried to determine the type of accommodation provided. The data clearly indicates that the listing is categorized under the "Private room" type, meaning guests will have a private space within a shared property."
  },
  {
    "question": "What is the cancellation policy for the "Skylit Midtown Castle"?"
    "answer": "The cancellation policy for the "Skylit Midtown Castle" is moderate. This conclusion is drawn from the data retrieved from the Airbnb listings, where the specific entry for this listing name was queried to determine the cancellation terms. The data indicates that the listing follows a moderate cancellation policy, which typically allows for more flexibility compared to strict policies, offering guests the ability to cancel within a certain timeframe before the check-in date for a full refund."
  }
]

A set of 40 such query document pairs were generated for this particular experiment. The agent was run on these generated queries and the output was logged to create the evaluation dataset.

The evaluation dataset (golden dataset) consists of:

1. Questions: Questions generated on the dataset
2. Ground truth answers: The reference (correct) answers for the generated questions
3. Reference Context: The source of truth from which the queries were generated (Ground truth tool outputs)
4. Retrieved Context: The documents retrieved using the NL2SQL++ tool run on the generated queries (tool outputs)
5. Agent Responses: The agent’s responses given the query and the retrieved context

An experiment was created on this evaluation dataset using 3 metrics, semantic similarity, context precision and answer relevancy. Semantic similarity measures the embedding similarity between the retrieved and reference contexts. Context precision measures how precise the retrieved contexts are with respect to the query and the reference context. Answer relevancy measures how relevant the agent’s response is to the user query and the retrieved context.

The average metric scores along with the experiment metadata for this particular experiment is provided below. Here, “averaged” refers to the mean of each metric across the data points in the evaluation dataset:

A metric quality analysis table can help us to analyze how the overall agent performed across the evaluation dataset, using a threshold for each metric and the number of data points that yielded a score above the given threshold.

S.No	Metric	Threshold	Samples Above Threshold	Total Number of Samples	Accuracy(%)
1	Semantic Similarity	0.70	40	40	100.00
2	Context Precision	0.90	40	40	100.00
3	Answer Relevancy	0.70	37	40	92.50

In our evaluation, NL2SQL++ consistently demonstrated strong performance, with all 40 test samples achieving both semantic similarity and context precision scores above the predefined threshold. This indicates that the tool reliably captures user intent and accurately translates natural language queries into structured SQL.

The LLM responsible for generating final responses also performed exceptionally well. While 37 out of the 40 responses exceeded the metric threshold, the remaining 3 fell slightly below. This minor variance is expected, as LLMs inherently generate novel token sequences rather than replicating reference content line for line. Despite these deviations, the model maintained high answer accuracy across the board which if it hadn’t, we would have observed more significant metric drops.

Detailed experiment reports are available to inspect individual samples, including those that did not meet the threshold, providing insight into how much they deviated and the potential reasons why.

Conclusión

This framework has been built with the core requirement of providing users with a persistent method to evaluate AI systems across domains and use cases, making evaluation simpler by using a consistent format for data, automating data handling and creating example scenarios where real ones are hard to collect. It also tracks every step an agent takes, which helps when multiple agents work together. In the future, we expect these tools to keep improving by updating test cases as real-world needs change, generating easy-to-understand reports for everyone, and including checks to catch bias or unsafe behavior. By doing this, we can make sure that AI agents stay reliable, transparent and most importantly aligned with the developers’ needs.