Fale enquanto ele trabalha: por que nosso agente aceita interrupções

Uma testadora inicial estava no meio de uma tarefa longa quando digitou uma correção no chat — sem parar nada. Depois ela nos contou que o momento foi surpreendentemente bom: a outra ferramenta de agente que ela usa a obriga a parar a execução primeiro antes de aceitar uma mensagem nova. "Ter que pará-lo só para falar com ele parecia bobagem", ela disse, "comparado com isso."

Ela tem razão, e a diferença não é um capricho pequeno de UX. Ela vem de uma decisão de design que tomamos cedo e seguimos reaplicando: um agente é um colega, não uma máquina. Você interrompe um colega no meio de uma frase e ele incorpora. Você não desliga e liga ele de novo.

Por que "pare primeiro" é o padrão errado

Fazer o usuário interromper uma execução antes de falar tem três custos, todos pagos pelo usuário:

• A correção chega tarde demais. O momento em que você percebe o agente saindo da rota é exatamente quando você deveria falar. Forçar a parada significa assistir ele queimar tempo e tokens no caminho errado enquanto você procura o botão de parar.
• Parar destrói o estado. Uma execução interrompida não retoma — você recomeça do zero ou, pior, recebe um toco de "cancelada" e precisa explicar o contexto de novo. Sua correção de rumo em pleno voo custa todo o trabalho já em andamento.
• Inverte quem serve a quem. "A máquina não pode te ouvir agora, volte depois" é a conveniência da máquina, não a sua.

Como o nosso funciona de verdade

Quando você envia uma mensagem enquanto uma execução está em andamento, três coisas acontecem em ordem:

1. Suas palavras são salvas primeiro. A mensagem cai no histórico da conversa imediatamente — antes de qualquer despacho. Sua intenção fica durável a partir daquele instante; nenhuma fila, buffer ou timing pode perdê-la.
2. Ela é entregue na próxima fronteira de passo. O agente não larga o que está fazendo no meio de uma chamada de ferramenta — ele lê sua mensagem na próxima pausa natural, do jeito que uma pessoa termina um raciocínio e então absorve o seu ponto.
3. Ele ajusta o rumo, não recomeça. Tudo que a execução já fez permanece. Sua mensagem é uma correção de rota aplicada a uma tarefa em movimento, não um reboot.

O princípio por baixo: a durabilidade da intenção do usuário vem acima da conveniência do sistema. Uma vez que as palavras estão salvas, tudo a jusante é timing — e timing pode ser tornado elegante. Intenção não salva não pode ser recuperada, ponto.

Como isso aparece na prática

O exemplo mais claro já é público. Na história do relógio, o pedido do founder mudou de direção duas vezes enquanto o agente trabalhava — "na verdade, faz uma versão em HTML", depois "empacota como um web app instalável." Cada interjeição chegou no meio da execução e curvou a trajetória. Ninguém apertou stop; o app entregue foi moldado por correções enviadas em pleno voo.

A versão sutil do dia a dia é mais sem graça e mais valiosa: você está dez mensagens dentro de uma tarefa de pesquisa, percebe que ele está montando a comparação errada, digita "compare com X em vez disso" — e vê ele virar sem perder as oito boas fontes que já tinha juntado.

O princípio viaja

Esta semana a mesma pergunta apareceu pelo outro lado: o que acontece quando nós interrompemos você — um restart de servidor para um deploy? A resposta honesta acabou sendo a mesma regra. Durante deploys, o servidor agora aceita injeções no meio da execução (suas palavras salvas sobrevivem e a próxima execução as retoma no contexto) e pausa apenas o início de novas execuções. Rejeitar uma entrada que o usuário já digitou seria a nossa conveniência se sobrepondo à sua intenção — a exata inversão que criticamos acima, só que vestida de ops.

Não estamos dizendo que isso é novidade — interrupções enfileiradas são como bons sistemas sempre funcionaram. Só é raro na UX de agentes, onde "pare a máquina para falar com ela" virou a norma sabe-se lá como. Ficamos felizes em ser o padrão chato e correto.