Arquitetura Multiagente com RAG Local para Atendimento Turístico Seguro e Rastreável

Resumo

Este estudo de caso documenta a construção e a publicação controlada de uma prova de conceito de atendimento turístico por e-mail, baseada em orquestração multiagente, recuperação aumentada por geração, modelos locais e automação no n8n. A solução recebe mensagens pelo Microsoft Outlook, identifica o cliente por dados técnicos do remetente, consulta cadastro e estados operacionais no Google Sheets, classifica a solicitação, direciona o atendimento para Sarah, Fidelizador, Concierge, Continuação Operacional, Atendimento Humano Geral ou Fallback, e consulta uma base documental armazenada no Supabase quando a pergunta exige evidência comercial.

Os resultados comprovados incluem resposta documental da Sarah, atendimento humano com confirmação posterior ao envio interno, agendamento de ligação em duas etapas pelo Fidelizador, conclusão do estado persistido, bloqueio de agendamento duplicado, tratamentos defensivos para estados não ativos e publicação bem-sucedida dos gatilhos de Outlook e Google Drive. Informações insuficientes foram encontradas nas fontes fornecidas para apresentar métricas de latência, custo computacional, taxa de acerto ou volume produtivo.

1. Introdução

O problema de negócio exigia conciliar atendimento consultivo, dados cadastrais, informações comerciais documentadas e operações externas sem transferir autonomia indevida ao modelo de linguagem. Uma resposta incorreta poderia misturar clientes, inventar preço, confirmar disponibilidade inexistente, criar evento sem consentimento final ou informar que uma equipe foi notificada antes do retorno real do Outlook.

A solução foi desenvolvida como POC, sigla para Prova de Conceito. O objetivo foi demonstrar viabilidade técnica e maturidade arquitetural, não afirmar prontidão irrestrita para produção. O workflow foi publicado para demonstração controlada após validação dos ramos principais e reconexão da credencial do Google Drive Trigger.

2. Definição do Problema

3. Arquitetura da Solução

A arquitetura publicada reúne dois fluxos acionados por gatilhos: ingestão documental via Google Drive e atendimento multiagente via Microsoft Outlook. O pipeline documental baixa o arquivo, extrai texto, prepara e divide o documento em chunks, gera embeddings locais e armazena o conteúdo na base RAG. O pipeline de atendimento identifica o cliente, classifica a solicitação no Orquestrador e executa apenas o ramo correspondente.

Google Drive Trigger
  -> Download do arquivo
  -> Extração de texto
  -> Preparação e divisão em chunks
  -> Embeddings locais
  -> Armazenamento na base RAG

Microsoft Outlook Trigger
  -> Identificação do cliente
  -> Cadastro no Google Sheets
  -> Orquestrador estruturado
  -> Switch de atendimento
     -> Sarah
     -> Fidelizador
     -> Concierge
     -> Continuação operacional
     -> Atendimento humano geral
     -> Fallback

3.1 Segurança e operação

O Orquestrador não possui ferramentas operacionais. Os agentes não acessam diretamente o Supabase. O contexto documental é tratado como dado e não como instrução. A execução de Outlook, Google Sheets e calendário permanece em nós determinísticos do n8n. A memória Simple Memory é segmentada por conversation_id, mas permanece local à instância.

3.2 Escalabilidade

A POC utiliza memória local e Google Sheets para persistência operacional. Informações insuficientes foram encontradas nas fontes fornecidas para descrever capacidade de carga, múltiplos workers, Queue Mode, throughput ou dimensionamento de infraestrutura com precisão. A limitação da Simple Memory para múltiplos workers foi explicitamente reconhecida.

5. Workflows Publicados e Nós Utilizados

5.1 Ingestão e atualização da base RAG

A execução visual anexada registrou um arquivo, 214 itens no preparo e armazenamento e 214 itens no processamento de embeddings. Essa observação representa a execução exibida, não uma métrica geral de produção.

5.2 Atendimento multiagente publicado

6. Jornada de Implementação

1. Descoberta: definição dos agentes, fontes autorizadas, limites operacionais e riscos de falsa confirmação.
2. Planejamento: preservação do workflow estável e criação de uma versão multiagente não publicada.
3. Design: orquestrador sem ferramentas, Switches explícitos, RAG compartilhado e contratos por agente.
4. Desenvolvimento: implementação do Fidelizador, Concierge, atendimento humano, continuação persistida e Sarah.
5. Validação: testes reais e simulações controladas de sucesso, falha, ação inválida, estado concluído, cancelado e inativo.
6. Implantação: reconexão da credencial Google Drive e publicação dos gatilhos.
7. Otimização: remoção de simuladores, migração de Draft para Reply e uso de Chain estruturadora.

7. Decisões Técnicas e Justificativas Arquiteturais

8. Análise de Código e Expressões

Não foi disponibilizado código-fonte completo do workflow em formato exportado. Foram fornecidas expressões JavaScript efetivamente utilizadas nos nós do n8n. Os trechos abaixo representam a lógica observável e não reconstruções.

A chave de sessão da Sarah usa o identificador normalizado da conversa, evitando o ID individual da mensagem.

{{
  String(
    $('Reunir Contexto da Sarah e RAG')
      .first()
      .json
      .conversation_id ?? ''
  )
}}

A expressão aplica fallback para string vazia e segmenta a Simple Memory por conversa. A dependência é o contrato produzido pelo nó de reunião. Para produção com múltiplos workers, a própria limitação da memória local permanece pendente.

A data operacional é gerada no timezone definido no projeto:

{{ $now.setZone('America/Sao_Paulo').toISO() }}

O resultado em ISO 8601 participa de registros e estados operacionais. A expressão não deve substituir uma data solicitada pelo cliente.

Na contingência, o n8n usa dados do item atual e recorre ao nó de preparação quando necessário:

{{
  String(
    $json.cliente ??
    $('Preparar Atendimento Humano — Sarah').first().json.cliente ??
    ''
  )
}}

Esse padrão permitiu testes autossuficientes sem quebrar o caminho real. O uso de nullish coalescing preserva valores válidos e só recorre ao fallback quando o campo está ausente ou nulo.

9. Desafios e Soluções

10. Resultados e Benefícios Comprovados

• Publicação bem-sucedida dos gatilhos de Google Drive e Microsoft Outlook.
• Ingestão documental automática com extração, segmentação, embeddings locais e armazenamento.
• Resposta documental real da Sarah na mesma conversa do Outlook.
• Encaminhamento humano da Sarah, notificação interna, confirmação ao cliente e registro no Google Sheets.
• Agendamento do Fidelizador em duas etapas, com evento de 30 minutos.
• Estado concluído e bloqueio comprovado de uma segunda criação de evento.
• Fallbacks e contingências validados por testes reais ou simulações controladas.

Não foram fornecidas métricas de redução de tempo, economia financeira, precisão do modelo ou satisfação dos usuários. Informações insuficientes foram encontradas nas fontes fornecidas para descrever esses aspectos com precisão.

11. Destaques de Engenharia

12. Lições Aprendidas

• Modelos de linguagem devem interpretar intenção, não comprovar execução operacional.
• Contratos intermediários em texto podem ser mais estáveis do que JSON direto em prompts extensos.
• O conversation_id é uma chave técnica essencial para memória e continuidade.
• Fallbacks precisam de resposta segura, mas não necessariamente de persistência na POC.
• Simulações controladas devem carregar os campos necessários quando executadas fora do caminho real.
• A publicação de um workflow com múltiplos gatilhos depende da validade de todas as credenciais.

13. Evoluções Futuras

• Substituir o destinatário interno provisório pela caixa oficial da ViaSul.
• Rotacionar ou comprovar a revogação da chave elevada do Supabase anteriormente exposta.
• Avaliar memória compartilhada em Redis ou Postgres para múltiplos workers.
• Implementar continuação persistida para Sarah e Concierge.
• Definir expiração e retenção dos estados e atendimentos.
• Testar concorrência, indisponibilidade, retry, carga, latência e consumo de recursos.
• Avaliar a persistência futura de ocorrências técnicas em workflow dedicado.

14. Conclusão

A POC demonstrou uma arquitetura multiagente capaz de combinar modelos locais, RAG validado, roteamento determinístico, memória segmentada, persistência operacional e integrações reais de e-mail, calendário e planilhas. O principal valor técnico não está apenas na automação da resposta, mas na disciplina de engenharia aplicada para impedir que uma decisão probabilística seja confundida com execução operacional.

O conjunto publicado comprova viabilidade técnica para uma demonstração controlada. A solução ainda possui pendências explícitas para produção real, incluindo credenciais definitivas, memória distribuída, métricas, testes de carga, políticas de retenção e tratamento de indisponibilidade. Essa delimitação preserva a fidelidade das evidências e distingue uma POC bem-sucedida de uma plataforma plenamente operacionalizada.