Projetando caminhos de escalação para agentes bloqueados

Um agente de código bloqueado é computação desperdiçada e momentum perdido. Sem um caminho claro de escalação, agentes bloqueados ou giram indefinidamente ou disparam alertas ruidosos que ninguém assume. Um design eficaz de escalação combina cada tipo de bloqueio ao respondedor humano certo, aplica timeouts apropriados e cria ciclos de feedback para os mesmos problemas pararem de recorrer.

Identificar tipos de bloqueio

Nem todos os bloqueios são iguais. Categorizá-los permite rotear cada um ao respondedor certo e definir níveis de urgência apropriados.

Bloqueios por dependência

O agente precisa de algo de outro time ou serviço—uma API que não está implantada, uma migração de banco que não rodou, ou uma atualização de biblioteca pendente de revisão. Bloqueios por dependência costumam ser os mais lentos de resolver porque cruzam fronteiras entre times.

Bloqueios por permissão

O agente não tem acesso a um recurso que precisa—um repositório, um vault de segredos, um ambiente de staging ou uma API key de terceiros. Bloqueios por permissão geralmente se resolvem rápido quando a pessoa certa é notificada, mas podem ficar horas se o pedido vai para uma fila genérica.

Bloqueios por ambiguidade

O agente não consegue prosseguir porque a especificação da tarefa é vaga, contraditória ou incompleta. Esses bloqueios exigem julgamento humano—um product owner ou tech lead precisa esclarecer a intenção antes do agente retomar.

Bloqueios por infraestrutura

O ambiente em si tem um problema—CI está fora do ar, um container falha ao construir, testes dão timeout por limites de recursos, ou uma partição de rede isola o agente dos serviços necessários. Bloqueios por infraestrutura frequentemente afetam múltiplos agentes simultaneamente.

Combinar bloqueios com respondedores

Cada tipo de bloqueio deve mapear para um papel ou pessoa específica, documentado em uma referência única que o time consiga encontrar sem buscar.

Bloqueios por dependência são roteados ao time dono do serviço bloqueante. Se esse time usa Dailybot, publique a escalação no canal deles com contexto para poderem priorizar.

Bloqueios por permissão são roteados ao líder do time ou admin de segurança que pode conceder acesso. Inclua o recurso específico e o motivo do acesso para o aprovador agir sem vai-e-vem.

Bloqueios por ambiguidade são roteados ao product owner, tech lead ou quem escreveu a especificação original. Inclua a interpretação do agente e a pergunta específica que não consegue resolver.

Bloqueios por infraestrutura são roteados ao time de plataforma ou DevOps. Inclua logs de erro, identificadores de ambiente e se outros agentes também estão afetados.

Configurar escalação baseada em timeouts

Timeouts previnem que bloqueios fiquem silenciosos. O timeout correto depende da criticidade da tarefa e do tipo de bloqueio.

Definir janelas de timeout

Um framework inicial razoável:

• Tarefas críticas (bloqueiam o sprint, relacionadas a produção): escalar após 30 minutos
• Tarefas padrão (trabalho de funcionalidades, refatoração): escalar após 1-2 horas
• Tarefas de baixa prioridade (melhorias desejáveis, documentação): escalar após 4 horas

Dentro dessas faixas, ajuste por tipo de bloqueio. Bloqueios por permissão costumam ter caminhos de resolução mais rápidos que bloqueios por dependência, então você pode definir um timeout mais curto para permissões (30 minutos) e mais longo para dependências (2 horas) mesmo no mesmo nível de prioridade.

Níveis de escalação

Projete pelo menos dois níveis. O primeiro nível notifica o respondedor designado via DM ou menção no canal. Se não houver resposta dentro de uma janela adicional de timeout, o segundo nível notifica um grupo mais amplo—um gerente, um canal de ops ou uma rotação de plantão.

Evite passar de três níveis. Se um bloqueio requer três escalações para receber atenção, o problema não é o sistema de escalação—é a cultura de resposta.

Construir ciclos de feedback

Escalação sem aprendizado é só apagar incêndio. Cada bloqueio resolvido é dado para prevenir o próximo.

Documentação pós-resolução

Após resolver um bloqueio, o respondedor ou agente deve registrar: o que causou o bloqueio, como foi resolvido, e se a correção é permanente ou temporária. Esses dados alimentam uma base de conhecimento que agentes e humanos podem consultar.

Rastreamento de recorrência

Rastreie quais tipos de bloqueio recorrem com mais frequência. Se bloqueios por permissão disparam três vezes ao mês para o mesmo recurso, invista em uma concessão de permissão permanente em vez de resolver cada um individualmente. Se bloqueios por ambiguidade se agrupam em uma área de produto específica, as especificações dessa área precisam de melhoria.

Aprendizado do agente

Alguns bloqueios podem ser prevenidos dando aos agentes melhor contexto desde o início. Se um agente consistentemente trava no mesmo tipo de setup de ambiente, adicione esse setup ao checklist de inicialização do agente. Se bloqueios por ambiguidade surgem da mesma informação faltante, inclua essa informação no template de tarefas.

Projetar o documento de escalação

Crie uma referência de uma página que o time consiga consultar em trinta segundos:

• Tipo de bloqueio (dependência, permissão, ambiguidade, infraestrutura)
• Primeiro respondedor (papel ou pessoa nomeada)
• Timeout até primeira escalação (minutos)
• Segundo respondedor (papel ou grupo)
• Timeout até segunda escalação (minutos)
• Método de notificação (DM, canal, pager)

Publique esse documento no seu canal de ops, vincule-o à configuração dos seus agentes e revise-o trimestralmente. Quando a estrutura do time mudar—novas contratações, rotações de papel, divisões de time—atualize o documento de escalação na mesma semana.

Tornar a escalação invisível

O melhor sistema de escalação é um que raramente dispara porque as causas subjacentes foram sistematicamente eliminadas. Use dados de escalação não como métrica de desempenho mas como sinal de onde investir em prevenção. Com o tempo, o objetivo não é escalação mais rápida—é que menos escalações sejam necessárias desde o início.