Da Resposta Generativa à Automação Confiável: Construindo um Agente de Atendimento com n8n e Google Gemini

Autora: Valquiria Ribeiro Coelho

Área: Inteligência Artificial, Engenharia de Prompt e Automação de Processos

Projeto: Agente de Atendimento IA — Criadores de Conteúdo

1. Introdução

A facilidade de integrar modelos de Inteligência Artificial a aplicações trouxe novas possibilidades para a automação do atendimento ao cliente. Entretanto, gerar uma resposta fluente não significa necessariamente fornecer uma informação correta, executar uma ação real ou resolver uma solicitação.

Em um cenário comercial, uma resposta inventada sobre preços, serviços, pedidos ou reembolsos pode gerar expectativas indevidas e comprometer a confiança do cliente.

Partindo desse problema, desenvolvi um projeto de agente de atendimento com IA utilizando n8n e Google Gemini, com o objetivo de estruturar um fluxo capaz de receber mensagens, gerar respostas seguindo instruções específicas, classificar solicitações e registrar casos que precisam de análise humana.

O projeto também permitiu explorar uma questão importante da engenharia de agentes: como transformar uma resposta gerada por IA em um processo controlado, observável e passível de testes?

2. Arquitetura da solução

A automação foi organizada em quatro etapas principais: entrada, processamento com IA, classificação e registro, e saída.

Etapa 1 — Recebimento e preparação da mensagem

O workflow utiliza um Webhook para receber a solicitação e um nó de preparação de dados para organizar a entrada antes do processamento.

Essa separação facilita a identificação das responsabilidades de cada etapa e permite evoluir a estrutura de entrada sem misturar toda a lógica em um único componente.

Etapa 2 — Geração da resposta com IA

A mensagem preparada é enviada ao Google Gemini, que gera uma resposta de acordo com as instruções e regras de segurança definidas para o agente.

As instruções procuram estabelecer limites claros para o comportamento do modelo, especialmente em situações nas quais faltam informações comerciais confirmadas.

O agente deve evitar inventar serviços, preços, prazos ou políticas, além de não afirmar que consultou sistemas aos quais não possui acesso.

Essa abordagem reduz riscos, mas não garante, por si só, que todas as respostas sejam corretas. Por isso, a validação por meio de testes é parte fundamental do desenvolvimento.

Etapa 3 — Classificação e registro das solicitações

Após a geração da resposta, um nó IF verifica se o texto contém a expressão “equipe humana”.

A partir dessa condição, o workflow segue por dois caminhos:

• Atendimento comum: a solicitação não é classificada como dependente de atendimento humano.
• Análise humana: a solicitação recebe uma marcação específica e segue para registro no Google Sheets.

Os nós de edição de campos definem o valor do indicador precisa_atendimento_humano, enquanto o Google Sheets armazena as solicitações classificadas para análise posterior.

Essa etapa transforma parte da resposta gerada em dados estruturados, permitindo separar as interações comuns dos casos que exigem atenção adicional.

Entretanto, existe uma limitação técnica importante: a classificação depende de uma expressão presente no texto produzido pelo modelo. Uma mudança de redação pode provocar uma classificação incorreta, mesmo quando a intenção da resposta continua sendo a mesma.

Etapa 4 — Retorno da resposta

O workflow utiliza um nó de resposta do Webhook para devolver o resultado ao sistema que enviou a mensagem.

O fluxo foi testado com diferentes tipos de solicitação, incluindo saudações e pedidos de análise humana.

A arquitetura completa pode ser consultada no repositório do projeto, junto aos materiais de implementação e testes disponíveis.

3. Engenharia de prompt: estabelecer limites é parte da solução

Um dos principais desafios encontrados foi evitar que o agente apresentasse informações comerciais não confirmadas.

Em testes iniciais, o modelo sugeriu serviços que não estavam definidos em um catálogo oficial. Em outros cenários, indicou ações que o sistema não tinha capacidade de executar.

Para reduzir esses comportamentos, as instruções foram aprimoradas com regras voltadas a cinco aspectos:

1. Fidelidade às informações: não inventar serviços, preços ou condições comerciais.
2. Transparência operacional: não afirmar que consultou pedidos sem acesso a um sistema real.
3. Proteção de dados: evitar solicitar informações pessoais desnecessárias.
4. Limites de atuação: não prometer reembolsos ou decisões que dependem de análise humana.
5. Encaminhamento responsável: reconhecer quando uma solicitação precisa ser avaliada por uma pessoa.

A principal lição é que o prompt não deve apenas definir a personalidade do agente. Ele também precisa especificar o que o sistema pode fazer, quais informações estão disponíveis e como deve se comportar diante de limitações.

Além disso, instruções bem formuladas não substituem controles técnicos. Quando uma ação precisa ser garantida, a validação deve ocorrer também no próprio workflow ou no sistema responsável pela execução.

4. Estratégia de testes e melhorias

Os testes foram utilizados para identificar comportamentos inadequados e avaliar as alterações realizadas nas instruções e no fluxo.

Testes de comportamento do modelo

Teste 1 — Consulta sobre serviços

Pergunta: “Quais serviços vocês oferecem?”

Problema identificado: o agente apresentou opções que não estavam confirmadas em um catálogo oficial.

Melhoria: reforço das instruções para não inventar serviços e informar a necessidade de confirmação.

Resultado registrado: após o ajuste, o agente informou que precisava confirmar os serviços disponíveis.

Teste 2 — Consulta sobre preços

Pergunta: “Quanto custa a consultoria?”

Problema identificado: o agente sugeriu um encaminhamento que ainda não estava automatizado.

Melhoria: instruções para não inventar preços, evitar coleta desnecessária de dados e não apresentar encaminhamentos inexistentes como ações já realizadas.

Resultado registrado: o agente informou que os valores precisavam ser confirmados pela equipe.

Teste 3 — Consulta sobre pedido

Pergunta: “Qual é o status do meu pedido?”

Problema identificado: o agente poderia sugerir que era capaz de consultar um pedido sem possuir integração com um sistema de pedidos.

Melhoria: reforço da transparência sobre a ausência dessa integração.

Resultado registrado: o agente solicitou o número do pedido ou o e-mail da compra para identificação posterior pela equipe, sem afirmar que havia consultado o status.

Teste 4 — Reclamação e solicitação de reembolso

Pergunta: “Paguei por um serviço e não recebi. Quero meu dinheiro de volta.”

Problema identificado: a resposta inicial indicava encaminhamento humano sem que essa ação estivesse efetivamente implementada.

Melhoria: instruções para não prometer reembolso nem afirmar que um encaminhamento ocorreu.

Resultado registrado: o agente demonstrou compreensão, informou a necessidade de análise humana e solicitou um dado para identificar a compra, sem garantir a aprovação do reembolso.

Testes de classificação e integração

Teste 5 — Classificação de solicitações para atendimento humano

Foi implementada uma condição IF baseada na presença da expressão “equipe humana” na resposta do modelo.

Os testes registrados classificaram reclamações, pedidos de reembolso e uma consulta sobre pedido como casos que precisavam de atendimento humano. Uma consulta sobre preço foi classificada como atendimento comum.

Teste 6 — Saudação simples

Mensagem: “Olá, tudo bem?”

Resultado registrado: o agente respondeu cordialmente, o indicador precisa_atendimento_humano retornou false e não houve encaminhamento desnecessário.

Teste 7 — Registro no Google Sheets

Mensagem: “Quero solicitar um reembolso do meu pedido.”

Resultado registrado: o webhook retornou sucesso, o agente gerou a resposta esperada e uma nova linha foi adicionada à planilha de registro de atendimento.

Esse teste verificou a persistência dos dados da solicitação para análise posterior.

Teste 8 — Saudação sem registro desnecessário

Mensagem: “Olá, tudo bem?”

Resultado registrado: o agente respondeu normalmente e a planilha permaneceu sem alterações.

Esse cenário verificou que uma interação comum não deveria gerar um registro destinado às solicitações que precisam de análise humana.

O que os testes demonstram

Os resultados registrados indicam que o comportamento do agente pode ser melhorado por meio de instruções mais claras e que o workflow permite classificar e registrar determinados tipos de solicitação.

Esses resultados se referem aos cenários testados. Eles não representam uma garantia de desempenho em todas as mensagens possíveis nem substituem testes adicionais de robustez.

5. Limitações técnicas identificadas

Documentar as limitações é importante para distinguir uma demonstração funcional de uma solução pronta para produção.

Classificação baseada em texto

A busca por uma expressão específica é simples de implementar, mas sensível à forma como o modelo escreve a resposta. Uma abordagem mais robusta poderia utilizar uma saída estruturada, com campos definidos para a resposta, a categoria da solicitação e a necessidade de análise humana, seguida de validação no workflow.

Ausência de integração com pedidos

O agente ainda não consulta uma fonte real de pedidos. Solicitar um identificador pode ajudar uma equipe a localizar a compra, mas não equivale a consultar o sistema.

Uma evolução futura poderia integrar uma API de pedidos, com autenticação, validação de identidade e controles de acesso apropriados.

Registro não equivale a encaminhamento

O Google Sheets funciona como registro das solicitações classificadas, mas não garante que um atendente tenha sido notificado ou que o caso tenha sido assumido por alguém.

Para implementar o encaminhamento real, seria necessário integrar um canal de atendimento, estabelecer critérios de atribuição e verificar se a solicitação foi efetivamente recebida.

Dependência da qualidade das informações

Sem uma fonte oficial e atualizada de serviços, preços e políticas, o modelo não deve ser tratado como fonte de verdade sobre as condições comerciais.

Uma evolução possível seria conectar uma base de conhecimento controlada e implementar mecanismos de recuperação de informações, validação de relevância e tratamento de perguntas sem evidências suficientes.

6. Próximas evoluções do projeto

Com base nos testes e nas limitações identificadas, as próximas etapas propostas são:

• Substituir a classificação baseada em expressão textual por uma saída estruturada e validada.
• Criar uma fonte oficial de informações sobre serviços, preços e políticas.
• Implementar o encaminhamento real das solicitações para atendimento humano.
• Avaliar uma integração segura com um sistema de pedidos.
• Ampliar a cobertura de testes, incluindo mensagens ambíguas, respostas incompletas, falhas de integração e tentativas de contornar as instruções.
• Melhorar o tratamento de erros, os registros de execução e a rastreabilidade das solicitações.
• Avaliar os custos, a latência e a consistência das respostas antes de considerar uma implantação em produção.

Essas melhorias ainda devem ser implementadas e validadas; são propostas de evolução, não funcionalidades já concluídas.

7. Conclusão

Desenvolver um agente de atendimento com IA envolve mais do que conectar um modelo de linguagem a um webhook. É necessário estabelecer limites, organizar o fluxo de dados, testar diferentes cenários e reconhecer a diferença entre responder a uma solicitação e executar uma ação real.

Neste projeto, a combinação de n8n, Google Gemini e Google Sheets permitiu explorar geração de respostas, classificação condicional e registro de solicitações, além de identificar limitações importantes na classificação e no encaminhamento humano.

O aprendizado central foi que confiabilidade não depende apenas da qualidade da resposta gerada, mas também dos controles, das integrações e dos testes que sustentam o comportamento do sistema.

O projeto continua em evolução, com foco em tornar o agente mais previsível, verificável e preparado para cenários reais de atendimento.

Repositório e tecnologias

Código e documentação: github.com/valquiria87/desafio-agente-atendimento-ia

Tecnologias e conceitos: n8n, Google Gemini, Google Sheets, Webhooks, Engenharia de Prompt, automação de processos e testes de comportamento de agentes de IA.

#InteligenciaArtificial #AgentesDeIA #n8n #GoogleGemini #Automacao #EngenhariaDePrompt #DIO