D13 · L3 · 04 — L2 · AI Agent Architecture & Design in Supply ChainL2 · Arquitectura y Diseño de Agentes de IA en la Cadena

Agent evaluation frameworks: testing, red-teaming & performance benchmarkingFrameworks de evaluación de agentes: testing, red-teaming y benchmarks de desempeño

An agent that has not been tested under adverse conditions has not been evaluated — only demonstrated.

El agente que no se ha testeado bajo condiciones adversas no ha sido evaluado — solo demostrado.

01What it isQué es

Agent evaluation tests whether an agent's sequence of decisions holds up before it touches real operations, combining backtesting on history, simulation of rare conditions, shadow mode beside human experts and red-teaming with deliberately adverse scenarios.

La evaluación de agentes prueba si la secuencia de decisiones de un agente resiste antes de tocar la operación real, combinando backtesting con historia, simulación de condiciones raras, shadow mode junto a expertos humanos y red-teaming con escenarios deliberadamente adversos.

02Why it mattersPor qué importa

A demo shows what an agent does on a good day; evaluation shows what it does when the ERP says zero by mistake, which is when the expensive errors happen. Trustworthy AI requires test, evaluation, verification and validation across the life cycle, including under conditions different from those seen in development (NIST, 2023 — AI Risk Management Framework 1.0, NIST AI 100-1). Because an agent acts sequentially in a changing environment, its performance must be measured over trajectories, not single predictions (Russell and Norvig, 2021 — Pearson, Artificial Intelligence: A Modern Approach).

Una demo muestra lo que hace un agente en un buen día; la evaluación muestra lo que hace cuando el ERP marca cero por error, que es justo cuando ocurren los errores caros. Una IA confiable requiere prueba, evaluación, verificación y validación a lo largo del ciclo de vida, incluso en condiciones distintas a las vistas en desarrollo (NIST, 2023 — AI Risk Management Framework 1.0, NIST AI 100-1). Como un agente actúa de forma secuencial en un entorno cambiante, su desempeño debe medirse sobre trayectorias, no sobre predicciones aisladas (Russell and Norvig, 2021 — Pearson, Artificial Intelligence: A Modern Approach).

03How it is doneCómo se hace

1
Backtest on real history. Replay the last 12 months and compare the agent's fill rate, inventory and cost against what the team actually did.
2
Red-team with operations. Have planners and IT jointly design bad-data, supplier-failure and demand-spike scenarios, and log every failure mode found.
3
Run in shadow first. Let the agent decide without executing for several weeks and approve go-live only when agreement and divergences are understood.
1
Haz backtesting con historia real. Reproduce los últimos 12 meses y compara fill rate, inventario y costo del agente contra lo que el equipo realmente hizo.
2
Haz red-teaming con operaciones. Que planeadores y TI diseñen juntos escenarios de datos erróneos, falla de proveedor y picos de demanda, y registra cada modo de falla.
3
Opera primero en modo sombra. Deja que el agente decida sin ejecutar durante varias semanas y aprueba la salida a producción solo cuando entiendas coincidencias y divergencias.

04The concept in depthEl concepto a fondo

🔍Agent evaluation: how to know if an agent is reliable before production›
An AI agent making autonomous decisions must be rigorously evaluated before deployment. Unlike an ML model that predicts a number, the agent makes sequential decisions in a dynamic environment — making its evaluation significantly more complex.
📊The supply chain agent evaluation framework›
(1) Backtesting: what decisions would the agent have made in the last 12 months? (2) Simulation: run the agent in a simulator to test behaviors in exceptional conditions without operational risk. (3) Shadow mode: agent operates in parallel without executing — compare agent vs. human decisions. (4) Red-teaming: design the most adverse scenarios — incorrect ERP data, supplier failure, 3x demand spike, adversarial attacks.
🔢Red-teaming for supply chain agents›
Red-teaming identifies failure modes. Most frequent: (1) Incorrect data in source system. (2) Exceptional conditions not seen in training. (3) Adversarial attacks (deliberately manipulated data to force an incorrect decision).
🏆Intermediate vs. Advanced›
Intermediate: participates in evaluation exercises; reports unexpected behaviors.

Advanced: designs the evaluation framework; leads red-teaming; manages the agent production approval process.
🔍Evaluación de agentes: cómo saber si un agente es confiable antes de producción›
Un agente de IA que toma decisiones autónomas debe evaluarse con rigor antes de su despliegue. A diferencia de un modelo de ML que predice un número, el agente toma decisiones secuenciales en un entorno dinámico, lo que hace su evaluación significativamente más compleja.
📊El marco de evaluación de agentes de supply chain›
(1) Backtesting: ¿qué decisiones habría tomado el agente en los últimos 12 meses? (2) Simulación: ejecutar el agente en un simulador para probar su comportamiento en condiciones excepcionales sin riesgo operativo. (3) Shadow mode (modo sombra): el agente opera en paralelo sin ejecutar; se comparan las decisiones del agente con las del humano. (4) Red-teaming: diseñar los escenarios más adversos — datos incorrectos en el ERP, falla de proveedor, pico de demanda de 3x, ataques adversariales.
🔢Red-teaming para agentes de supply chain›
El red-teaming identifica modos de falla. Los más frecuentes: (1) datos incorrectos en el sistema fuente; (2) condiciones excepcionales no vistas en el entrenamiento; (3) ataques adversariales (datos manipulados deliberadamente para forzar una decisión incorrecta).
🏆Intermedio vs. Avanzado›
Intermedio: participa en los ejercicios de evaluación; reporta comportamientos inesperados.

Avanzado: diseña el marco de evaluación; lidera el red-teaming; gestiona el proceso de aprobación del agente para producción.

05In practiceEn la práctica

🔍Never deploy a supply chain agent in production without red-teaming›
Failure modes are frequently exceptional scenarios the agent was not explicitly designed to handle.
🔢Shadow mode is the most valuable evaluation phase before actual deployment›
It allows measuring the agreement rate vs. the human expert under real operating conditions — without the operational risk of deployment.
🔗Red-teaming must include operations experts — they know the most frequent adverse scenarios in real operations›
The technical team designs the incorrect data scenarios. The operations team designs the exceptional business scenarios.
📊Document detected failure modes and corrective actions — it is the agent safety history›
When the agent fails in production, the red-teaming history allows identifying if the failure mode was known or is new.
🔍Nunca despliegues un agente de supply chain en producción sin red-teaming›
Los modos de falla suelen ser escenarios excepcionales que el agente no fue diseñado explícitamente para manejar.
🔢El shadow mode es la fase de evaluación más valiosa antes del despliegue real›
Permite medir la tasa de coincidencia con el experto humano en condiciones reales de operación, sin el riesgo operativo del despliegue.
🔗El red-teaming debe incluir a expertos de operaciones: ellos conocen los escenarios adversos más frecuentes de la operación real›
El equipo técnico diseña los escenarios de datos incorrectos. El equipo de operaciones diseña los escenarios de negocio excepcionales.
📊Documenta los modos de falla detectados y las acciones correctivas: es el historial de seguridad del agente›
Cuando el agente falla en producción, el historial de red-teaming permite identificar si el modo de falla ya era conocido o es nuevo.

06Illustrative caseCaso ilustrativo

Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Illustrative case: Agent evaluation before deployment — manufacturing company
The team evaluates the agent in 3 phases before production deployment.
Evaluation phaseMethodCritical finding
Phase 1: Backtesting (12 months of historical data)The agent simulates its decisions over the last 12 months · Fill rate and DIO of agent vs. manual process are comparedAgent generated fill rate of 97.8% vs. 93.2% of the manual process · DIO: 28 vs. 32 days of the manual
Phase 2: Red-teaming (adverse scenarios)The team designs 12 adverse scenarios: incorrect ERP data, primary supplier failure, demand spike 3× the forecastCritical failure mode: when the ERP shows 0 units due to a data entry error, the agent automatically generates an emergency PO of 10,000 units
Phase 3: Shadow mode (6 weeks)Agent operates in parallel without executing · Team compares agent decisions with real buyer decisionsAgent would have taken 78% of the same decisions as the buyer · The 22% difference included the 3 cases of promotions not captured in the ERP
Result: Agent approved for production with 2 critical modifications: (1) verification in the WMS before issuing emergency POs, (2) integration of the promotional calendar as input. Without these modifications, estimated losses would have been $420K MXN in the first year.
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Caso ilustrativo: Evaluación del agente antes del despliegue — empresa manufacturera
El equipo evalúa el agente en 3 fases antes del despliegue en producción.
Fase de evaluaciónMétodoHallazgo crítico
Fase 1: Backtesting (12 meses de datos históricos)El agente simula sus decisiones de los últimos 12 meses · Se comparan el fill rate y el DIO del agente vs. el proceso manualEl agente generó un fill rate de 97.8% vs. 93.2% del proceso manual · DIO: 28 vs. 32 días del manual
Fase 2: Red-teaming (escenarios adversos)El equipo diseña 12 escenarios adversos: datos incorrectos en el ERP, falla del proveedor principal, pico de demanda 3× el pronósticoModo de falla crítico: cuando el ERP muestra 0 unidades por un error de captura, el agente genera automáticamente una OC de emergencia de 10,000 unidades
Fase 3: Shadow mode (6 semanas)El agente opera en paralelo sin ejecutar · El equipo compara las decisiones del agente con las decisiones reales del compradorEl agente habría tomado 78% de las mismas decisiones que el comprador · El 22% de diferencia incluyó los 3 casos de promociones no capturadas en el ERP
Resultado: El agente se aprobó para producción con 2 modificaciones críticas: (1) verificación en el WMS antes de emitir OC de emergencia y (2) integración del calendario promocional como insumo. Sin estas modificaciones, las pérdidas estimadas habrían sido de $420K MXN en el primer año.

07How it is measuredCómo se mide

🔍Agent Red-Teaming Coverage %›
Agent Red-Teaming Coverage %
(Critical failure modes with a test scenario designed and executed / Total critical failure modes identified) × 100
Benchmark: >80% of critical failure modes covered by red-teaming before deployment
⚠️ An agent deployed without red-teaming has unknown failure modes that can materialize in production with significant financial consequences.
📊Shadow Mode Decision Agreement Rate %›
Shadow Mode Decision Agreement Rate %
(Agent decisions in shadow mode that agree with human decisions / Total decisions for the period) × 100
Benchmark: 60–80% agreement rate is the acceptable range · >95% may indicate the agent only replicates the human without adding value · <40% indicates a poorly calibrated agent
🔑 The shadow mode agreement rate is the most direct indicator of agent quality — it shows if it would make the same decisions as the human expert.
🔍Agent Red-Teaming Coverage %›
Agent Red-Teaming Coverage % (cobertura de red-teaming)
(Modos de falla críticos con un escenario de prueba diseñado y ejecutado / Total de modos de falla críticos identificados) × 100
Benchmark: >80% de los modos de falla críticos cubiertos por red-teaming antes del despliegue
⚠️ Un agente desplegado sin red-teaming tiene modos de falla desconocidos que pueden materializarse en producción con consecuencias financieras significativas.
📊Shadow Mode Decision Agreement Rate %›
Shadow Mode Decision Agreement Rate % (tasa de coincidencia en modo sombra)
(Decisiones del agente en shadow mode que coinciden con las decisiones humanas / Total de decisiones del periodo) × 100
Benchmark: 60–80% de coincidencia es el rango aceptable · >95% puede indicar que el agente solo replica al humano sin agregar valor · <40% indica un agente mal calibrado
🔑 La tasa de coincidencia en shadow mode es el indicador más directo de la calidad del agente: muestra si tomaría las mismas decisiones que el experto humano.

08What you would useQué se usa

📌 Agent Evaluation
🟧Python — Gymnasium / RLlib›
Module: Supply Chain Agent Simulation Environment

Gymnasium and RLlib for simulating supply chain environments for agent evaluation and training.
🟦LangSmith (LangChain)›
Module: LLM Agent Evaluation + Tracing

LangSmith for backtesting and monitoring LLM agent behavior in production.
📌 Evaluación de agentes
🟧Python — Gymnasium / RLlib›
Módulo: Entorno de simulación para agentes de supply chain

Gymnasium y RLlib para simular entornos de supply chain con fines de evaluación y entrenamiento de agentes.
🟦LangSmith (LangChain)›
Módulo: Evaluación + trazabilidad de agentes LLM

LangSmith para backtesting y monitoreo del comportamiento de agentes LLM en producción.
The bottom lineEn corto

If you have not tried to break the agent, production will do it for you.

Si no intentaste romper al agente, producción lo hará por ti.

All D13 componentsTodos los componentes de D13D13 artifactsArtifacts de D13SCRA