Nem toda tarefa de um Agente IA termina na conversa: como executar processos longos, informar status e retomar o atendimento

Quando uma pessoa conversa com um Agente IA, existe uma expectativa de resposta rápida. Ela envia uma pergunta, aguarda alguns segundos e recebe uma mensagem. Esse formato funciona bem para esclarecer dúvidas, consultar informações simples ou executar ações com poucas etapas.

O problema aparece quando a solicitação exige um processo mais longo.

Um cliente pode enviar vários documentos e pedir uma análise. Uma proposta personalizada pode depender de preços, disponibilidade, regras comerciais e dados armazenados em sistemas diferentes. Um cadastro pode exigir validação fiscal, conferência de documentos e aprovação humana. Uma pesquisa pode precisar consultar diversas fontes antes de produzir uma resposta confiável.

Essas tarefas podem levar minutos ou até horas. Mantê-las dentro do mesmo ciclo de resposta cria uma conversa aparentemente travada, aumenta o risco de timeout e faz o cliente pensar que algo deu errado.

A solução não é aumentar indefinidamente o tempo máximo de espera. É tratar a solicitação como um processo que continua depois da mensagem inicial.

A conversa pode iniciar o trabalho sem permanecer aberta

Um Agente IA não precisa concluir tudo antes de responder ao usuário. Ele pode compreender a solicitação, validar os dados recebidos, iniciar o processo e informar que o trabalho continuará sendo executado.

A conversa deixa de ser o lugar onde toda a execução acontece. Ela passa a funcionar como uma interface para iniciar, acompanhar e receber o resultado.

Esse é o princípio da execução assíncrona.

Em uma execução síncrona, a aplicação envia uma solicitação e mantém a conexão aberta até receber o resultado. Em uma execução assíncrona, a aplicação inicia o trabalho, recebe um identificador e consulta seu andamento posteriormente ou espera uma notificação de conclusão.

A documentação de execução em segundo plano da OpenAI, por exemplo, permite iniciar respostas demoradas de forma assíncrona. A aplicação pode consultar o objeto enquanto o estado permanece como `queued` ou `in_progress`. Quando a resposta deixa esses estados, alcançou uma condição final.

Essa capacidade resolve uma parte do problema técnico. A empresa ainda precisa decidir como registrar a tarefa, preservar seu contexto, informar o cliente, entregar o resultado e agir quando alguma etapa falhar. É por isso que um bom Agente IA depende de contexto, ferramentas e processo, não apenas de um prompt capaz de compreender a solicitação.

Execução assíncrona não significa abandonar o cliente

Um erro comum é responder “estamos processando” e deixar o trabalho rodando silenciosamente.

Do ponto de vista do cliente, um processo sem informação continua parecendo travado. A espera deixou de acontecer diante de um indicador de digitação, mas a incerteza permanece.

Toda tarefa longa precisa de quatro elementos:

1. Confirmação: o sistema informa que entendeu a solicitação e iniciou o trabalho.

2. Status: o usuário consegue saber se a tarefa está aguardando, sendo processada, concluída ou interrompida.

3. Retomada: quando o resultado fica pronto, o atendimento continua a partir do ponto correto.

4. Tratamento de falhas: se algo der errado, o sistema explica o problema e define o próximo passo.

O trabalho pode acontecer fora da conversa, mas a experiência continua sendo acompanhada por ela.

Em vez de deixar o cliente esperando, o Agente pode responder:

“Recebi os três documentos e iniciei a análise. Esse processo pode levar alguns minutos. Você não precisa permanecer nesta conversa. Avisarei assim que o relatório estiver pronto.”

Essa mensagem encerra a espera imediata sem encerrar o atendimento.

Quando usar resposta imediata, streaming ou tarefa assíncrona

Nem toda operação demorada precisa seguir o mesmo formato.

Uma resposta imediata funciona quando o resultado pode ser produzido em poucos segundos. O usuário faz uma pergunta, o sistema consulta uma fonte e devolve a resposta no mesmo ciclo.

O streaming é útil quando o resultado pode ser apresentado progressivamente. O usuário começa a receber o conteúdo enquanto o modelo continua gerando a resposta. Isso reduz a percepção de espera, mas a conexão ainda precisa permanecer ativa.

A tarefa assíncrona faz mais sentido quando o trabalho:

* depende de várias etapas;

* consulta serviços externos que podem demorar;

* processa muitos arquivos ou grandes volumes de dados;

* exige aprovação humana;

* precisa sobreviver ao fechamento do canal;

* pode ser retomado depois de uma interrupção;

* produz um arquivo, relatório ou ação operacional ao final.

A escolha não deve ser feita apenas com base no tempo estimado. Também importa saber o que acontece se a conexão cair, se um sistema externo ficar indisponível ou se o cliente sair da conversa.

Como estruturar um processo longo executado por um Agente IA

Uma arquitetura desse tipo separa a interação com o usuário da execução operacional. A conversa inicia a demanda. Um processo persistente assume o trabalho.

1. O Agente identifica que a tarefa não deve bloquear a conversa

Uma consulta simples ao estoque pode ser respondida em poucos segundos. A análise de dezenas de páginas, uma pesquisa em várias fontes ou uma operação que depende de muitos sistemas deve seguir outro caminho.

O Agente pode considerar fatores como:

* quantidade de dados;

* número de etapas;

* sistemas envolvidos;

* tempo provável de execução;

* dependência de serviços externos;

* necessidade de aprovação humana;

* impacto de uma interrupção;

* risco de executar a mesma ação duas vezes.

A partir desses critérios, ele escolhe entre responder imediatamente, transmitir o resultado progressivamente ou criar uma tarefa assíncrona.

Essa decisão também depende das ferramentas disponíveis. Um Agente precisa de ferramentas para consultar sistemas e executar ações reais, mas cada ferramenta pode ter seu próprio tempo de resposta, limite e possibilidade de falha.

2. A aplicação cria um registro persistente da tarefa

Antes de iniciar a execução, o sistema deve registrar o processo em um banco de dados.

Esse registro pode incluir:

* identificador da tarefa;

* cliente e organização responsáveis;

* conversa e canal de origem;

* Agente que iniciou o processo;

* objetivo solicitado;

* arquivos e dados recebidos;

* sistemas que serão consultados;

* estado atual;

* número de tentativas;

* horário de criação e última atualização;

* resultado produzido;

* erro encontrado, quando houver;

* próximo passo esperado.

O ponto central é simples: a tarefa não pode depender da sessão de conversa continuar aberta. Mesmo que o usuário feche o WhatsApp, o navegador ou o aplicativo, o trabalho precisa permanecer registrado.

Os estados internos podem seguir uma estrutura como:

* `pending`: tarefa criada, mas ainda não enviada para execução;

* `queued`: aguardando capacidade de processamento;

* `in_progress`: execução iniciada;

* `waiting_input`: aguardando informação ou aprovação;

* `completed`: concluída com sucesso;

* `failed`: interrompida por um erro;

* `cancelled`: cancelada pelo usuário ou pelo sistema;

* `incomplete`: encerrada sem produzir o resultado esperado.

A referência de eventos de webhook da OpenAI diferencia respostas concluídas, canceladas, com falha e incompletas. Essa separação permite que a aplicação escolha um fluxo adequado para cada resultado, em vez de tratar qualquer encerramento como sucesso.

3. Uma fila desacopla a conversa da execução

Depois que a tarefa é registrada, ela pode ser enviada para uma fila. Um worker, serviço responsável por processar trabalhos em segundo plano, retira a tarefa da fila e executa as etapas necessárias.

No caso de uma análise documental, o processo poderia:

1. validar os arquivos recebidos;

2. verificar se estão legíveis e no formato aceito;

3. extrair o conteúdo;

4. classificar os documentos;

5. analisar cada seção;

6. comparar as informações encontradas;

7. produzir um relatório;

8. armazenar o resultado;

9. solicitar revisão humana, quando necessário;

10. avisar o canal de atendimento.

A conversa não precisa permanecer bloqueada durante nenhuma dessas etapas.

A fila também ajuda a controlar capacidade. Se cem clientes enviarem documentos ao mesmo tempo, o sistema não precisa iniciar cem análises sem limite. Ele pode ordenar as tarefas, distribuir o trabalho entre diferentes workers e aplicar prioridades quando houver prazos ou níveis de serviço distintos.

4. O sistema acompanha o andamento

Existem duas formas comuns de descobrir se uma tarefa terminou.

Na primeira, chamada de polling, a aplicação consulta periodicamente o status do processo. Enquanto ele estiver aguardando ou em andamento, uma nova consulta é realizada depois de determinado intervalo.

Na segunda, o serviço responsável pela execução envia um webhook quando algum evento acontece. Em vez de perguntar repetidamente se o processo terminou, a aplicação recebe uma notificação quando há uma mudança relevante.

O polling pode ser simples de implementar, mas aumenta o número de consultas e exige uma política de intervalo. Consultar rápido demais desperdiça recursos. Consultar devagar demais atrasa a entrega do resultado.

O webhook reduz consultas desnecessárias, mas cria outras responsabilidades. O endpoint precisa estar disponível, verificar a origem da requisição, responder rapidamente e processar cada evento de forma segura.

O guia de webhooks da OpenAI recomenda que o endpoint responda com sucesso em poucos segundos e envie trabalhos mais pesados para um worker. Caso contrário, a entrega pode ser repetida. Em uma aplicação de negócio, o webhook pode atualizar a tarefa, armazenar o resultado e disparar uma nova mensagem para o cliente.

Retomar a conversa exige preservar o contexto

Concluir a tarefa é apenas parte do trabalho. O sistema ainda precisa saber para quem entregar o resultado e como continuar o atendimento.

A tarefa deve permanecer relacionada à conversa que a originou. Quando o processo termina, o sistema recupera informações como:

* quem fez a solicitação;

* em qual canal ela aconteceu;

* qual Agente estava atendendo;

* o que foi prometido ao cliente;

* quais dados foram enviados;

* qual resultado foi produzido;

* qual deve ser o próximo passo.

Assim, o Agente não retorna com uma mensagem genérica como “processo concluído”. Ele retoma o contexto:

“Terminei a análise dos documentos que você enviou. Encontrei duas divergências entre o contrato e a proposta comercial. Preparei um resumo com os pontos identificados e as ações recomendadas.”

A retomada pode acontecer horas depois ou em outro canal. O usuário pode iniciar a solicitação pelo site e receber o resultado por e-mail ou WhatsApp, desde que exista consentimento e uma associação segura entre a tarefa e o contato.

Esse vínculo também mostra por que registrar a conversa no CRM é tão importante quanto responder ao cliente. Sem histórico, identidade e relação entre conversa e processo, o sistema pode entregar o resultado à pessoa errada, repetir perguntas ou perder o próximo passo comercial.

O status precisa ser compreensível para o cliente

Os estados técnicos são úteis para o sistema, mas não devem ser apresentados sem tradução.

Um cliente não precisa saber que o job está no estado `queued`. Ele precisa entender o que está acontecendo.

A interface pode apresentar os estados desta forma:

* Solicitação recebida: os dados foram registrados.

* Preparando análise: a tarefa está aguardando processamento.

* Análise em andamento: os documentos ou sistemas estão sendo consultados.

* Aguardando informação: é necessário enviar um dado ou aprovar uma etapa.

* Concluído: o resultado está disponível.

* Não foi possível concluir: ocorreu um problema e uma nova ação é necessária.

* Cancelado: o processo foi interrompido.

Dependendo da duração, também pode ser útil informar etapas intermediárias. Uma proposta pode passar por “consultando disponibilidade”, “calculando condições” e “gerando documento”. Uma análise pode passar por “validando arquivos”, “comparando informações” e “preparando relatório”.

O sistema não deve inventar porcentagens apenas para parecer preciso. Quando não houver uma estimativa confiável, é melhor informar a etapa atual e explicar o que falta para a conclusão.

Falhas fazem parte do fluxo

Processos longos interagem com mais componentes e possuem mais pontos de falha.

Um sistema externo pode ficar indisponível. Um documento pode estar corrompido. Uma credencial pode expirar. O modelo pode produzir uma saída fora do formato esperado. O usuário pode cancelar a solicitação enquanto ela ainda está em andamento.

O tratamento de falhas precisa ser planejado antes da automação entrar em produção.

Algumas falhas podem ser tentadas novamente de forma automática. Outras exigem intervenção humana. Há situações em que o cliente precisa fornecer uma nova informação.

A mensagem deve refletir essa diferença:

“Não consegui acessar o sistema de cadastro neste momento. Farei uma nova tentativa automaticamente.”

Ou:

“O documento enviado está protegido por senha. Envie uma versão desbloqueada para que a análise continue.”

A empresa também precisa definir quando o processo deve ser encaminhado para uma pessoa. A supervisão humana funciona melhor quando existem critérios claros para autonomia e aprovação, especialmente em tarefas com impacto financeiro, jurídico ou operacional.

Repetir uma tentativa não pode repetir o efeito

Uma nova tentativa não pode cadastrar o mesmo cliente duas vezes, gerar duas propostas, enviar duas mensagens ou realizar duas cobranças.

Esse cuidado é chamado de idempotência. O sistema usa um identificador único para reconhecer que determinada operação ou evento já foi processado.

O mesmo princípio vale para webhooks. A documentação da OpenAI informa que entregas podem ser repetidas quando o endpoint não responde corretamente e que eventos duplicados podem ocorrer em casos raros. Por isso, a aplicação deve verificar a assinatura da requisição e usar o identificador do webhook para processar cada notificação apenas uma vez.

Exemplos de tarefas que podem continuar após a conversa

A execução assíncrona amplia o campo de atuação dos Agentes IA porque permite transformar uma conversa em trabalho operacional.

Análise de documentos

O cliente envia contratos, laudos, currículos ou relatórios. O Agente registra a solicitação, processa os arquivos e entrega uma análise quando o trabalho termina.

Preparação de propostas

O Agente coleta as necessidades do cliente durante a conversa. Depois, consulta preços, regras comerciais, disponibilidade e dados do CRM para montar uma proposta personalizada.

Processamento de cadastros

A conversa reúne os dados iniciais, mas a conclusão depende de validações fiscais, consultas externas, análise de documentos e registro em sistemas internos.

Pesquisas com várias fontes

O Agente recebe uma pergunta, consulta diferentes fontes, compara informações e produz um relatório. A documentação de deep research da OpenAI explica que pesquisas com múltiplas etapas podem levar dezenas de minutos e recomenda execução em segundo plano com webhooks para avisar quando o resultado estiver pronto.

Rotinas administrativas

Conferência de informações, atualização de planilhas, organização de arquivos, geração de relatórios e sincronização de sistemas também podem ser iniciadas por uma conversa e finalizadas posteriormente.

O Agente deixa de ser apenas um atendente

Quando toda ação precisa terminar antes da próxima mensagem, o Agente permanece limitado ao ritmo de um chatbot.

A execução assíncrona muda essa lógica. O Agente pode receber uma demanda, transformá-la em trabalho, coordenar ferramentas, acompanhar o processo e retornar com o resultado. Ele não apenas conversa sobre a operação. Ele participa dela.

Essa mudança exige uma arquitetura que trate conversas e processos como elementos relacionados, mas diferentes.

A conversa possui mensagens, contexto e participantes. O processo possui estados, etapas, prazos, tentativas, resultados e falhas. Um pode continuar mesmo quando o outro está temporariamente inativo.

É esse desenho que permite analisar documentos, preparar propostas, processar cadastros ou pesquisar várias fontes sem deixar o cliente preso diante de uma conversa aparentemente travada.

Um processo longo precisa de status, retomada e tratamento de falhas. Não basta aumentar o tempo de espera da conversa.