Como integramos agentes de IA à plataforma SimpleOne: arquitetura, cenários e segurança

Em um ambiente corporativo, os assistentes de IA rapidamente atingem um limite: eles podem responder a perguntas, mas não conseguem executar tarefas. É possível solicitar informações, mas não é possível instruí-los a gerar um ticket, compilar dados de incidentes, enviar um resumo ou localizar objetos relacionados.

Enquanto isso, os agentes de IA estão dominando as discussões do setor. Ao contrário de um chatbot ou de um assistente padrão, um agente opera de forma autônoma. Ao receber uma solicitação, um agente de IA avalia suas ferramentas disponíveis e decide a sequência ideal para utilizá-las. Não há scripts rígidos e predefinidos — apenas um conjunto de métodos e instruções que definem o que o agente está autorizado a fazer.

Neste artigo, a equipe da SimpleOne detalha a arquitetura dos agentes dentro de nossa plataforma GenAI: seus componentes principais, como eles se integram aos processos de negócios e o que podem realizar em um ambiente de produção.

A GenAI opera em todas as camadas da nossa plataforma: nas ferramentas de low-code, no ESM e em aplicativos de negócios prontos para uso, como o ITSM. No SimpleOne, a IA é uma camada nativa da plataforma, integrando-se perfeitamente aos direitos de acesso, fluxos de trabalho e regras de negócios.

Nosso parceiro de tecnologia, a Ainergy, é responsável pela orquestração de modelos. A base arquitetônica da plataforma SimpleOne garante uma interação segura com o conhecimento corporativo por meio do RAG (Retrieval-Augmented Generation) e de mecanismos de segurança. Ferramentas específicas e universais são desenvolvidas sobre essa base: agentes autônomos, serviços de IA prontos para uso para integração em fluxos de trabalho e interfaces de usuário.

É por meio dessa abordagem que os agentes de IA se tornaram parte integrante dos processos de negócios da nossa plataforma. Veja a seguir como um agente é estruturado:

O agente é uma configuração que combina uma instrução e um adaptador. A instrução define a identidade e a função do agente: seu contexto de trabalho e os problemas específicos que ele resolve. Essencialmente, trata-se de um prompt do sistema. Por exemplo: “Você é um analista de incidentes. Todos os dias, você reúne os incidentes encerrados nas últimas 24 horas e os transforma em um artigo da Base de Conhecimento.” O agente se conecta a um adaptador, que lhe concede acesso às suas ferramentas.

O adaptador é um kit de ferramentas reutilizável. Um administrador o configura uma única vez e pode conectá-lo a vários agentes. Embora a própria plataforma possa hospedar uma vasta gama de métodos, um agente específico vê apenas as ferramentas incluídas no adaptador que lhe foi atribuído. Um adaptador pode atender a vários agentes; por exemplo, um kit de ferramentas geral para leitura de dados da plataforma não precisa ser recriado para cada agente individualmente.

O adaptador reúne dois tipos de ferramentas: métodos e ferramentas MCP. Para o agente, elas são funcionalmente idênticas — ele simplesmente visualiza uma lista unificada e seleciona a ferramenta certa para a tarefa.

Métodos são ferramentas executadas dentro da plataforma SimpleOne: buscar dados de uma tabela, criar um registro ou acionar um script. Os administradores descrevem e adicionam esses métodos ao adaptador. Um agente não pode, fisicamente, executar uma ação que não esteja presente em seu adaptador; ele não pode inventar ferramentas na hora.

Ferramentas são ações que o agente pode invocar por meio de um servidor MCP (Model Context Protocol): buscar dados externos, localizar um documento, criar um registro ou interagir com um sistema de terceiros.

O Nexus é o gateway de roteamento para o modelo de linguagem. É aqui que você define qual LLM será usado, qual endpoint chamar e com quais parâmetros. Um único Nexus pode ser conectado a vários agentes, permitindo que os administradores troquem o modelo de IA subjacente globalmente com uma única alteração de configuração.

Quando um agente recebe uma tarefa, o modelo de linguagem analisa a lista de ferramentas disponíveis em seu adaptador, lê suas descrições e decide qual ferramenta chamar, quais parâmetros passar e como processar o resultado. Não há uma sequência de etapas pré-definida; o agente constrói dinamicamente o caminho de execução para atingir a meta alvo.

Uma característica arquitetônica crucial é o modelo de execução híbrido para agentes. Por padrão, os agentes são executados em um ambiente de execução nativo dentro do SimpleOne — exatamente o mesmo ambiente que hospeda seus dados e processos de negócios. O agente acessa objetos da plataforma diretamente, sem depender de integrações intermediárias ou contêineres externos. Qualquer ação disponível para um usuário na interface do usuário está disponível para o agente no nível da plataforma. Isso garante acesso direto aos dados, segurança previsível (os dados nunca saem do perímetro corporativo) e menos pontos de falha em comparação com arquiteturas de tempo de execução externas.

Simultaneamente, a plataforma oferece suporte a ambientes de execução externos para agentes por meio do MCP. Isso atende a cenários em que um cliente já mantém sua própria infraestrutura de agentes em uma pilha de código aberto, ou quando os dados necessários residem em sistemas externos, em vez de dentro do SimpleOne. Ambas as abordagens podem ser combinadas de forma integrada em uma única plataforma.

Você precisa de um agente se já conta com fluxos de trabalho? Geralmente, sim — mas não para todas as tarefas. Em um fluxo de trabalho padrão, as entradas e saídas em cada etapa são previsíveis, permitindo que você mapeie todo o processo com antecedência. Um agente é necessário quando a situação varia a cada vez, e você simplesmente não consegue codificar de forma rígida todos os cenários de ramificação possíveis.

Por exemplo, em um Service Desk, um usuário pode enviar um ticket dizendo qualquer coisa, desde “não abre” até “tudo está quebrado” ou “não consigo fazer login desde ontem”. Um agente determina de forma autônoma quais perguntas esclarecedoras fazer, onde buscar os dados necessários e qual resposta formular. Não há um roteiro fixo; cada solicitação é única. É aí que a IA de agente agrega o máximo valor.

Por outro lado, considere o exemplo do agente-analista mencionado anteriormente. Todos os dias, ele coleta incidentes encerrados e compila um artigo resumido. Aqui, a sequência de etapas é estática e conhecida de antemão — ele age mais como um pipeline automatizado. O agente é altamente eficaz nessa função porque gera um texto coerente e analítico, em vez de simplesmente transferir dados brutos de A para B. No entanto, trata-se fundamentalmente de um processo determinístico, e não de tomada de decisão autônoma.

Como implantar um agente

Um agente de IA configurado no SimpleOne pode ser acionado a partir de três pontos diferentes, dependendo do contexto operacional.

1. Construtor de Fluxo de Trabalho

O agente é incorporado a um fluxo de trabalho da mesma forma que qualquer bloco de ação padrão. Anteriormente, os desenvolvedores precisavam criar subfluxos para lidar com ações não lineares dentro de um processo. Agora, um agente substitui o subfluxo em situações em que as etapas específicas não podem ser rigidamente mapeadas com antecedência.

Por exemplo, considere um fluxo de trabalho de desenvolvimento de software. As etapas são padrão: coleta de requisitos, desenvolvimento, revisão de código, testes, documentação e implantação. No entanto, um único bloco não pode representar cada etapa. “Desenvolvimento” envolve dezenas de chamadas ao Git e um ambiente de execução separado; “testes” envolvem a geração e a execução de autotestes; “documentação” tem sua própria lógica complexa. Uma parte desse trabalho é executada fora do ambiente de execução da plataforma, em infraestrutura externa, por meio do MCP.

O cenário muda a cada vez: algumas etapas são puladas, outras são adicionadas, e as revisões de código são executadas iterativamente até que o código seja aprovado. Não é possível construir um subfluxo determinístico para esse nível de variação.

Portanto, é possível substituir cada etapa (ou paralelizá-las) por blocos de agentes. O fluxo de trabalho não é montado a partir de dezenas de blocos de ação, mas sim de agentes. Não é necessário construir um subprocesso rígido; o agente decide a sequência e seleciona as ferramentas necessárias para concluir sua etapa específica.

2. Widget de API

Um agente pode ser incorporado diretamente na interface do usuário e acionado via API — seja um widget de portal, um formulário de inscrição ou um chat de mensagens instantâneas. O usuário interage com uma interface familiar e permanece alheio à mecânica subjacente do agente: ele digita uma solicitação e, nos bastidores, o agente seleciona ferramentas, executa ações e retorna o resultado para essa mesma interface.

A implementação mais comum é um widget de chat. O usuário digita uma mensagem no chat do portal, o widget a encaminha ao agente via API, o agente realiza o trabalho e envia a resposta de volta. Essa é uma opção altamente flexível para cenários personalizados: você define o design da interface e o ponto de acionamento. É ideal para tarefas rápidas e pontuais, não vinculadas a um processo de ponta a ponta.

3. Assistente Inteligente Universal

Oferecer uma interface conversacional pronta para uso na plataforma é, essencialmente, uma aplicação específica de uma chamada de API que você não precisa construir do zero. Detalhamos isso na seção a seguir.

Agente dos Agentes: a Interface Conversacional

Na maioria dos ambientes corporativos, o assistente de IA existe em um silo separado dos processos de negócios — é uma interface de chat que responde a perguntas, mas não possui permissões para acessar dados ou executar ações dentro da plataforma. Para o autoatendimento corporativo, desenvolvemos um “agente dos agentes” — um assistente inteligente universal. Por trás da interface de chat, há vários agentes equipados com adaptadores, métodos e instruções configurados.

O usuário vê um chat padrão. Nos bastidores, o agente orquestrador recebe a solicitação, seleciona as ferramentas necessárias de seu adaptador e executa ações dentro da plataforma: pesquisar dados, criar registros, consultar a Base de Conhecimento corporativa ou chamar sistemas externos via MCP. O resultado é retornado de forma integrada ao diálogo.

Como é configurado: um administrador cria uma configuração para uma tarefa específica ou um grupo de usuários. Ele conecta o agente, atribui um adaptador com as ferramentas adequadas e habilita o RAG, se necessário. Quando o RAG está ativo, o agente busca fragmentos relevantes em documentos corporativos para responder a uma consulta, usa-os como contexto para o LLM e cita explicitamente os documentos nos quais se baseou. O agente não inventa respostas; ele faz referência a materiais concretos da sua Base de Conhecimento.

É possível manter várias configurações simultaneamente: uma para a equipe de suporte de TI (com acesso a incidentes e à Base de Conhecimento), outra para analistas financeiros (com acesso a relatórios e dados da plataforma) e uma terceira como assistente geral, não especializado. Os usuários veem apenas as configurações às quais o administrador lhes concedeu acesso explicitamente.

Como isso difere de um widget de chat padrão: embora seja possível criar um widget que chame um agente via API para cenários personalizados, o Assistente resolve um problema diferente. Ele oferece uma interface pronta para uso, otimizada nativamente para interagir com agentes, completa com memória de diálogo e integração direta com o conhecimento corporativo. Você não precisa criá-lo, basta configurá-lo para a tarefa.

Além disso, um agente pode criar outro agente. Se um agente dispõe de métodos para trabalhar com entidades da plataforma, ele pode configurar um novo agente diretamente a partir do diálogo: o usuário descreve a tarefa, e o assistente monta um agente para lidar com ela. Esse é um benefício direto de nossa arquitetura unificada: um agente interage com entidades da plataforma por meio de métodos, e uma “entidade de agente” não é exceção.

Em breve, apresentaremos suporte para subagentes: um agente poderá delegar partes de uma tarefa a outro diretamente dentro do diálogo. Isso possibilita cenários em que uma única solicitação do usuário aciona uma cadeia em cascata de agentes especializados, cada um operando dentro de seu próprio adaptador e área de responsabilidade definida.

Estudo de caso: Agente Analista de Incidentes no Suporte de TI

Vejamos outro exemplo de atividade de um agente. Esse foi o primeiro Proof of Concept (PoC) de agente que a equipe do SimpleOne desenvolveu na plataforma. Embora ainda não esteja implantado em produção, ele ilustra perfeitamente como um agente opera, desde a configuração inicial até o resultado final.

A tarefa do agente: todos os dias, agregar incidentes encerrados da plataforma e compilá-los em um artigo da Base de Conhecimento.

A instrução (função): “ Você é um analista de ITSM. Você coleta dados de incidentes e os estrutura em material legível para a Base de Conhecimento.” Ele está conectado a um Nexus que o direciona para um modelo de linguagem selecionado.

O adaptador: contém seis métodos. O agente determina de forma autônoma a ordem e a seleção desses métodos em cada etapa:

1. Fazer uma pergunta de esclarecimento / refinar os parâmetros da tarefa.
2. Localizar a tabela de incidentes no banco de dados da plataforma.
3. Consultar a tabela para buscar incidentes encerrados em um período específico.
4. Analisar os dados (o modelo de linguagem processa os incidentes recuperados).
5. Criar um rascunho de artigo para a Base de Conhecimento.
6. Encerre a sessão.

Em um teste, o agente recuperou dados relativos a incidentes de conexão com a internet e os formatou em um artigo da Base de Conhecimento. O artigo foi gerado automaticamente, sem qualquer intervenção humana durante as fases de coleta de dados e elaboração do rascunho.

Fundamentalmente, o agente opera estritamente dentro das permissões do usuário que o iniciou. Ele não pode acessar dados que o usuário não possa ver e não realiza nenhuma ação que não seja explicitamente permitida. Cada etapa é registrada: o administrador pode ver exatamente quais ferramentas o agente invocou, quais dados solicitou e o que retornou.

A decisão final, no entanto, continua a cargo de um ser humano (Human-in-the-Loop). Depois que o artigo é redigido, um funcionário o revisa e aprova para publicação. O agente automatiza o trabalho pesado — coleta, processamento e redação —, mas não substitui o ser humano quando são necessários julgamento crítico e responsabilidade.

Todo o caminho de execução do agente é totalmente rastreável, etapa por etapa: qual método foi chamado, com quais parâmetros, qual foi a resposta e como o modelo interpretou o resultado antes de passar para a próxima etapa. Essa observabilidade é vital para depurar e refinar a forma como o agente toma decisões.

Segurança e Controle de Acesso

Os agentes na plataforma SimpleOne GenAI operam com base na arquitetura de segurança existente da plataforma. O agente age em nome do usuário que iniciou a sessão: as permissões da plataforma são calculadas dinamicamente no exato momento em que os dados são acessados, aplicadas especificamente a esse usuário. Isso garante que um agente não possa acessar dados restritos ao usuário — mesmo que o método necessário exista no adaptador do agente. Cada ação é registrada no log da plataforma: quem, quando, por meio de qual agente e o que foi feito com os dados.

Além dessa base da plataforma, adicionamos uma camada de controle específica para cada agente. Por exemplo, o administrador define os métodos no adaptador. Um agente não consegue, fisicamente, executar uma ação que não esteja presente em seu adaptador. Ele não cria ferramentas na hora, nem consulta o banco de dados diretamente. Tudo o que está disponível para o agente é explicitamente definido e permitido. A plataforma não tolera nenhuma autonomia não autorizada.

As permissões da plataforma regem o acesso aos dados e aos objetos do sistema. Os critérios de ACL (Lista de Controle de Acesso) no nível do método adicionam uma camada extra: eles determinam se um usuário pode invocar um método específico por meio de um agente, mesmo que tenha acesso aos dados subjacentes. Por exemplo, você pode permitir que um usuário leia incidentes, mas proibir que ele execute um agente que atualize esses incidentes em massa.

Em resumo, trata-se de um modelo de segurança de três camadas:

1. As permissões da plataforma determinam o que um usuário pode fazer de maneira geral no sistema.
2. O acesso ao agente determina quais agentes um usuário tem permissão para iniciar.
3. O acesso a métodos (em desenvolvimento) determina quais ferramentas específicas um agente tem permissão para usar durante a sessão desse usuário.

Próximos passos

Planejamos implementar habilidades para agentes — um passo evolutivo das instruções básicas para instruções reutilizáveis. Atualmente, um agente recebe uma instrução abrangente. Com as habilidades, ele poderá carregar dinamicamente a habilidade específica necessária para uma tarefa precisa dentro de uma sessão. Isso permite que os administradores planejem cenários altamente complexos sem sobrecarregar o prompt do sistema, oferecendo controle granular sobre o comportamento do agente em diversas situações. Nossa biblioteca de métodos e habilidades prontas para uso se expandirá, permitindo que você monte um agente para uma tarefa padrão usando modelos pré-criados, em vez de escrever tudo do zero.

Resumindo, acreditamos firmemente que os agentes de IA em uma plataforma empresarial só têm valor na medida em que estão organicamente integrados aos seus processos e dados existentes. A abordagem que estamos adotando com o SimpleOne GenAI baseia-se exatamente nesse princípio: o agente trabalha com exatamente os mesmos objetos, permissões e integrações que o restante da plataforma. Não requer nenhuma infraestrutura paralela para acessar dados corporativos — tudo o que já existe em seu sistema fica acessível ao agente por meio de métodos e adaptadores.

O MCP expande essa lógica para sistemas externos. Por meio de um mecanismo unificado, o agente obtém acesso a ferramentas externas como Jira, Confluence, sistemas de monitoramento e muito mais. Além disso, a própria plataforma pode atuar como um servidor MCP para agentes externos. Nesse cenário, os dados e processos corporativos da SimpleOne passam a fazer parte, de maneira integrada, de qualquer ecossistema mais amplo de agentes que sua empresa utilize. Já abordamos esse tema em um artigo separado.