O dia em que nosso agente abriu o próprio bug

Uma pessoa pediu ao agente uma coisa banal, juntar as pontas de uma conversa, alinhar o próximo passo, fazer aquilo andar. No meio do caminho, uma ferramenta que ele precisava deu erro. Não foi um erro do modelo. Foi um cano genuinamente quebrado em algum lugar mais abaixo, do tipo que teria parado qualquer programa na hora.

Aqui está o que ele não fez. Ele não entrou em loop. Ele não alucinou um “tudo pronto!” animado por cima de uma tarefa que não tinha acontecido. Ele não enterrou a falha três camadas abaixo, num log que ninguém ia ler até terça-feira.

Ele disse pra pessoa, com todas as letras, que essa parte específica estava quebrada naquele momento. Então abriu um ticket, o bug, os passos pra reproduzir, o lugar exato onde tinha travado. Na manhã seguinte o fix estava mergeado, e a mesma conversa pegou a ponta de volta e terminou o trabalho. Ninguém no time digitou uma palavra num bug tracker.

Essa é a história inteira, e o resto deste texto é por que ela importa. O agente esbarrou numa ferramenta quebrada, pediu desculpas ao usuário, abriu o ticket sozinho, e de manhã o fix estava mergeado e ele simplesmente terminou o trabalho.

O que software normalmente faz quando uma ferramenta quebra

Imagina a versão normal, porque todo mundo já viveu ela.

Um programa chama uma coisa que não está lá. A chamada falha. E aí uma de duas coisas ruins acontece. Ou tudo desaba com um stack trace vermelho que não significa nada pra quem disparou aquilo, ou, pior na era da IA, ele finge. Devolve uma resposta confiante montada a partir do nada, porque devolver alguma coisa é o que ele foi treinado pra fazer, e uma falha é só um buraco constrangedor pra tapar.

Os dois resultados empurram o mesmo trabalho pra um humano. Alguém tem que perceber a falha. Alguém tem que ler o trace, entender, decidir que é real, achar o repositório certo, e descrever o que deu errado com clareza suficiente pra uma segunda pessoa conseguir consertar. Aí alguém tem que lembrar de dar sequência no pedido original, que a essa altura já sumiu da tela.

Esse repasse, de “uma ferramenta quebrou” pra “um humano está escrevendo o ticket”, é onde a confiabilidade morre, em silêncio. Não porque o bug era difícil. Mas porque ninguém estava na obrigação de carregá-lo do momento em que quebrou até o momento em que foi registrado.

O buraco é a atenção humana, e atenção é o recurso mais caro e mais interrompível que uma empresa tem. Uma ferramenta quebrada que precisa de uma pessoa pra ser notada é uma ferramenta quebrada que continua quebrada até alguém por acaso olhar.

O conserto ingênuo: mandar o agente ser honesto

O movimento óbvio de início é fazer o agente admitir a falha em vez de fingir sucesso. Isso é progresso de verdade, um sistema que diz “não consegui fazer essa parte” já é melhor do que um que mente com confiança.

Mas honestidade sozinha só muda o problema de lugar.

Agora a falha está visível, o que é bom, e ela está parada numa janela de chat, o que não é. A pessoa lê “não consegui completar esse passo”, dá de ombros e segue em frente, porque ela veio atrás de um resultado, não de um diagnóstico. O erro é honesto e órfão ao mesmo tempo. Não existe ticket. A próxima pessoa que disparar o mesmo fluxo bate na mesma parede e ganha o mesmo pedido educado de desculpas. O sistema é transparente sobre estar quebrado e não faz nada a respeito.

Um beco sem saída honesto continua sendo um beco sem saída. Nomear a falha é o piso, não o teto.

O que o agente de fato fez

A diferença na nossa história não é que o agente era mais inteligente. É que o agente tratou o erro como um problema dele pra encaminhar, do jeito que um bom colega faria.

Quando a ferramenta falhou, o agente leu o erro do jeito que ele lê qualquer outro resultado, como informação, não como o fim da linha. Ele viu que a falha era real e reproduzível, não um capricho de como a coisa tinha sido digitada. Ele falou a verdade pro usuário sobre o que não conseguia fazer, pra ninguém ficar esperando por uma promessa que ele não podia cumprir. E então, sem ninguém pedir, fez a coisa que um humano teria que lembrar de fazer: abriu o ticket, com detalhe suficiente pra um fix começar a partir dos passos, e não de um chute.

O agente esbarrou numa ferramenta quebrada, pediu desculpas ao usuário, abriu o ticket sozinho, e é essa última parte que muda a economia da coisa. A falha não ficou esperando um humano descobrir. Ela se anunciou, totalmente documentada, no instante em que aconteceu.

Durante a noite, uma sessão separada pegou o ticket, fez o fix e mergeou. E aqui está a parte que transforma um truque esperto num loop de verdade: de manhã, a mesma conversa, aquela que tinha travado na noite anterior, voltou, achou a ferramenta funcionando, e terminou o que a pessoa tinha pedido originalmente. O pedido do usuário e o fix do bug se fecharam na mesma thread, sobre o mesmo problema, sem uma corrida de revezamento de humanos no meio.

Por que um loop ganha de um alarme de incêndio

A maioria do monitoramento para no alarme. Algo quebra, uma notificação dispara, e agora um humano é responsável por tudo que vem depois do beep: triar, consertar, dar sequência, e lembrar do pedido original. O alarme é honesto. Ele também é só o começo do trabalho.

Um loop é diferente porque ele não termina no perceber. O agente que esbarrou na ferramenta quebrada foi o primeiro elo de uma corrente que incluiu abrir o ticket, consertar e terminar, e a corrente se fechou sem passar o bastão pra uma pessoa cansada às 23h.

O mecanismo que torna isso possível não tem nada de extraordinário, depois que você o enxerga. Um erro é só mais um resultado que o agente consegue ler. Um relatório de bug é só escrita estruturada, que é justamente a coisa em que esses sistemas são melhores. Uma sessão de fix é só mais uma tarefa que pode rodar enquanto o escritório está no escuro. E uma conversa que lembra onde parou pode retomar em vez de recomeçar. Nenhuma dessas peças é exótica. O que é novo é ligar todas num único circuito, pra que uma falha flua o caminho inteiro até um fix sem cair fora do loop no meio.

O sistema ingênuo pede pra um humano carregar a falha de “quebrou” pra “foi registrado” pra “foi consertado” pra “está pronto”. Cada um desses repasses é um lugar onde a bola é derrubada. O loop remove os repasses. O agente que achou o bug é o mesmo ator, atravessando sessões, que leva a coisa até o fim.

Um alarme de incêndio te diz que algo está errado. Um loop já está a caminho do conserto.

A virada: confiança se constrói de momentos como esse

Pensa no que te faz confiar uma coisa de verdade a um colega de trabalho.

Quase nunca é a resposta polida que ele dá quando você faz uma pergunta direta. É a vez em que ele bateu numa parede no seu projeto, te contou na lata em vez de esconder, descreveu exatamente o que deu errado pra não morder a próxima pessoa, e depois voltou e terminou a coisa que disse que ia terminar. Isso não é inteligência. Isso é ownership, carregar um problema até o fim em vez de largá-lo no segundo em que ele ficou inconveniente.

Essa é a régua pra um software que vai tocar operação de verdade. Não um modelo confiante quando as coisas dão certo, mas um sistema honesto quando as coisas dão errado, e responsável o bastante pra fechar o próprio loop. O agente que abriu o próprio bug não foi impressionante por ser esperto. Ele foi confiável porque, diante de uma falha, fez a sequência chata, responsável e sem glamour que um bom colega faz, e a pessoa que pediu ajuda acordou com um trabalho terminado e um fix que nunca precisou ir atrás.

O agente esbarrou numa ferramenta quebrada, pediu desculpas ao usuário, abriu o ticket sozinho, e de manhã o fix estava mergeado e ele simplesmente terminou o trabalho. Essa frase é curta. A confiança que ela conquista não é.

---

A gente está construindo isso na Apollo Space, software que assume a falha tanto quanto a vitória, fecha os próprios loops, e volta pra terminar o que começou. Se a parte mais exaustiva da sua semana é carregar as bolas que os outros derrubaram até a linha de chegada, esse é exatamente o trabalho que a gente acha que um sistema deveria fazer primeiro.