Execução e interrupção

Camada funcional

Enviar mensagem inicia uma execução. O passo a passo aparece ao vivo. Se o agente estiver ocupado ou esperando algo, a plataforma diz isso em vez de aceitar em silêncio. E, a qualquer momento, dá para mandar parar — e parar de verdade.

O que acontece ao enviar, conforme o estado da conversa

O caso de "esperando credencial" tem um cuidado extra: existe uma janela em que não há mais nem card para preencher nem pedido para cancelar — e sem essa recuperação automática, a conversa ficaria travada nesse estado para sempre. A mesma recusa também aparece quando falta um pré-requisito de integração (por exemplo, uma conexão que caiu), para não travar toda mensagem por um problema de configuração.

Parar uma execução

Parar é tratado como prioridade: a plataforma tenta garantir que a execução pare de verdade, mesmo quando o caminho normal de resposta não está funcionando. Um detalhe importa para quem usa: um pedido de parar que chega atrasado não cancela uma execução nova que já tinha começado depois dele — só a execução que estava rodando no momento em que o pedido foi feito.

Duas pausas diferentes de parar

Diferente de parar, há duas situações em que a execução espera e depois continua de onde parou: aprovação humana e preenchimento de credencial. Nos dois casos a sessão de trabalho é preservada — o agente não perde o fio quando alguém volta e decide.

Ocupação da janela de contexto e compactação

A plataforma mede, a cada turno, o quanto da capacidade de memória de uma conversa já está em uso.

O que a interface mostra: um indicador de ocupação com detalhamento por categoria (mensagens, ferramentas, memória, skills e espaço livre). A conta que fecha é: uso total mais espaço livre soma a capacidade máxima.

Correção (12/08/2026): o gatilho automático mudou de dono. Até então, a plataforma considerava compactar a conversa a partir de 80% de ocupação da janela — um limite fixo que disparava cedo demais e descartava contexto que ainda dava para aproveitar. Hoje quem decide quando compactar automaticamente é o próprio motor de execução do agente, que só age perto do limite real da janela, reservando uma margem de segurança para si mesmo; a plataforma não dispara mais essa compactação por conta própria.

O que continua exatamente como antes:

• A medição de fim de turno (o indicador de ocupação por categoria, mensagens/ferramentas/ memória/skills/espaço livre), que alimenta o popover de contexto e o botão "Liberar espaço".
• O diagnóstico de piso fixo: quando as mensagens são menos de 15% do total ocupado, compactar devolveria quase nada, e a interface continua explicando que o peso está na configuração do agente, não no histórico.

Compactação manual: dá para pedir para compactar a qualquer momento, pelo chat. Roda como uma operação separada, em segundo plano, com um teto de 120 segundos por tentativa. O marco visual de "conversa compactada" só aparece depois de confirmar que a janela realmente encolheu — não basta o pedido ter sido aceito. Corrigida em 12-13/08/2026 uma falha que deixava esse pedido preso em "compactando" para sempre.

Aviso quando o agente perde o fio

Em conversas muito longas, o agente pode continuar respondendo mas ir se afastando das instruções originais — sem erro, sem aviso, só gradualmente "esquecendo" o combinado. A plataforma detecta esse padrão e avisa antes do trabalho se perder, com uma faixa no topo da conversa.

O aviso liga automaticamente, sem configuração, e é calibrado para disparar depois de algumas respostas seguidas fora do combinado (por padrão, três) — não uma só, para não alarmar por um deslize pontual.

Cada organização pode desligar (20/08/2026). Até então o aviso era ligado ou desligado para a plataforma inteira, de uma vez — não havia como desligar para uma organização sem desligar para todas. Como a detecção funciona acrescentando uma instrução a todo agente da organização, quem não quer o aviso, ou prefere não gastar instrução com ele, agora desliga sozinho em Configurações da organização. As duas camadas precisam concordar para o aviso existir: o interruptor geral da plataforma segue valendo como desligamento de emergência, e a preferência da organização decide dentro do que ele deixa passar. As duas resolvem num só lugar, porque o valor é consultado em três momentos de uma mesma execução — quando a instrução é dada ao agente, quando o desvio é medido e quando o aviso aparece na tela — e divergir entre eles produz o pior dos dois desfechos: instrução dada sem medição (aviso que nunca dispara) ou medição sem instrução (aviso que dispara sempre). Falha ao ler a preferência da organização cai no padrão histórico: ligado.

O que isso não detecta: não é uma medida de "o histórico saiu da memória" — é uma medida de que o modelo parou de seguir a instrução, ainda que ela continue disponível para ele.

Duas saídas, e só na faixa do topo (02/09/2026)

Até 17/08/2026 o aviso oferecia uma única saída, "Iniciar nova conversa", que criava uma conversa vazia — quem clicava no meio de um trabalho recomeçava do zero. Em 18/08/2026 passaram a ser três, e uma delas exigia fechar uma janela que cobria a conversa antes de continuar lendo.

Em 02/09/2026 essa janela saiu, e com ela uma das três saídas. O mesmo alerta estava aparecendo em dois lugares ao mesmo tempo: a faixa no topo, que já traz as duas ações que fazem alguma coisa e fica à vista enquanto a situação durar, e uma janela por cima, que só acrescentava a interrupção — no meio de uma conversa que a pessoa estava lendo. A terceira saída era "Continuar aqui", que não fazia nada; e não fazer nada não precisa de botão quando nada está bloqueando o caminho.

Restam duas, na faixa, em ordem de custo:

1. Resumir a conversa (destaque) — a mesma compactação manual descrita acima. É a saída mais barata: resume o histórico e mantém a pessoa na mesma conversa. Fica desabilitada nas mesmas condições de sempre (conversa ocupada, sem histórico a resumir) e também quando o peso é conteúdo fixo do agente — nesse caso compactar devolveria pouco espaço, e o aviso não recomenda o que não resolve (o medidor de contexto, que já mostra o diagnóstico ao lado, continua permitindo mesmo assim).
2. Levar para uma conversa nova — vira um turno do próprio agente ("hand-off"): ele escreve o estado do trabalho e, quando o agente tem a capacidade de operar a própria plataforma, já cria a conversa nova e planta o resumo lá; sem essa capacidade, ele gera um documento e a pessoa recebe um link para baixar. Essa decisão (criar conversa vs. gerar arquivo) é definida no servidor, não pelo agente — evita a situação de o agente tentar uma ação que não tem disponível e anunciar uma conversa que não existe. Exige que a conversa esteja livre (sem execução em curso).

O desfecho do hand-off fica registrado como um marco permanente na linha do tempo da conversa (diferente do banner, que some quando a aderência volta): "Preparando a transferência" enquanto roda, depois um botão para abrir a conversa nova ou baixar o resumo, ou um aviso de que o turno terminou com erro e nenhum resumo foi gerado (nesse caso dá para pedir de novo). Pedir hand-off mais de uma vez na mesma conversa é permitido — cada marco de pedido só mostra o resultado da sua própria tentativa.

Em conversas vistas por link compartilhado (visão só-leitura), o aviso inteiro não aparece — quem só está lendo a conversa de outra pessoa não tem como acionar nenhuma das duas ações.

O aviso passou a ser falado (02/09/2026). Enquanto existia a janela, ela era a única parte que se anunciava sozinha para quem usa leitor de tela. Tirada a janela, o aviso do topo ficava mudo: quem não vê a tela simplesmente não era informado de que a conversa tinha entrado nesse estado.

Agora o aviso é anunciado nos dois momentos em que ele pode aparecer — quando a conversa se degrada enquanto você está nela, e quando você já a abre degradada. São dois casos, e cada um exigiu tratamento próprio: o que funciona para avisar de uma mudança não avisa nada quando o texto já estava lá desde o começo.

A faixa passou a caber num canto (03/09/2026)

A faixa mostrava quatro coisas de uma vez: o aviso em si, a recomendação, a razão de uma das saídas estar indisponível e as duas saídas. Com duas conversas abertas lado a lado, isso comia um terço do espaço de leitura de cada uma — o alerta ocupava mais lugar do que aquilo sobre o que ele alertava.

Agora só o essencial fica sempre à vista: o aviso e a saída mais barata. O resto desce para um bloco que abre com um clique.

Duas regras decidem quando esse bloco abre por conta própria, e as duas têm o mesmo critério — se aquilo é resposta a algo que você fez:

• Um erro abre o bloco. Erro é o desfecho de um clique seu, e esconder isso atrás de um gesto a mais seria simplesmente não avisar. Tentar de novo e falhar de novo faz o aviso reaparecer, em vez de a segunda falha passar calada.
• Uma saída indisponível não abre o bloco. "Não há histórico para resumir" é estado da conversa, acontece com frequência e não pede reação sua. Abrir por isso deixaria a faixa sempre expandida, e a economia de espaço desapareceria. Quem quiser o motivo o alcança pelo próprio botão.

Para quem usa leitor de tela nada muda entre recolhido e aberto: é o mesmo aviso, dito do mesmo jeito — só a apresentação muda.

E o estado recolhido não é guardado entre visitas, de propósito: o aviso não é algo que se dispensa. Enquanto a condição durar, ele volta.

Correção (14/08/2026): a instrução que pede ao agente para sinalizar o início de cada resposta media taxas bem diferentes conforme o turno: quase 1 em 3 turnos sem chamar nenhuma ferramenta antes de escrever emitia o sinal, contra menos de 1 em 20 turnos que chamavam uma ferramenta primeiro — o caso mais comum numa plataforma de agentes autônomos, que quase sempre agem antes de escrever. A instrução original pedia para sinalizar "o começo de toda resposta", o que não fazia sentido para um turno que começa com uma ação, não com texto — quando o agente finalmente escrevia, já não era mais "o começo" de nada. A instrução agora ancora explicitamente no primeiro texto do turno, com orientação própria para depois de usar ferramentas, e a medição deixou de disparar aviso em conversas saudáveis por causa desse falso positivo.

O que dá para fazer

Quando o provedor de IA recusa por limite (25/08/2026)

Uma execução também pode terminar porque o provedor de IA recusou por limite de uso da conta — não é uma falha do agente nem da conversa. Esse caso ganhou um card próprio, âmbar, sem o botão "Continuar": insistir não resolve, e o limite volta sozinho depois de um tempo. Antes desta correção o motivo se perdia, e a conversa mostrava o card genérico de erro sem dizer o que havia acontecido.

Limites conhecidos

• Execução órfã: se o ambiente por trás da execução morrer no meio do processo, a conversa pode ficar presa em "Trabalhando" até alguém parar e reenviar a mensagem.
• A recusa por conversa ocupada é uma resposta esperada, não um erro de sistema: quem integra por API precisa tratá-la (mostrar um aviso ou oferecer enfileirar a mensagem).