Ogni engagement Tzar.Tech si chiude con 60 giorni di overlap on-call. Entrambi i team — il nostro e quello del cliente — condividono il pager. All'inizio lo consideravamo un gesto di buona volontà. Si è rivelato la fase più importante dell'engagement.
Ecco perché.
Cosa non cattura la suite di evals
La suite di evals cattura ciò che ha pensato di testare. Per definizione, non cattura ciò che non ha pensato.
Per la maggior parte dei sistemi con agenti IA rilasciati in produzione, i primi 60 giorni fanno emergere:
- Input che nessuno aveva previsto. Un utente carica un PDF di 400 pagine in bulgaro. Un cliente colpisce l'endpoint con virgolette HTML-escaped. Un'integrazione invia timestamp in microsecondi.
- Assunzioni sulla frequenza che erano sbagliate. Un percorso "raro" si rivela essere l'8% del traffico. Un percorso "comune" si rivela essere lo 0,1%.
- Latenza di coda che il carico degli eval non riproduceva. La p99 sembra buona a 100 RPS nei load test; a 250 RPS in produzione, la p99.9 spike a causa di un connection pool dimensionato per la distribuzione sbagliata.
- Comportamenti di costo che emergono sotto prompt reali. Gli utenti reali formulano le domande in modi che triplicano il conteggio dei token rispetto ai suoi prompt sintetici di eval.
Queste cose non compaiono in nessuna suite di evals ben progettata, perché la suite di evals è un modello di ciò che lei sa. I primi 60 giorni sono quando il sistema incontra la realtà.
Cosa fa davvero l'overlap on-call
Due cose, entrambe importanti:
1. Il team uscente è ancora collegato quando le cose vanno male. Quando compare il nuovo sintomo, l'ingegnere che conosce il codice è in chiamata. Non in un canale Slack a due fusi orari di distanza — davvero svegliato, attivamente al lavoro. Il fix viene rilasciato invece di diventare un ticket.
2. Il team ricevente impara le modalità di fallimento nel proprio contesto. Vengono svegliati. Seguono il runbook (veda il runbook che esce con ogni agente). Escalano a noi quando serve. Ogni incident diventa un esercizio guidato nell'operare il sistema, con gli autori originali in linea.
Al giorno 60, il team ricevente ha gestito abbastanza incident da sapere cosa è difficile, cosa è facile, cosa ignorare, e per cosa vale la pena svegliare un dirigente.
Cosa non facciamo
Non gestiamo l'on-call primario. Durante l'overlap siamo secondari. Il sistema è del team del cliente. Il nostro ruolo è "il senior on-call che sa rispondere alla domanda 'è normale' e 'qual è il percorso sicuro qui.'"
Questo conta: se tenessimo il primario, il team del cliente non svilupperebbe mai il muscolo. Sveglierebbero noi per primi, ogni volta, e al giorno 60 sarebbero ancora dipendenti. L'overlap è una finestra di insegnamento, non un servizio.
Cosa dicono i dati
Abbiamo tenuto statistiche su questo per gli engagement. La forma è coerente:
- Prime due settimane: circa metà dei page raggiungono noi. La maggior parte sono chiarimenti, non incident veri.
- Settimane 3–4: circa un quarto raggiungono noi. Il team del cliente ha interiorizzato le diagnosi comuni.
- Settimane 5–8: meno del 10% raggiungono noi. Quelle che lo fanno sono modalità di fallimento genuinamente nuove che meritano una modifica al codice.
Dopo 60 giorni, l'engagement mediano ci sveglia una volta al mese per il trimestre successivo, e quasi mai dopo. Il sistema è loro.
Perché 60 giorni, non 30
Abbiamo provato 30 una volta. Non bastavano.
Diverse modalità di fallimento si manifestano solo a cavallo di un mese (cicli di fatturazione, batch mensili, carichi di reporting di fine trimestre). Un overlap di 30 giorni può chiudersi senza incontrarle, lasciando il team del cliente cieco a una categoria di problemi che accadranno, prima o poi, quando non ci sarà un backup senior da chiamare.
60 giorni catturano i fallimenti a cavallo di un mese e danno al team ricevente un secondo mese intero per gestirli da soli, con noi come backup. Non è simmetrico e non è arbitrario — è ciò che abbiamo trovato sufficiente per trasferire davvero la titolarità.
Cosa costa e perché lo facciamo
Sessanta giorni di on-call secondario sono tempo di engineering reale che non fatturiamo separatamente. Lo includiamo nel prezzo dell'engagement. Alcuni clienti non ci credono quando diciamo che è obbligatorio — insistiamo comunque, e quelli che provano a saltarlo di solito ci richiamano al secondo mese chiedendoci di tornare come consulenti.
Preferiamo restare 60 giorni la prima volta.