A Forter conseguiu envolver cerca de 200 pessoas na construção de agentes de inteligência artificial durante uma maratona prática de duas semanas, depois de projetar um ambiente que reduzia a necessidade de experiência em programação e permitia que analistas e engenheiros testassem suas ideias rapidamente. Ben Maraney, engenheiro principal da empresa, apresenta a experiência como uma lição sobre a remoção de complexidade desnecessária, em vez de tentar resolver todos os desafios da construção de agentes de uma só vez.
O início: uma maratona prática com prazo de cinco semanas
O objetivo era treinar as equipes de pesquisa e desenvolvimento para criar seus próprios agentes, incluindo analistas com formação em direito, psicologia e ciências, alguns dos quais nunca haviam escrito SQL. A equipe precisava preparar o ambiente em cinco semanas e, depois, realizar uma maratona de construção de duas semanas. Por isso, o projeto se concentrou em três eixos: ferramentas, plataformas e remoção dos obstáculos para os usuários.
Um servidor MCP central em vez de ferramentas dispersas
A Forter adotou um servidor interno baseado no protocolo MCP, chamado Toolchain. O servidor fornecia uma interface única para descobrir e experimentar ferramentas e criar as conexões específicas de cada agente. Também permitia que o usuário escolhesse apenas as ferramentas de que o agente precisava, em vez de conceder acesso amplo, o que poderia confundi-lo ou levá-lo a usar ferramentas inadequadas.
O número de ferramentas cresceu de cerca de 20 quando a equipe foi criada para aproximadamente 60 no início da maratona e, depois, para quase 100 duas semanas após seu término. A unificação do repositório e a existência de exemplos e arquivos de configuração claros ajudaram a adicionar novas ferramentas rapidamente, ao mesmo tempo que ofereciam recursos de governança, como o monitoramento do consumo de tokens e do uso das ferramentas.
Em vez de construir, em um período curto, um sistema personalizado de geração aumentada por recuperação (RAG), a empresa conectou o Toolchain à plataforma Glean, usada para pesquisar fontes internas como Confluence, Asana, Jira, Slack e Salesforce. Foram disponibilizados três tipos de ferramentas: pesquisa de documentos e trechos relevantes, leitura do documento completo e resumo de acordo com uma pergunta ou um tema definido pelo agente.
De uma plataforma sem programação a soluções personalizáveis
A Forter usou o LibreChat para oferecer uma experiência de conversação rápida e com pouca programação. Os usuários podiam ver as ferramentas chamadas pelo agente, as consultas e os parâmetros enviados por ele e os resultados recebidos. Isso ajudou a compreender o comportamento dos agentes e a detectar problemas cedo, embora a integração com o MCP às vezes fosse instável, com controle limitado de versões e personalização.
Para os casos mais complexos, a empresa ofereceu repositórios de modelo que davam aos desenvolvedores controle total sobre o código, além da possibilidade de adicionar ferramentas e subagentes, mas eram mais lentos de configurar e implantar, especialmente para os analistas. Mais tarde, a Forter criou uma interface interna chamada AI Hub, que permitia escolher o modelo, escrever a mensagem do sistema, definir as ferramentas e compartilhar o agente em poucas etapas.
Já para os agentes não interativos, foi usado o framework Strands com o Argo Workflows para executá-los de acordo com cronogramas ou eventos, como a criação de tíquetes no Jira e no Asana. Maraney observa que a existência de um sistema de agendamento e execução já estabelecido pode eliminar a necessidade de uma nova arquitetura específica para agentes.
O que foi efetivamente construído?
Os usos incluíram agentes que ajudavam os analistas a formular hipóteses e experimentos melhores, revisar relatórios pós-incidente e analisar a queda no desempenho dos comerciantes usando Snowflake e notebooks do Databricks. A empresa também desenvolveu agentes especialistas, como Layla e Penny, para acessar código, configurações e dados e responder a perguntas relacionadas a decisões sobre transações e faturamento. O uso da Layla se estendeu às equipes de sucesso do cliente e suporte depois que seu conhecimento do sistema se tornou mais amplo do que o de qualquer indivíduo.
Entre os exemplos de agentes não interativos estavam a sugestão de configurações iniciais para um novo comerciante com base em comerciantes semelhantes, a preparação de pesquisas preliminares quando um tíquete de suporte chegava e a análise de alertas de anomalias, relacionando-os a alterações no código. A Forter também testou um agente de resposta a incidentes, mas descobriu que seus resultados aparentemente excelentes dependiam principalmente da cópia de análises de causa raiz escritas anteriormente por humanos em relatórios do BetterNext.
O que muda na prática?
Essa experiência mostra que a observabilidade não é um recurso secundário. Exibir as ferramentas, os parâmetros e os resultados nos quais o agente se baseava foi essencial para descobrir que o agente de resposta a incidentes não estava realmente inferindo a causa raiz. Por isso, a Forter posteriormente adicionou o Langfuse para rastrear sessões de agentes, chamadas de ferramentas e o fluxo de trabalho.
A experiência também mostra que a multiplicidade de plataformas pode ser intencional: uma plataforma sem programação para experimentação rápida, soluções de software para personalização e agentes que funcionam com base em eventos ou cronogramas. Por outro lado, a empresa enfrentou problemas com o modelo de criar um repositório separado para cada agente e depois voltou a usar um número menor de repositórios que reuniam agentes relacionados, facilitando a introdução de capacidades compartilhadas, como o rastreamento.
Maraney também alerta que métricas gerais de avaliação, como relevância, coerência e segurança, podem dar uma falsa impressão de qualidade. Uma avaliação útil deve testar a correção da resposta, o uso das ferramentas adequadas e a recuperação do contexto correto, aspectos mais difíceis que exigem conhecimento preciso do que significa uma boa resposta. Por isso, avaliações avançadas podem ser adiadas em experimentos internos nos quais o ser humano continua participando do processo de decisão, mas isso não deve ser considerado uma alternativa permanente à avaliação.
As iniciativas de expansão também precisam envolver as equipes jurídicas e de segurança desde cedo, especialmente no que diz respeito ao local de processamento e à retenção dos dados. Maraney afirma que o uso de um serviço de nuvem como o Amazon Bedrock, acompanhado da documentação de políticas de não retenção de dados, ajudou a lidar com essas preocupações dentro dos controles da empresa, em vez de transformar cada agente em um caso separado de aprovação.