Fila de tarefas para agentes de IA: muitos pedidos sem perdas

Uma fila de tarefas para agentes de IA é uma fila de espera durável que registra cada pedido recebido antes de qualquer trabalho começar e, depois, entrega os itens ao agente um de cada vez, com status e responsável claros. As prioridades decidem o que vai primeiro, e as confirmações atestam que cada item foi recebido, iniciado e concluído. Juntas, impedem que pedidos simultâneos se percam ou sejam feitos duas vezes.

Principais pontos

• Registre todo pedido em uma fila durável antes que o agente toque nele, para que uma falha ou um horário de pico nunca apague trabalho.
• Use um esquema de prioridades curto, que uma pessoa consiga ler e explicar, e defina a prioridade por regras, não pelo palpite do modelo.
• Confirme em três momentos (recebido, iniciado, concluído) e trate o silêncio como sinal para tentar de novo ou escalar para uma pessoa.
• Evite duplicidade com uma chave de idempotência por pedido, para que uma mensagem repetida ou uma etapa reexecutada nunca gere um segundo efeito.
• Monitore a própria fila: a idade do item mais antigo, os itens travados e os itens rejeitados mostram problemas antes de o cliente reclamar.

Por que pedidos simultâneos se perdem ou se duplicam?

Um único agente trabalhando em uma conversa processa o que estiver no seu contexto. Quando um e-mail, uma mensagem de chat e um formulário chegam no mesmo minuto, os três podem cair na mesma conversa. O agente pode responder só ao último, misturar dois pedidos sem relação em uma única resposta ou terminar o primeiro e nunca voltar aos outros. Ninguém vê uma falha, porque tecnicamente nada quebrou. O trabalho simplesmente sumiu.

A duplicidade tem outra causa. Quem envia tenta de novo quando não recebe confirmação. Um cliente que não ouve nada escreve outra vez. Um sistema conectado que não recebe resposta rápida envia o mesmo evento uma segunda vez. A documentação de webhooks da Stripe diz com clareza que um endpoint pode receber o mesmo evento mais de uma vez e deve ser construído para lidar com isso. A lição vale muito além de pagamentos: qualquer canal que repete envios vai, cedo ou tarde, entregar o mesmo pedido duas vezes.

Os dois problemas têm a mesma raiz. A memória do agente não é um livro-razão. Um modelo guarda o que está diante dele e não consegue dizer com segurança o que lhe foi pedido ontem, o que está pela metade ou o que ele já enviou. A fila tira esse registro de dentro do modelo e o coloca em um lugar que sobrevive a reinícios, trocas de responsável e manhãs cheias.

O que uma fila de tarefas de agente realmente contém?

Uma fila é uma lista de itens de trabalho, cada um com um estado, guardada fora do modelo. O agente não decora a lista. Ele lê o próximo item dela. Um item útil traz estes campos:

• Identificador: uma referência única, mais uma chave de idempotência que identifica o pedido original.
• Origem e solicitante: de qual canal veio e quem pediu.
• Pedido: o que está sendo solicitado, em forma específica o bastante para ser testada depois.
• Classe de prioridade: definida por regra quando o item é criado e visível para a equipe.
• Status: aguardando, em andamento, concluído, falhou ou precisa de uma pessoa.
• Reserva (lease): qual executor está com o item e quando essa reserva expira.
• Tentativas: quantas vezes o item já foi executado.
• Resultado: a saída e a evidência de que o trabalho foi concluído.

Os itens avançam por estados definidos, e cada mudança é gravada em um registro. Esse registro permite que o líder de operações responda à pergunta mais importante depois de um incidente: o que aconteceu com este pedido?

A mesma lógica aparece nos conceitos de observabilidade descritos pelo OpenTelemetry, que separam sinais como logs, métricas e traces. A fila se beneficia dos três. Os logs mostram o que aconteceu com um item, as métricas mostram como a fila inteira está se comportando, e os traces mostram como um pedido atravessou várias ferramentas.

Como as prioridades devem funcionar?

Prioridade é uma decisão de negócio, então deve ser escrita pelo negócio. Mantenha o esquema pequeno. Três classes costumam bastar, e cada uma precisa de uma definição simples:

• Urgente: um prazo com peso legal ou de segurança, ou um cliente que não consegue operar de jeito nenhum. Esses itens vão primeiro e avisam uma pessoa imediatamente.
• Padrão: pedidos normais, com prazo de resposta combinado. A maior parte do trabalho está aqui.
• Segundo plano: trabalho útil sem relógio correndo, como organizar cadastros ou preparar resumos.

Defina a classe com regras determinísticas sempre que puder: o canal, o tipo de conta de quem enviou, um campo do formulário, uma lista de palavras-chave. O modelo pode sugerir uma classe quando as regras não cobrem o caso, mas uma regra ou uma pessoa deve confirmar tudo o que cair na classe mais alta. Caso contrário, um palpite confiante e errado pode colocar trabalho de baixo valor na frente de emergências reais.

Dois ajustes evitam a maior parte dos problemas de prioridade. Primeiro, adicione envelhecimento: um item de segundo plano que esperou além do limite sobe de classe, de modo que baixa prioridade nunca signifique nunca. Segundo, não interrompa o trabalho no meio de uma etapa. Deixe o agente terminar a etapa atual, salvar o progresso e só então pegar o item urgente. O progresso salvo é o tema de Checkpoints de agentes de IA: como retomar o trabalho, e é isso que torna seguro trocar de tarefa.

Prioridade também nunca concede permissão. Um pedido urgente para alterar um dado de pagamento exige a mesma aprovação de um pedido padrão. As regras sobre quais ações precisam de uma pessoa ficam nos seus guardrails para agentes de IA e valem igualmente para todas as classes.

O que uma confirmação deve atestar?

Uma confirmação é um registro de que uma etapa aconteceu. A fila precisa de três, e cada uma atende a um leitor diferente.

• Recebido: enviado ao solicitante assim que o item é gravado. Traz um número de referência e alinha expectativas. Essa única mensagem elimina boa parte das novas tentativas e dos e-mails repetidos que geram duplicidade.
• Iniciado: registrado internamente quando um executor pega o item. O executor fica com uma reserva (lease) com prazo de expiração, de modo que a posse é temporária, não permanente.
• Concluído: registrado com o resultado e a evidência de que o trabalho atendeu aos critérios. Definição de pronto para agentes de IA: exija evidência explica por que isso deve ser prova, e não a afirmação de que o agente acredita ter tido sucesso.

A reserva é o que resolve o silêncio. Se um executor pega um item e depois trava, cai ou perde a conexão, a reserva expira e o item volta ao estado de aguardando, com a contagem de tentativas aumentada. Sem reserva, esse item ficaria marcado como em andamento para sempre, que é a forma mais silenciosa de perder um pedido.

Defina um limite de tentativas. Ao atingi-lo, o item não deve continuar girando. Ele passa para uma faixa de intervenção humana, com o histórico anexado, e uma pessoa nomeada o recebe. Essa faixa não é uma falha do desenho. É o desenho funcionando: alguns pedidos exigem julgamento, e a fila deve dizer isso com clareza.

Os textos de engenharia da Anthropic sobre agentes de longa duração fazem um ponto parecido. Trabalho que atravessa várias sessões precisa de registros escritos de progresso, porque cada nova sessão começa sem memória da anterior. Um item de fila com status e campo de resultado é esse registro para cada pedido individual.

Como impedir que o mesmo pedido seja executado duas vezes?

A ferramenta para isso é a idempotência: executar a mesma operação duas vezes tem o mesmo efeito que executá-la uma vez. A documentação da API da Stripe sobre requisições idempotentes descreve bem o padrão. Quem chama anexa uma chave única ao pedido e, se o pedido for repetido com essa chave, o sistema devolve o resultado original em vez de agir de novo. Dá para aplicar a mesma ideia ao seu agente em dois pontos.

Na entrada, monte a chave com algo estável: o identificador da mensagem no sistema de origem ou, quando não existe identificador, uma combinação de solicitante, assunto e janela de tempo. Antes de criar um item novo, verifique se essa chave já existe. Se existir, anexe a nova mensagem ao item existente e avise o solicitante de que o pedido já está em andamento. Não faça a fusão em silêncio, porque a segunda mensagem pode trazer uma correção.

No momento da ação, passe a chave para tudo o que tiver efeito colateral. Antes de enviar um e-mail, criar um registro ou emitir um pedido de reembolso, a ferramenta verifica se aquela chave já tem um resultado guardado. Se tiver, devolve esse resultado em vez de repetir a ação. Isso importa mais depois que uma reserva expira, porque o executor anterior pode ter concluído a ação logo antes de travar. O novo executor precisa conseguir descobrir isso, não repetir. Para entender melhor como as ferramentas são chamadas, veja O que é tool calling em IA? Explicação simples para empresas.

A capacidade entra na mesma conversa. A fila permite limitar quantos itens rodam ao mesmo tempo, o que protege os sistemas que o agente chama. Quando um serviço externo começa a recusar chamadas, a fila desacelera e espera, em vez de gastar tentativas. Planeje esse comportamento junto com os limites de requisições (rate limits) das APIs que o agente usa.

Como isso fica na prática?

Veja um cenário ilustrativo. Não é um caso real.

Uma pequena distribuidora usa um agente para tratar dúvidas sobre pedidos. Em uma segunda-feira de manhã, um cliente envia um e-mail pedindo para mudar o endereço de entrega. Dois minutos depois, o mesmo cliente manda uma mensagem de chat com o mesmo pedido, porque ninguém respondeu. Ao mesmo tempo, um supervisor do armazém preenche um formulário avisando de um palete danificado que precisa ser tratado antes de um caminhão sair.

Com a fila, o e-mail e o chat geram a mesma chave de idempotência, então o segundo se junta ao primeiro item e o cliente recebe um aviso de que o pedido já está em andamento. O relato do palete corresponde à regra de urgência, passa na frente e avisa o líder de operações. O agente termina a etapa atual da troca de endereço, salva o progresso, trata o item do palete e depois volta. Quando a troca de endereço é concluída, o item registra a confirmação do sistema de pedidos como evidência. Nada se perde, nada é enviado duas vezes e cada passo pode ser revisado depois.

Para implantar isso no seu ambiente, siga estas etapas, nesta ordem:

• Etapa um: liste todos os canais por onde pedidos chegam ao agente, inclusive os informais, como e-mails encaminhados.
• Etapa dois: escolha o lugar durável onde os itens serão guardados e direcione todos os canais para ele antes que o agente veja qualquer coisa.
• Etapa três: defina os campos do item e os status permitidos, e registre quem pode mover um item entre eles.
• Etapa quatro: escreva as regras de prioridade em linguagem simples, nomeie um responsável por elas e adicione uma regra de envelhecimento.
• Etapa cinco: defina as três confirmações, incluindo o texto enviado aos solicitantes.
• Etapa seis: adicione chaves de idempotência na entrada e em toda ferramenta que altera algo.
• Etapa sete: defina o prazo da reserva, o limite de tentativas e a faixa de intervenção humana, com um destinatário nomeado.
• Etapa oito: teste com uma rajada deliberada de pedidos variados, repetidos e malformados em ambiente de teste, antes de entrar em produção.
• Etapa nove: escolha as medidas da fila que você vai revisar com regularidade, como a idade do item mais antigo e o conteúdo da faixa de intervenção humana.

O teste de rajada da etapa oito é o que as equipes costumam pular. É também o que encontra os problemas, porque o tráfego real é irregular e um teste leve esconde todas as condições de corrida.

Você precisa de uma fila ou um fluxo basta?

Nem todo agente precisa de uma fila completa. Se os pedidos chegam raramente, um de cada vez, e uma pessoa acompanha cada resultado, um registro simples pode bastar. A fila se justifica quando os pedidos chegam por vários canais, quando o mesmo remetente pode se repetir, quando o trabalho demora o bastante para se sobrepor ou quando um item perdido tem custo real.

Pergunte também se a tarefa precisa mesmo de um agente. Se as etapas são fixas e as entradas são previsíveis, um fluxo determinístico com uma fila na frente costuma ser mais barato e mais fácil de auditar. Agente de IA ou fluxo determinístico? Como decidir traz um guia de decisão. Onde o agente é necessário, a fila continua ajudando, porque separa a pergunta sobre qual trabalho existe da pergunta sobre como o agente o executa.

Como a Be Human trata filas de pedidos?

A Be Human trata a fila como parte do harness em torno do agente, não como um acessório. Em um primeiro projeto, definimos o papel do agente, os canais que o alimentam, as regras de prioridade, os limites de aprovação e a evidência que conta como pronto. Construímos a entrada, os estados dos itens, as reservas, as chaves de idempotência e a faixa de intervenção humana de forma que sua equipe consiga ler e alterar tudo isso. Na operação gerenciada, monitoramos a saúde da fila, revisamos itens travados e escalados, mantemos as integrações conforme os canais mudam e fazemos melhorias controladas nas regras, com sua equipe aprovando tudo o que altera o que o agente pode fazer.

Perguntas frequentes

Qual é a diferença entre uma fila e simplesmente dar ao agente uma lista no prompt? A lista no prompt vive dentro do contexto do modelo, que é temporário e pode ser truncado, reordenado ou esquecido. A fila vive fora do modelo, em armazenamento durável, com status e registros. O agente lê a partir dela, então um reinício ou um dia longo não apaga a lista.

Como decidir por quanto tempo uma reserva deve durar? Baseie-se no tempo que um item normal leva mais uma margem razoável, e meça isso em execuções reais, em vez de estimar. Uma reserva curta demais causa tentativas duplicadas, enquanto uma longa demais deixa itens travados escondidos. Comece com cautela, revise os itens travados e ajuste.

O agente deve decidir as prioridades sozinho? Ele pode propor uma prioridade, principalmente para mensagens que não se encaixam em nenhuma regra. Uma regra escrita ou uma pessoa deve decidir tudo o que afeta prazos, segurança ou dinheiro. Isso mantém o esquema explicável, o que importa quando alguém pergunta por que um pedido esperou.

O que monitorar depois que a fila estiver rodando? Acompanhe a idade do item mais antigo na espera, quantos itens estão na faixa de intervenção humana, com que frequência as reservas expiram e quantos pedidos recebidos correspondem a uma chave já existente. Números crescentes em qualquer um deles apontam um problema de capacidade, de regras ou de alguma ferramenta conectada. Revise esses indicadores em uma rotina regular, não só depois de uma reclamação.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.