Cada engagement de Tzar.Tech termina con 60 días de solapamiento en on-call. Ambos equipos — el nuestro y el del cliente — comparten el pager. Al principio lo veíamos como un gesto de buena voluntad. Resultó ser la fase más importante del engagement.
Aquí está el porqué.
Lo que la suite de evals no captura
La suite de evals captura lo que pensó en probar. Por definición, no captura lo que no se le ocurrió.
Para la mayoría de los sistemas con agentes IA enviados a producción, los primeros 60 días sacan a la luz:
- Entradas que nadie anticipó. Un usuario sube un PDF de 400 páginas en búlgaro. Un cliente golpea el endpoint con comillas HTML-escapadas. Una integración envía timestamps en microsegundos.
- Suposiciones de frecuencia que estaban mal. Un camino "raro" resulta ser el 8% del tráfico. Un camino "común" resulta ser el 0,1%.
- Latencia de cola que la carga de evals no reprodujo. p99 parece bien a 100 RPS en pruebas de carga; a 250 RPS en producción, p99.9 se dispara por un connection pool que dimensionó para la distribución equivocada.
- Comportamientos de coste que emergen con prompts reales. Los usuarios reales formulan preguntas de formas que triplican el conteo de tokens del prompt frente a sus prompts sintéticos de eval.
Estos no aparecen en ninguna suite de evals bien diseñada, porque la suite de evals es un modelo de lo que sabe. Los primeros 60 días son cuando el sistema se encuentra con la realidad.
Qué hace en realidad el on-call solapado
Dos cosas, ambas importantes:
1. El equipo saliente sigue conectado cuando algo va mal. Cuando aparece el nuevo síntoma, el ingeniero que conoce el código está en la llamada. No en un canal de Slack a dos zonas horarias — realmente paginado, mirando activamente. El fix se entrega en lugar de convertirse en un ticket.
2. El equipo receptor aprende los modos de fallo en su propio contexto. Les paginan. Recorren el runbook (véase el runbook que entregamos con cada agente). Nos escalan cuando lo necesitan. Cada incidente se convierte en un ejercicio guiado de operar el sistema, con los autores originales en la línea.
Para el día 60, el equipo receptor ha gestionado suficientes incidentes como para saber qué es difícil, qué es fácil, qué ignorar y qué merece paginar a un ejecutivo.
Lo que no hacemos
No llevamos el on-call primario. Somos el secundario durante el solapamiento. El equipo del cliente es dueño del sistema. Nuestro rol es "el on-call senior que puede responder a '¿es esto normal?' y '¿cuál es el camino seguro aquí?'".
Esto importa: si llevásemos el primario, el equipo del cliente nunca desarrollaría el músculo. Nos paginaría primero, siempre, y al día 60 seguiría siendo dependiente. El solapamiento es una ventana de enseñanza, no un servicio.
Lo que dicen los datos
Hemos llevado estadísticas de esto a lo largo de los engagements. La forma es consistente:
- Primeras dos semanas: aproximadamente la mitad de las páginas nos llegan. La mayoría son aclaraciones, no incidentes reales.
- Semanas 3–4: aproximadamente un cuarto nos llega. El equipo del cliente ha interiorizado los diagnósticos comunes.
- Semanas 5–8: menos del 10% nos llega. Los que llegan son modos de fallo genuinamente nuevos que merecen un cambio de código.
Después de 60 días, el engagement mediano nos pagina una vez al mes durante el siguiente trimestre, y casi nunca después. El sistema es suyo.
Por qué 60 días y no 30
Probamos 30 una vez. No bastó.
Varios modos de fallo solo aparecen en límites de mes (ciclos de facturación, jobs batch mensuales, cargas de reporte de fin de trimestre). Un solapamiento de 30 días puede completarse sin haberlos encontrado nunca, dejando al equipo del cliente ciego ante una categoría de problemas que ocurrirá, antes o después, cuando no haya un respaldo senior al que llamar.
60 días captura los fallos de límite de mes y le da al equipo receptor un segundo mes completo para manejarlos solo con nosotros como respaldo. No es simétrico y no es arbitrario — es lo que hemos descubierto que basta para transferir genuinamente la propiedad.
Cuánto cuesta esto y por qué lo hacemos
Sesenta días de on-call secundario son tiempo real de ingeniería que no facturamos aparte. Lo metemos en el precio del engagement. Algunos clientes no nos creen cuando decimos que es obligatorio — insistimos igualmente, y los que intentan saltárselo suelen volver a llamarnos al segundo mes pidiéndonos que regresemos como consultores.
Preferimos quedarnos los 60 días la primera vez.