Cliente. El equipo de modernización de aplicaciones de un hyperscaler global de cloud, que construye agentes de IA para migrar, diagnosticar y optimizar sistemas de sus clientes, y necesita decidir con criterio verificable cuáles de esos agentes llegan a producción.
Enfoque
Este es el primer caso del portfolio donde el cuarto eslabón —la IA sobre el dato— no es el instrumento con el que trabajo sino el producto entregado. Recorre tres eslabones: ingeniería de software, ingeniería de datos e IA. La distinción respecto de los casos anteriores es deliberada: acá lo que se construye es la infraestructura con la que otro equipo evalúa a sus propios agentes.
La tesis que gobierna el trabajo es que un agente no se promueve a producción por impresión. Una demo convincente no es evidencia; una métrica de LLM aislada tampoco lo es, porque no dice nada sobre el impacto para el negocio ni sobre si el evaluador automático coincide con un especialista del dominio. Para que la decisión sea defendible hacen falta tres piezas encadenadas: evidencia capturada bajo un contrato estable, un juez calibrado contra un humano experto, y una regla determinística que convierta esa evidencia en una decisión de promoción. Sin las tres, la gobernanza de agentes queda en el terreno de la opinión.
El problema detectado
Evaluar un agente es distinto de evaluar un modelo. El agente llama herramientas, muta memoria y encadena turnos; la respuesta final es apenas la punta visible de un recorrido que puede haber fallado en cualquier tramo. Dos consecuencias prácticas:
- La evidencia queda atada al runtime. Cada framework de agentes registra sus pasos a su manera, así que las corridas dejan de ser comparables entre sí y entre versiones. Sin comparabilidad no hay medición, solo anécdotas ordenadas cronológicamente.
- La métrica técnica no llega a la mesa de decisión. Un puntaje de calidad no responde la pregunta que hace quien decide: si desplegamos esta versión, ¿qué cambia por cada 1.000 interacciones, y con qué incertidumbre?
El problema declarado era medir agentes. El problema real era anterior: no existía un contrato de evidencia que sobreviviera al cambio de runtime, ni un puente formal entre la métrica del juez y la decisión de liberación.
Relevamiento funcional
Antes de escribir el motor de evaluación definí qué es una evidencia y en cuántos niveles se captura. Los contratos son inmutables y están tipados con Pydantic v2, de modo que la evaluación se desacopla del runtime del agente y la trazabilidad se conserva comparable entre corridas:
| Nivel de evidencia | Qué captura | Qué habilita |
|---|---|---|
OUTPUT | La respuesta final del agente | Comparación de calidad extremo a extremo entre versiones y entre agentes |
STEPS | Llamadas a herramientas y transiciones de memoria del recorrido | Diagnóstico de causa raíz: en qué tramo se rompió, no solo que se rompió |
TELEMETRY | Trazas OpenTelemetry multi-turno de la ejecución | Correlación temporal, rendimiento y reconstrucción de la corrida completa |
Fijar los tres niveles primero, y recién después el motor que los consume, es lo que evita que la plataforma quede acoplada a la herramienta de agentes que estaba de moda el mes en que se escribió.
Construcción de la solución técnica
La plataforma ejecuta, observa, compara y evalúa agentes. Las piezas:
- Ejecución y observabilidad. Integré el runner de Google ADK con instrumentación OpenTelemetry, capturando llamadas a herramientas, transiciones de memoria y trazas multi-turno. La evaluación de calidad se apoya en Vertex AI Gen AI Evaluation Service.
- Motor de valor. Construí el componente que convierte métricas técnicas de LLM en impacto estimado por cada 1.000 interacciones y por segmento. La estimación no se publica como un número seco: lleva bootstrap Monte Carlo estratificado de 1.000 muestras y un intervalo de confianza al 90%, porque una estimación sin banda de incertidumbre es una afirmación disfrazada de dato.
- Compuerta de promoción. Sobre ese motor corre un árbol determinístico de cuatro estados —
BLOCKED,UNCALIBRATED,HOLD,PASS— que se recorre en orden y gobierna la promoción de agentes. Determinístico es el punto: la misma evidencia produce siempre la misma decisión, y la decisión se puede auditar después. - Backend y rendimiento. Gateway REST asíncrono en FastAPI con SQLAlchemy async para orquestar benchmarks concurrentes. Eliminé cuellos de botella de I/O con caché en memoria y búsquedas O(1) en la comparación y la lectura de datasets.
- Interfaz de inspección. Dashboard React 18 / Vite con telemetría en tiempo real, inspección de deltas de memoria, correspondencia de invocaciones a herramientas y gráficos radar comparativos entre agentes. Los flujos críticos de inspección y gestión de corridas quedaron cubiertos con 27 pruebas unitarias de frontend.
- Despliegue. Contenerización con build multi-stage y despliegue en Cloud Run vía Cloud Build, con acceso autenticado por IAM.
Capa de información y datos
El gobierno del dato es la sustancia del producto, no un anexo:
- Calibración del juez. Implementé un servicio de acuerdo entre anotadores con Cohen’s kappa corregido por azar y bandas de confianza, para auditar cuánto coincide la evaluación LLM-as-a-judge con la línea de base de un especialista del dominio. Un juez automático que nadie contrastó contra un humano es un generador de números, no un evaluador.
- Residencia y minimización. La ejecución se restringe a una región definida y el flujo incorpora sanitización de PII antes de que el dato llegue al evaluador.
- Continuidad sin red. Fallbacks determinísticos permiten sostener las pruebas y la continuidad operativa sin dependencias de servicios externos, de modo que la suite no depende de la disponibilidad de un endpoint.
- Conjuntos de referencia. Preparé golden datasets para tres familias de casos de modernización: migración Java/Spring Boot hacia Cloud Run, diagnóstico Cloud SRE y optimización SQL/BigQuery. Sin conjunto de referencia estable no hay comparación entre versiones, solo la sensación de que esta anda mejor.
Una aclaración de honestidad: las cifras de impacto que produce el motor son estimaciones modeladas a partir de métricas técnicas, no ahorros auditados por un tercero. La plataforma expone el intervalo de confianza precisamente para que nadie las lea como otra cosa.
Cómo se condujo el trabajo
- Calidad como compuerta, no como intención. El pipeline corre una compuerta de calidad de cinco etapas con más de 150 pruebas backend y frontend, análisis estático y compilación estricta de TypeScript. Lo que no pasa las cinco etapas no llega al entorno desplegado.
- Especificación antes que código. Escribí en inglés el playbook de la práctica para montar proyectos agénticos con Spec-Driven Development: el mismo criterio que aplico en el resto de los casos —fijar el contrato antes de la implementación— llevado a un documento que otros equipos usan.
- Revisión y mentoría. Revisiones técnicas y acompañamiento a otros ingenieros sobre concurrencia, contratos de datos y escritura de especificaciones.
Qué prueba este caso
- IA como entregable, no como instrumento: el cuarto eslabón del método construido y desplegado, con contratos, calibración y compuerta.
- Gobernanza operacionalizada: la decisión de promover un agente vive en un árbol determinístico y auditable, no en un comité que mira una demo. Es la misma tesis de gobernanza-como-infraestructura que sostengo en el resto del portfolio, aplicada al objeto más difícil de gobernar.
- Ingeniería de plataforma completa: contratos tipados, backend asíncrono, observabilidad, frontend de inspección, contenerización y despliegue en cloud, con una compuerta de calidad que hace verificable todo lo anterior.