Automação sem erros de contexto: como evitar que a IA decida por si

A maioria das PMEs que já deu o salto para a automação sem erros de contexto ainda enfrenta um problema silencioso: quando o sistema precisa de saber quem pediu uma acção, confia essa decisão ao modelo de inteligência artificial. E o modelo, por muito bom que seja, às vezes troca um dígito num identificador, inventa um nome ou simplesmente alucina. O resultado? Um email de confirmação que vai parar à pessoa errada, uma reunião agendada para o cliente do lado ou um documento gerado com dados de outro utilizador. Agora, uma discussão na comunidade n8n mostra como injectar esses dados de contexto — como o ID do utilizador ou da sessão — directamente a partir do agente que faz o pedido, sem que o LLM alguma vez lhes toque. E tudo isto mantendo o hub de ferramentas centralizado, sem duplicar workflows.

O que é e como funciona

Imagine um restaurante onde o empregado, sempre que leva um pedido à cozinha, tem de escrever o número da mesa num papel. Se o empregado se engana, o prato vai para a mesa errada. No mundo das automações com n8n, o empregado é o modelo de linguagem (LLM) e o número da mesa são campos como userId ou sessionId. Até agora, a prática comum era pedir ao LLM que preenchesse esses campos através de funções como $fromAI('userId', ...). Funcionava muitas vezes, mas falhava precisamente quando era mais crítico — com UUIDs longos, caracteres semelhantes ou contextos ambíguos.

A nova abordagem, detalhada num tópico da comunidade n8n, elimina essa fragilidade. Em vez de o LLM decidir o valor, o próprio agente que invoca a ferramenta já transporta consigo o contexto de execução — o ID do utilizador autenticado, o identificador da sessão de chat, o fuso horário. Esse contexto é injectado directamente nos sub-workflows das ferramentas, através do nó MCP Server Trigger, sem nunca passar pelas “mãos” do modelo. É como se o restaurante tivesse um sistema que lê automaticamente o número da mesa onde o empregado está, sem lhe pedir para o escrever.

Na prática, o fluxo mantém-se centralizado: um workflow “Tool Hub” expõe várias ferramentas (enviar email, gerir agenda, gerar documentos) através do protocolo MCP. Um agente separado liga-se a esse hub via MCP Client Tool e, quando recebe uma mensagem de um utilizador, guarda os dados de identidade num nó Set. A diferença está em como esses dados chegam às ferramentas: em vez de serem passados como inputs preenchidos pelo LLM, são injectados a partir do contexto de execução do cliente, garantindo que cada acção é executada exactamente para o utilizador e sessão correctos.

O que diferencia das alternativas

Até agora, a opção para quem usava o nó MCP Server Trigger era confiar no LLM para preencher campos de identidade. Isso obrigava a validações manuais posteriores, a logs de auditoria constantes e, mesmo assim, a uma taxa de erro que tornava o sistema pouco fiável para operações sensíveis. Outras plataformas de automação resolvem o problema de forma diferente — algumas exigem que cada ferramenta seja ligada directamente ao agente, perdendo a centralização; outras simplesmente não expõem o contexto de sessão, obrigando a workarounds frágeis.

A solução discutida na comunidade n8n distingue-se por três pontos. Primeiro, mantém o hub de ferramentas completamente centralizado — não é preciso duplicar lógica de negócio em cada agente. Segundo, remove a dependência do LLM para dados que são puramente contextuais, devolvendo ao sistema a responsabilidade pela identidade. Terceiro, é open-source e pode ser implementada com a versão self-hosted do n8n, sem custos adicionais de licenciamento. Para uma PME que já utiliza n8n como orquestrador, isto significa que pode dar o salto para automações multiutilizador sem reescrever tudo do zero.

O que isto significa para PMEs portuguesas

Para um director geral de uma PME com 10 colaboradores, a diferença entre uma automação que “quase sempre funciona” e uma que “nunca falha na identidade” é a diferença entre confiar e não confiar no sistema. Quando um comercial pede ao assistente virtual para “enviar a proposta ao João”, e o sistema envia para o João errado porque o LLM trocou dois caracteres no UUID, a confiança desaparece. Com a injecção directa de contexto, esse risco é eliminado — o sistema sabe sempre quem fez o pedido e em que sessão está, sem margem para interpretação criativa.

Este padrão é particularmente relevante para empresas que já usam ou planeiam usar automatização de email em cenários multiutilizador, como equipas de vendas ou suporte. Também se aplica a agendamento de reuniões, geração de documentos personalizados e qualquer fluxo onde a identidade do utilizador seja crítica. O custo de implementação é essencialmente o tempo de um perfil técnico para reconfigurar os nós — não há licenças extra, porque o n8n self-hosted é gratuito. E o retorno aparece na primeira vez que se evita um erro com consequências reais, como um email com dados pessoais enviado ao destinatário errado, com implicações de RGPD e privacidade de dados.