Todo limite aqui é permanente e proposital. Nenhum deles é um bug, e conhecê-los cedo muda como você configura a coisa.
Se, em vez disso, um e-mail específico ficou sem resposta, isso é um diagnóstico, não um limite: por que a IA não respondeu.
Começa na conexão. Não existe histórico.
Conectar uma caixa de e-mail inicia uma observação dos e-mails novos. Nada de antes da conexão é importado, e nada do que você fizer depois preenche o passado.
A consequência prática: conecte a caixa de e-mail antes do período que você quer coberto. Uma caixa conectada na sexta não sabe nada da quinta, e a base de conhecimento é o único jeito de dar a ela um contexto anterior a ela.
Ele só conta as respostas que saíram por ele
A plataforma registra o que ela mesma enviou. Uma resposta que um colega digita no Gmail ou no Outlook é uma resposta real a um cliente real, e não é creditada aqui — então a thread ainda pode parecer esperando.
Os dois provedores falham de forma diferente, e não é seguro descrever um como o outro. No Gmail a observação é armada na caixa de entrada, então a resposta dele nunca chega a nós. No Outlook a assinatura de itens enviados entrega a mensagem, e mesmo assim a thread não é marcada como respondida.
Então “sem resposta” aqui sempre significa a última mensagem que consigo ver é a deles — nunca você deve uma resposta a essa pessoa.
No Gmail, ele vê a caixa de entrada e nada mais
A observação é armada especificamente na INBOX. E-mail que pula a caixa de
entrada — filtrado direto para uma etiqueta, ou arquivado ao chegar — é
invisível. Se você roda filtros agressivos, o e-mail que você mais quer
tratado pode ser o que nunca chega.
As instruções pertencem ao agente, não à caixa de e-mail
Não existe instrução por canal. O que você diz a um agente se aplica em todo lugar em que esse agente responde. Você pode redigir uma instrução para se escopar — “ao responder e-mails no support@…” — mas isso é um pedido a um modelo, não uma configuração que algo impõe.
Duas caixas de e-mail que genuinamente precisam de comportamentos diferentes precisam de agentes diferentes.
Uma instrução não impede um rascunho de ser escrito
É a que as pessoas tentam primeiro, e não funciona do jeito que parece. Dizer a um agente “não responda a e-mails de marketing” muda como uma resposta é redigida, não se ela existe. O único jeito de um prompt não produzir rascunho é o modelo emitir zero caracteres, e um modelo mandado ficar quieto normalmente escreve em vez disso uma recusa educada — que se torna o rascunho.
O que realmente impede uma resposta é determinístico e vive no código, antes
de o modelo rodar: e-mail que se identifica como automatizado é descartado, e
e-mail de um endereço no-reply é mostrado, mas nunca rascunhado. Esses são
filtros, não instruções, e não são configuráveis por caixa de e-mail.
Os rascunhos não estão em todo lugar
Na maioria das caixas de e-mail, uma resposta pendente também é escrita na pasta de Rascunhos do provedor. Num Grupo do Microsoft 365 não é — o Graph não tem API de rascunho para conversas de grupo, então esses ficam apenas no painel.
Também não existe pontuação de confiança por rascunho. Um rascunho é sinalizado pela triagem ou não é; nada mede o quão certo o modelo estava, e qualquer interface sugerindo o contrário estaria inventando.
Um modo de resposta não definido significa autônomo
Se o modo armazenado um dia faltar ou não for reconhecido, o fallback é autônomo — a IA envia. Essa é uma escolha deliberada sobre qual falha é pior, e significa que definir o padrão explicitamente é melhor do que assumir que um campo vazio significa “não fazer nada”.
A entrega não é nossa
Se uma resposta foi enviada daqui e nunca chegou, isso é SPF, DKIM, a reputação do seu domínio ou o filtro de spam do destinatário. Essas coisas vivem com o seu provedor de e-mail e o seu DNS. Este produto não gerencia, não monitora e não relata nada disso, e nada aqui vai dizer que uma mensagem foi marcada como spam.