Módulo 8: Project The Reservo Agent In Production

Lo que tu agente todavía necesita

Descripción

Las seis lecciones anteriores entregaron un agente operado: instrumentado con trace_id y logging estructurado (M2), medido en costo y latencia modelada (M3/M4), gateado contra regresiones de forma con evidencia real (M5), y endurecido con un circuit breaker que recuerda entre runs (M6). Esta lección hace lo que la Lección 7 de agent-fundamentals M8 ya hizo una vez con el agente construido: cierra el mapa del ecosistema, ahora que la capa de operación está en la mano y no solo en la promesa del DISEÑO.md.

Vas a ver, ejecutado, el límite exacto de lo que el gate de esta guía puede y no puede juzgar — y, a partir de ahí, un recorrido por las guías vecinas que existen específicamente para llevar este mismo agente operado más allá de esa frontera: infraestructura e incidentes, calidad semántica de la respuesta, reducción real del costo, resiliencia genérica a fondo, y seguridad contra manipulación.

Conexión con el módulo

Esta lección no agrega ninguna disciplina nueva a la capa de operación — existe para ser explícita sobre las disciplinas que esta guía, por diseño, nunca cubrió, y por qué esa ausencia es una frontera trazada desde el DISEÑO.md, no un descuido. La Lección 8 cierra el capstone con el checklist de "listo para producción" que asume, con precisión, todo lo que esta lección traza.

Analogía: el restaurante sobrevivió el año, pero todavía es un solo local

El restaurante de la introducción de este módulo sobrevivió un año completo de servicio real: la inspección diaria, el contador, el cronómetro, el generador de respaldo, el protocolo de sustitución de chef — las cinco piezas de operación, funcionando juntas. Pero un restaurante que sobrevivió un año, con una sola cocina, todavía no es una cadena con inspección municipal de salubridad sobre todo el edificio (infraestructura e incidentes, no solo la cocina). Todavía no tiene un crítico gastronómico que confirme, plato por plato, que la comida sabe bien —no solo que llegó a la mesa con el plato correcto y a tiempo— (calidad semántica). Todavía no negoció con sus proveedores para bajar el costo de los ingredientes que el contador ya sabe medir (reducir el costo, no solo medirlo). Todavía no pasó la certificación completa de un cuerpo de bomberos que audita cada sistema de emergencia del edificio entero, no solo el generador de la cocina (resiliencia genérica, a fondo). Y todavía no tiene un guardia en la puerta que confirme que quien entra no viene a manipular al personal para que rompa el protocolo (seguridad). Ninguna de esas cinco cosas hace falta para que el restaurante sirva bien este año — pero todas hacen falta para que crezca más allá de él.

Ejemplo trabajado: el límite exacto del gate — pasa la forma, nunca juzga el tono

Antes de nombrar las guías vecinas, vale la pena ver, ejecutado, el límite más concreto y menos discutible de todo este capstone: el gate de la Lección 5 nunca lee el texto final que el agente le muestra al usuario — solo la tool que eligió, la forma de su resultado, el valor exacto, el costo y la latencia.

import harness as hn

# Mismo guion que book_focus_pro_3h_ana -- misma secuencia de tools,
# mismo booking_id, PERO con una respuesta final deliberadamente cortante.
rude_script = [
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_01", "name": "list_rooms", "input": {}}]},
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_02", "name": "get_quote",
         "input": {"room": "Focus", "tier": "pro", "hours": 3}}]},
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_03", "name": "book_room",
         "input": {"room": "Focus", "tier": "pro", "hours": 3, "member": "Ana"}}]},
    {"stop_reason": "end_turn", "content": [
        {"type": "text", "text": "Ya. Dale."}]},
]

report = hn.run_regression_gate(hn.CASE_SET, overrides={"book_focus_pro_3h_ana": rude_script})
hn.print_gate_summary(report)

Qué esperar:

=== GATE: PASS (5/5) ===
  quote_focus_pro_3h                     PASS
  quote_focus_basic_3h                   PASS
  book_focus_pro_3h_ana                  PASS
  book_boardroom_pro_1h_sofia            PASS
  book_and_cancel_studio_basic_1h_diego  PASS

PASS (5/5) — el gate no notó absolutamente nada distinto. Y tiene toda la razón en no notarlo: run_case (M5) nunca lee final["content"][0]["text"] — solo inspecciona la tool elegida, el schema del resultado, el valor exacto de book_room, el costo y la latencia, ninguno de los cuales cambió. "Ya. Dale." es, para las cuatro comparaciones deterministas de este gate, una respuesta tan válida como "Reservé Focus pro 3h para Ana. Confirmación #1." — porque ninguna de las dos preguntas que este gate sabe contestar es "¿la respuesta suena profesional?". Si v2 de la Lección 5 hubiera introducido este mismo cambio de tono en vez de saltarse la cotización, el gate de esta guía lo habría dejado pasar sin ninguna alarma — no por un descuido de diseño, sino porque esa pregunta, con toda intención, nunca estuvo en su alcance.

Las cinco guías vecinas

Esta guía opera el agente que agent-fundamentals construyó. A su alrededor hay cinco guías hermanas más, cada una tomando ese mismo agente operado y llevándolo más lejos en una dirección que esta guía, por diseño, nunca cubrió:

agents-in-production  ← ESTA GUÍA (operar: observar, medir, gatear, endurecer+versionar)
   │
   ├─► sre-and-incident-response
   │     Infraestructura, no aplicación: SLI/SLO de un Lambda y una API,
   │     Prometheus/Grafana/CloudWatch, el ciclo de vida de un incidente
   │     con roles y severidades, postmortems sin culpa. Esta guía opera
   │     UN run del agente; esa guía opera la infraestructura completa
   │     que sostiene a miles de runs a la vez.
   │
   ├─► evaluation-frameworks
   │     Calidad SEMÁNTICA de la respuesta: trajectory evaluation,
   │     tool-call accuracy JUZGADA, LLM-as-judge, datasets dorados,
   │     evaluation CI/CD. El ejemplo trabajado de esta lección hizo
   │     visible exactamente el hueco que esa guía llena.
   │
   ├─► cost-optimization-caching
   │     REDUCIR el costo: prompt caching, selección de modelo por
   │     costo, batching, tiered optimization. Esta guía mide el costo
   │     (M3) como una señal más -- nunca enseña a bajarlo.
   │
   ├─► resilience-and-reliability-patterns
   │     Patrones de resiliencia genéricos, a fondo: bulkheads,
   │     degradación elegante, load shedding, backoff+jitter aleatorio
   │     real, medidos con exhaustion de threads y retry storms, para
   │     cualquier dependencia HTTP -- no solo la capa de tool-calls de
   │     un agente que M6 de esta guía endureció.
   │
   └─► agent-security-and-sandboxing
         Endurecer el agente contra usuarios malintencionados: inyección
         de prompt, mínimo privilegio, sandbox, human-in-the-loop,
         guardrails, secretos. Esta guía asume el agente ya endurecido
         contra fallos de infraestructura -- nunca contra manipulación.

Y, como ya trazó agent-fundamentals M8 (Lección 7), los componentes del agente —memoria de largo plazo, RAG, context engineering, MCP, orquestación multi-agente— siguen viviendo en sus propias guías hermanas. Esta guía los opera como parte de un run cuando existen (los mide, los loguea) — nunca los construye ni profundiza en ellos.

Dos fronteras que conviene tener presentes, porque son las más fáciles de confundir

Costo: medir (esta guía) contra reducir (cost-optimization-caching-guide). M3 de esta guía se detiene en "cuánto costó este run y por qué" — nunca en "cómo bajarlo". Si la pregunta cambia a "¿deberíamos cachear este prompt del sistema?" o "¿un modelo más chico resolvería este caso igual de bien y más barato?", esa pregunta pertenece, sin ambigüedad, a la guía hermana.
Resiliencia: la capa de tool-calls de un agente (M6 de esta guía) contra sistemas distribuidos genéricos (resilience-and-reliability-patterns-guide). El CircuitBreaker de M6 protege una tool específica de un agente, con backoff modelado y determinista. Esa guía construye el mismo vocabulario —citado, nunca repetido— a una escala completamente distinta: cualquier dependencia HTTP de un sistema distribuido, con jitter aleatorio real y medido con miles de clientes simulados.

Cómo usar este mapa

No hace falta recorrer las cinco guías vecinas para que este capstone haya cumplido su promesa: ya sabes instrumentar, medir, gatear y endurecer un agente que ya funciona. Las guías vecinas están para cuando la operación de tu agente choque, de verdad, con el límite específico que cada una resuelve:

¿Necesitas alertar sobre la tasa de error de un servicio, o escribir un postmortem sin culpa? → SRE e incidentes, sin excepción.
¿La pregunta real es si la respuesta del agente es clara, correcta y bien razonada — no solo si su forma no se rompió? → evaluation frameworks.
¿El costo medido en M3 ya es una preocupación real de presupuesto, y necesitas bajarlo? → cost optimization & caching.
¿Necesitas bulkheads, degradación elegante o load shedding para un sistema distribuido completo, no solo una tool de un agente? → resilience & reliability patterns.
¿Vas a exponer el agente a usuarios reales o a entradas no confiables? → agent security & sandboxing, sin excepción.

La misma regla que sostuvo cada módulo de esta guía —agregar una capacidad solo cuando la tarea la necesita, no "por si acaso"— vale también a esta escala del ecosistema completo.

Errores comunes

Pensar que "el gate pasó" significa "la respuesta del agente es buena". El ejemplo trabajado de esta lección lo desmiente con evidencia ejecutada: un texto cortante y poco profesional pasa el gate exactamente igual que uno cuidadoso, porque el gate nunca inspecciona el texto. "Pasó el gate" significa, con precisión, "la forma no se rompió" — nunca "la calidad es aceptable".
Confundir la validación de umbrales de costo/latencia (M5) con optimización de costo real. check_cost_threshold confirma que un run se mantuvo bajo un presupuesto conocido — no reduce ese presupuesto. Bajar el costo real (caching, selección de modelo) es, sin excepción, trabajo de cost-optimization-caching-guide.
Pensar que el CircuitBreaker de M6 "ya es" resiliencia completa de un sistema distribuido. Protege una tool de un agente, con datos deterministas — no construye bulkheads, no mide exhaustion de pool de threads, no usa jitter aleatorio real. Esa profundidad completa vive, íntegra, en resilience-and-reliability-patterns-guide.
Saltar directo a agent-security-and-sandboxing o evaluation-frameworks sin haber operado primero un agente con esta guía. Ambas se apoyan en entender bien qué significa observar, medir y gatear un run — sin esa base, el vocabulario de esas guías se siente como una capa aislada, en vez de una extensión razonada de lo que ya construiste.
Adoptar las cinco guías vecinas a la vez, "para curarse en salud". La misma disciplina que sostuvo cada módulo de esta guía —una capacidad a la vez, verificada antes de seguir— vale para el ecosistema completo. Adoptar SRE, evaluación semántica, reducción de costo, resiliencia genérica y seguridad simultáneamente, sin haber sentido la necesidad concreta de cada una, multiplica la complejidad sin necesariamente multiplicar el valor.

Ejercicios

Ejercicio 1: ¿Qué guía lo resuelve? (Fácil)

Para cada necesidad, nombra la guía vecina correcta: (a) "necesito saber si el 99% de mis runs de Reservo responden en menos de 2 segundos, medido con el reloj real de producción"; (b) "necesito que un modelo evalúe si la explicación del precio que el agente le dio al cliente es clara y correcta"; (c) "el gasto mensual en tokens ya es significativo, quiero cachear el system prompt"; (d) "necesito defender al agente de un usuario que esconde instrucciones dentro de una reserva falsa".

Ver solución

(a) sre-and-incident-response-guide — latencia de infraestructura, medida con el reloj real, con SLI/SLO — no la latencia modelada de M4 de esta guía.

(b) evaluation-frameworks-guide — juicio semántico sobre la calidad de una respuesta, exactamente el hueco que el ejemplo trabajado de esta lección hizo visible.

(c) cost-optimization-caching-guide — reducir el costo con prompt caching, no solo medirlo como hace M3 de esta guía.

(d) agent-security-and-sandboxing-guide — defensa contra inyección de prompt, un tipo de manipulación que ninguna validación de forma de esta guía cubre.

Ejercicio 2: Esta guía o una vecina (Medio)

Contrasta cada capacidad que este capstone SÍ tiene con la capacidad vecina relacionada que NO tiene: (a) el CircuitBreaker de M6 vs. bulkheads y load shedding; (b) check_cost_threshold (M5) vs. reducir el costo real; (c) rollout_decision (M7, comparación de forma) vs. un juez semántico que compare dos versiones.

Ver solución

(a) El CircuitBreaker de M6 (este capstone) protege una tool específica de un agente, con estado que persiste entre runs, sobre datos deterministas. Bulkheads y load shedding (resilience-and-reliability-patterns-guide) operan a nivel de sistema distribuido completo — aislar recursos entre distintas dependencias, descartar tráfico de forma controlada cuando el sistema entero está sobrecargado — un alcance mucho más amplio que una sola tool.

(b) check_cost_threshold (este capstone) confirma que un run se mantuvo bajo un presupuesto ya fijado — una comparación, no una optimización. Reducir el costo real (cost-optimization-caching-guide) cambia el presupuesto mismo: cachear un prompt repetido, elegir un modelo más barato para una tarea simple, agrupar llamadas en batch.

(c) rollout_decision (este capstone) compara, con ==, si v2 sigue eligiendo la misma tool y el mismo valor exacto que v1 en cada caso del CASE_SET — una comparación literal. Un juez semántico (evaluation-frameworks-guide) compararía si la calidad de la respuesta de v2 es igual, mejor o peor que la de v1 — una pregunta que ningún == puede contestar, y que esta guía, con toda intención, nunca intenta responder.

Ejercicio 3: Traza el camino de Reservo hacia una operación de nivel empresarial (Difícil)

El agente de Reservo de este capstone va a atender miles de reservas reales por día, con un equipo de guardia rotando turnos, un presupuesto de tokens que ya preocupa a finanzas, y la exigencia de que las respuestas suenen profesionales sin excepción. Ordena qué guías recorrerías, en qué secuencia, y justifica el orden.

Ver solución

Un orden razonable, de la base hacia afuera:

agents-in-production-guide, completa (M1-M8). Ya la tienes: el agente instrumentado, medido, gateado y endurecido, con rollout seguro. Sin esto, ninguna de las guías siguientes tiene sobre qué apoyarse.
sre-and-incident-response-guide, para el equipo de guardia y la infraestructura. "Miles de reservas por día" y "un equipo rotando turnos" son, con precisión, el lenguaje de SLI/SLO, roles de incidente y postmortems — la capa de infraestructura que sostiene el volumen que este capstone nunca necesitó simular.
evaluation-frameworks-guide, para "que las respuestas suenen profesionales sin excepción". El ejemplo trabajado de esta lección mostró, con evidencia, que el gate de esta guía nunca certifica el tono. Con volumen real, esa certificación deja de ser opcional.
cost-optimization-caching-guide, para el presupuesto que ya preocupa a finanzas. M3 de esta guía ya mide el costo con precisión — el paso siguiente, una vez que el número preocupa de verdad, es reducirlo.

Por qué ese orden: operar primero, después dar soporte de infraestructura al volumen, después certificar la calidad que el volumen expone, después optimizar el costo que el volumen infla — cada guía se apoya en que la anterior ya esté resuelta. agent-security-and-sandboxing y resilience-and-reliability-patterns no aparecen en esta lista porque el escenario descrito no menciona usuarios malintencionados ni dependencias HTTP externas más allá de las tools ya endurecidas por M6 — agregarlas "por si acaso" repetiría, otra vez, el error que la sección "Cómo usar este mapa" advirtió no cometer.

Resumen y siguiente paso

Ejecutamos, con evidencia real, el límite más concreto de todo este capstone: el gate de la Lección 5 pasa 5/5 incluso con una respuesta final cortante y poco profesional, porque nunca inspecciona el texto — solo la tool, el schema, el valor, el costo y la latencia.
Recorrimos las cinco guías vecinas del ecosistema de operación: SRE e incidentes (infraestructura, no aplicación), evaluation frameworks (calidad semántica, el hueco exacto que el ejemplo trabajado hizo visible), cost optimization & caching (reducir, no solo medir), resilience & reliability patterns (resiliencia genérica a fondo, más allá de una tool), y agent security & sandboxing (endurecer contra manipulación, no solo contra fallos de infraestructura).
La regla de adopción se mantiene: esta guía completa es suficiente para el alcance que prometió; cada guía vecina se suma solo cuando tu agente operado choca, de verdad, con el límite específico que esa guía resuelve.

Siguiente lección: 08 — Proyecto: entrega el agente listo para producción. Cerramos el capstone y la guía completa con el checklist final y los cuatro artefactos generados de punta a punta en una sola corrida.

Recursos adicionales

Anthropic — Building effective agents — Sobre cuándo agregar complejidad operacional (más disciplinas, más guardas) y cuándo no — la misma pregunta que esta lección aplica a escala de ecosistema.
Anthropic — Tool use overview — El protocolo que sostiene tanto esta guía como sus cinco vecinas de operación.
evaluation-frameworks-guide — el índice completo de esa guía, para cuando el hueco que el ejemplo trabajado de esta lección mostró se vuelva una necesidad real.
Python — Scope y ciclo de vida de módulos — La misma base técnica que sostiene, en toda esta guía, por qué el estado de BOOKINGS o de un CircuitBreaker vive y muere con el proceso que lo aloja.

← AnteriorLa capa de resiliencia Siguiente →Proyecto: entrega el agente listo para producción