Todo engagement da Tzar.Tech termina com 60 dias de overlap no on-call. Os dois times — o nosso e o do cliente — dividem o pager. No início, pensávamos nisto como gesto de boa vontade. Acabou sendo a fase mais importante do engagement.
Aqui está o porquê.
O que a suíte de evals não pega
A suíte de evals pega o que você pensou em testar. Por definição, não pega o que você não pensou.
Para a maioria dos sistemas com agentes IA em produção, os primeiros 60 dias expõem:
- Inputs que ninguém antecipou. Um usuário faz upload de um PDF de 400 páginas em búlgaro. Um cliente bate no endpoint com aspas HTML-escaped. Uma integração envia timestamps em microssegundos.
- Suposições de frequência que estavam erradas. Um caminho "raro" se revela ser 8% do tráfego. Um caminho "comum" se revela ser 0,1%.
- Latência de cauda que a carga do eval não reproduziu. p99 parece bem em 100 RPS nos load tests; em 250 RPS em produção, p99,9 dispara por causa de um connection pool que você dimensionou para a distribuição errada.
- Comportamentos de custo que emergem com prompts reais. Usuários reais fraseiam perguntas de jeitos que triplicam a contagem de tokens do prompt vs. seus prompts de eval sintéticos.
Estes não aparecem em nenhuma suíte de evals bem desenhada, porque a suíte de evals é um modelo do que você sabe. Os primeiros 60 dias são quando o sistema encontra a realidade.
O que o overlap no on-call de fato faz
Duas coisas, ambas importantes:
1. O time que está saindo ainda está conectado quando algo dá errado. Quando o novo sintoma aparece, o engenheiro que conhece o código está na call. Não num canal de Slack a dois fusos de distância — efetivamente paginado, olhando ativamente. O fix é entregue em vez de virar ticket.
2. O time que recebe aprende os modos de falha no contexto próprio. Eles são paginados. Percorrem o runbook (veja o runbook que acompanha cada agente). Escalam para nós quando precisam. Cada incidente vira um exercício guiado de operar o sistema, com os autores originais na linha.
No dia 60, o time que recebe lidou com incidentes suficientes para saber o que é difícil, o que é fácil, o que ignorar, e o que vale paginar um executivo.
O que não fazemos
Não cobrimos o on-call primário. Somos o secundário durante o overlap. O time do cliente é dono do sistema. Nosso papel é "o on-call sênior que pode responder 'isto é normal' e 'qual é o caminho seguro aqui.'"
Isto importa: se cobríssemos o primário, o time do cliente nunca desenvolveria o músculo. Eles nos paginariam primeiro, sempre, e no dia 60 ainda estariam dependentes. O overlap é uma janela de ensino, não um serviço.
O que os dados dizem
Mantemos estatísticas sobre isto entre engagements. A forma é consistente:
- Primeiras duas semanas: aproximadamente metade dos pages chega até nós. A maioria são esclarecimentos, não incidentes reais.
- Semanas 3–4: aproximadamente um quarto chega até nós. O time do cliente internalizou diagnósticos comuns.
- Semanas 5–8: menos de 10% chegam até nós. Os que chegam são modos de falha genuinamente novos que valem mudança de código.
Após 60 dias, o engagement mediano nos pagina uma vez por mês no trimestre seguinte, e quase nunca depois. O sistema é deles.
Por que 60 dias, não 30
Tentamos 30 uma vez. Não foi suficiente.
Vários modos de falha só aparecem em fronteiras de mês (ciclos de billing, jobs em batch mensais, cargas de relatório de fim de trimestre). Um overlap de 30 dias pode terminar sem nunca encontrá-los, deixando o time do cliente cego para uma categoria de problemas que vai acontecer, eventualmente, quando não houver backup sênior para ligar.
60 dias pega as falhas de fronteira de mês e dá ao time que recebe um segundo mês inteiro para lidar com elas sozinho com a gente como backup. Não é simétrico e não é arbitrário — é o que descobrimos ser suficiente para transferir posse genuinamente.
Quanto isto custa e por que fazemos
Sessenta dias de on-call secundário é tempo real de engenharia que não cobramos separadamente. Embutimos no preço do engagement. Alguns clientes não acreditam quando dizemos que é obrigatório — insistimos mesmo assim, e os que tentam pular geralmente nos chamam de volta no mês dois pedindo para voltarmos como consultores.
Preferimos ficar 60 dias da primeira vez.