Oracle AI Agent Studio: o que é, como funciona e o que avaliar

Agentes de IA já passaram a aparecer dentro das plataformas corporativas. A Oracle incorporou essa capacidade diretamente ao Fusion Cloud Applications por meio do AI Agent Studio, um ambiente de construção que permite criar, configurar, validar e publicar agentes de IA sem sair do ecossistema onde os dados e os processos já estão presentes.

Antes, a decisão envolvia avaliar se valia a pena integrar uma ferramenta externa de IA ao ERP. Agora, a empresa já tem essa capacidade disponível dentro da plataforma contratada, e o trabalho é usá-la com governança. Essa proximidade entre agente e sistema traz vantagens evidentes de integração, mas também exige método na adoção. Um agente que agenda entrevistas, calcula remuneração ou movimenta um processo de compras atua sobre dados sensíveis e regras de negócio que precisam de controle de acesso, validação e rastreabilidade.

Neste artigo veremos o que ela é, como seus componentes se organizam, quais caminhos de construção existem e quais critérios técnicos avaliar antes de habilitá-la no seu ambiente. A intenção é reduzir a complexidade da decisão, apresentando o funcionamento com precisão e apontando onde estão os pontos de atenção.

O QUE É O ORACLE AI AGENT STUDIO E ONDE ELE SE ENCAIXA NO FUSION

O AI Agent Studio é o ambiente de design do Oracle Fusion Cloud Applications dedicado à criação de agentes de IA. Nele, a equipe técnica monta agentes a partir de templates pré-configurados ou constrói agentes e fluxos multiagente do zero, ajustando comportamento por meio de prompts em linguagem natural. Por ser nativo do Fusion, o Studio acessa de forma direta as bases de conhecimento, as ferramentas e as APIs das aplicações, o que permite publicar o agente dentro do próprio fluxo de trabalho, sem a etapa de conectores e sincronizações que uma solução externa exigiria.

O alcance acompanha a suíte: os agentes podem ser configurados nos módulos de Human Capital Management, Supply Chain e Manufacturing, Procurement, Financials, CX e Permitting and Licensing.

Um aspecto que merece destaque na avaliação técnica é o modelo de segurança. O Studio herda automaticamente as configurações de segurança, as políticas e os controles de acesso já definidos no Fusion, em vez de criar um perímetro paralelo de permissões. Na prática, o acesso à configuração de agentes é concedido por duty roles específicos de cada produto, atribuídos via Security Console, o que mantém a administração dos agentes dentro da mesma disciplina de governança que a empresa já aplica ao restante da plataforma. Esse desenho reduz um dos riscos mais comuns em iniciativas de IA corporativa, que é o surgimento de uma automação com permissões mais amplas do que as dos usuários que ela representa.

Também é importante situar o que o Studio não é. Ele não é um chatbot pronto nem um produto de uso final: é um ambiente de construção, voltado a administradores e times técnicos, no qual os agentes são desenhados, testados e então disponibilizados aos usuários de negócio. A ferramenta inclui recursos próprios de validação e teste para verificar os fluxos antes da publicação, além de mecanismos de monitoramento e avaliação após o deploy. Essa separação entre desenho e uso é o que permite tratar agentes de IA com o mesmo rigor de ciclo de vida aplicado a qualquer outra customização da plataforma.

COMPONENTES DO AI AGENT STUDIO E COMO ELES SE RELACIONAM

A unidade central da ferramenta é o agent team, o time de agentes. É ele que pode ser publicado para uso, e consiste em um agente único ou em um grupo de agentes que segue uma sequência estruturada de passos para cumprir uma tarefa de negócio ou responder a uma consulta. A documentação da Oracle usa como exemplo um time de recrutamento capaz de agendar entrevistas, triar currículos, calcular remuneração e gerar propostas, sempre respeitando políticas e aprovações definidas.

Entender que o deploy acontece no nível do time, e não do agente isolado, ajuda a planejar a arquitetura desde o início: o desenho parte da tarefa de negócio completa e distribui responsabilidades entre os agentes que a compõem.

Dentro do time estão os agentes propriamente ditos, que usam um modelo de linguagem para raciocinar, criar planos de ação e interagir com usuários. A Oracle os categoriza em três tipos principais. O agente user-proxy atua em nome do usuário de negócio e conduz a conversa; o agente supervisor orquestra os demais agentes dentro do fluxo; e o agente especialista concentra uma função específica, geralmente associada ao domínio de uma ferramenta. Um mesmo time pode combinar esses tipos, e é essa combinação que sustenta os fluxos multiagente com pontos de aprovação humana onde a operação exigir.

Ao redor dos agentes existem quatro componentes que definem seu comportamento e seus limites. Os topics estabelecem as áreas de atuação do agente, delimitando sobre o que ele pode conversar e agir; um agente de benefícios, por exemplo, pode ter tópicos de previdência, planos de saúde e planos de ações. As instructions são regras em linguagem natural aplicadas a cada tópico, incorporadas aos prompts enviados ao modelo, e funcionam como guardrails de resposta, incluindo orientações do tipo "se não souber a resposta, não invente uma".

As tools são as utilidades que o agente usa para executar tarefas, como calculadora, e-mail, consulta a objetos de negócio, conectores e recuperação de documentos via RAG, e são reutilizáveis entre agentes. Por fim, o componente de testing permite validar a configuração de ferramentas, tópicos e instruções, além de conferir o raciocínio do agente e as fontes que ele cita antes da publicação.

A relação entre esses componentes segue uma lógica de níveis que facilita a governança. O time define a tarefa de negócio, os agentes dividem o trabalho, os tópicos delimitam o território de cada um, as instruções regulam o comportamento dentro desse território e as ferramentas dão capacidade de execução. Cada nível é um ponto de controle independente, o que significa que ajustar o comportamento de um agente raramente exige reconstruir o fluxo inteiro. Para quem vai administrar isso em produção, essa modularidade é o que torna viável evoluir os agentes com segurança à medida que o processo de negócio muda.

TEMPLATES PRONTOS, AGENTES DO TIPO SUPERVISOR E FLUXOS DO TIPO WORKFLOW: QUANDO USAR CADA UM

A escolha do caminho de construção deve partir da natureza da tarefa, e a documentação da Oracle organiza bem essa decisão. O template pré-configurado atende os cenários em que o processo de negócio já é comum ao mercado, como um agente de benefícios que responde dúvidas de colaboradores a partir dos documentos da própria empresa. Nesse caso, a equipe habilita o template, carrega os documentos específicos da organização e ajusta o que for necessário, sem construir nada do zero.

Um detalhe de funcionamento: os artefatos de um template, como agentes, ferramentas e tópicos, não são editáveis diretamente, então qualquer modificação exige criar uma cópia do artefato e adicioná-la ao time. A ferramenta oferece duas formas de partir de um template, Copy Template e Use Template, que se distinguem apenas pela ordem em que se renomeia o time e se editam os artefatos.

O agente customizado do tipo supervisor entra quando a tarefa exige expertises distintas e a ordem das ações depende do contexto. Um exemplo é um assistente de contratos que gera minutas com campos preenchidos, revisa contratos existentes, faz análise de risco, recomenda mudanças e encaminha para aprovação. Como cada uma dessas atividades pede uma especialização, o desenho adequado é um agente supervisor coordenando agentes trabalhadores, cada um com instruções e ferramentas próprias. A característica central desse modelo é a orquestração dinâmica: o supervisor decide, com base no contexto do problema, quais trabalhadores acionar e em que momento, de forma não determinística.

O time do tipo workflow resolve o caso contrário, em que a sequência de tarefas é conhecida de antemão e deve ser executada sempre na mesma ordem. Um exemplo é um assistente de cotações de fornecedores que processa o documento da cotação, mapeia os atributos, cria uma requisição em rascunho e a submete para aprovação. Nesse formato, agentes e artefatos são adicionados como nós de um fluxo, e cada nó executa uma função definida, como extrair dados, chamar um objeto de negócio, executar um LLM ou enviar um e-mail. A distinção prática entre os dois tipos de time é essa: supervisor para processos em que o caminho varia conforme a situação, workflow para processos determinísticos que repetem a mesma sequência.

Existe ainda a decisão anterior a essa, entre um fluxo de agente único e um processo multiagente. A orientação da própria Oracle é direta: requisitos simples, como recuperar respostas de um único documento de política, ficam bem com um agente só. Cenários mais complexos, em que múltiplos documentos precisam ser interpretados ou em que a resposta varia conforme quem pergunta, justificam múltiplos agentes, com a questão do usuário direcionada ao trabalhador adequado.

Um critério útil de arquitetura: se a descrição da tarefa cabe em um parágrafo de instruções e um conjunto pequeno de ferramentas, o agente único tende a ser mais fácil de manter, testar e explicar. A complexidade multiagente deve ser adotada quando o processo a exige, e não como ponto de partida.

COMO FUNCIONA A GOVERNANÇA DE ACESSOS E SEGURANÇA

O modelo de segurança do AI Agent Studio se apoia inteiramente na estrutura de permissões do Fusion Applications, e esse é o ponto que mais interessa a quem responde por governança. O acesso à configuração de agentes é concedido por meio de duty roles específicos de cada produto, como os papéis de administrador de agentes para CX, Financials, HCM, Supply Chain, Procurement e demais módulos. A concessão acontece pela Security Console, onde se cria um job role customizado, se adicionam os duty roles dos produtos desejados e se atribui o papel aos usuários que vão configurar agentes.

Quem precisa administrar agentes em toda a suíte recebe o conjunto completo de duty roles junto ao privilégio de gestão de todos os agentes inteligentes, enquanto o acesso restrito a um produto usa apenas o papel daquele módulo. Essa granularidade tem uma consequência de arquitetura organizacional que convém planejar. É possível, por exemplo, permitir que o time de RH configure agentes apenas em Human Capital Management, enquanto o time de operações atua em Supply Chain, sem que um tenha visibilidade sobre o ambiente do outro.

A Oracle traz também um alerta administrativo relevante: o uso de papéis predefinidos pode gerar consumo de assinatura independentemente de o serviço de nuvem correspondente ter sido contratado, o que recomenda atenção na atribuição desses papéis. Detalhes de configuração como esse raramente aparecem nas apresentações comerciais da ferramenta, mas afetam custo e governança desde o primeiro dia.

A segurança em tempo de execução segue a mesma lógica de herança. Quando um agente usa a ferramenta de objetos de negócio para consultar, criar ou atualizar registros, ele respeita os controles de acesso baseados em papel que já valem para os usuários do Fusion, e o administrador ainda pode restringir quais objetos e quais campos o agente enxerga ou ignora. No nível do time de agentes, a aba de segurança define quais papéis podem acessá-lo, o que vale tanto para o uso interno quanto para chamadas externas via API.

O efeito combinado desses controles é que o agente nunca carrega permissões mais amplas do que as do contexto em que atua, evitando que a automação escape aos controles definidos para a plataforma. Complementam esse desenho as instruções em linguagem natural com guardrails de resposta e os recursos de teste e monitoramento, que permitem verificar o raciocínio do agente e as fontes citadas antes e depois da publicação.

COMO OS AGENTES SE CONECTAM A SISTEMAS EXTERNOS

A conexão com sistemas fora do Fusion acontece por três mecanismos de natureza distinta, e entender a diferença entre eles ajuda a desenhar a integração correta para cada caso. O primeiro é o conjunto de ferramentas que o agente usa para alcançar dados e serviços externos durante a execução. A ferramenta External REST conecta o agente a aplicações SaaS internas ou externas e a APIs públicas, com parâmetros de autorização configuráveis para serviços que exigem credenciais.

A ferramenta MCP permite conexão segura a servidores que implementam o Model Context Protocol, sem a necessidade de construir wrappers REST ou lógica de plugin adicional, o que reduz o custo de integração com fontes que já expõem esse padrão. Somam-se a elas o Connector, que liga o agente a fontes de conteúdo como SharePoint e páginas web, e a possibilidade de registrar um LLM próprio via credenciais, para quem prefere usar um modelo além dos fornecidos pela Oracle.

O segundo mecanismo funciona na direção inversa: aplicações externas chamando os agentes do Fusion. Isso acontece pela API /invokeAsync, com autenticação OAuth 2.0 por meio do OCI Identity and Access Management. A configuração exige uma confiança bidirecional entre os ambientes, estabelecida pela criação de aplicações confidenciais espelhadas nos dois lados, uma no IAM do Fusion representando o sistema externo e outra no IAM do sistema externo representando o serviço do AI Agent Studio.

Em tempo de execução, a aplicação externa obtém um token de acesso, chama a API passando a mensagem do usuário e recebe um Job ID para acompanhar o processamento e recuperar a resposta, num modelo assíncrono. O acesso continua condicionado aos papéis definidos na aba de segurança do time de agentes, mantendo a coerência com o modelo de governança descrito na seção anterior.

O terceiro mecanismo é o protocolo Agent2Agent, ou A2A, voltado à colaboração entre agentes de plataformas diferentes. Trata-se de um protocolo aberto e apoiado pela indústria que padroniza a forma como agentes se descobrem, se descrevem e se chamam, eliminando integrações ponto a ponto construídas sob medida. Cada agente publica um Agent Card, um documento JSON legível por máquina que informa o que o agente é, quais habilidades oferece, como chamá-lo e qual autenticação exige, e um catálogo de agentes indexa esses cartões para descoberta com regras de acesso.

A Oracle ilustra o uso com um agente de vendas do Fusion consultando um agente de terceiros para obter opções de viagem e cotações de custo, e com um assistente corporativo genérico acionando agentes especialistas do Fusion para responder sobre políticas de RH. Para a arquitetura, o A2A é o padrão que conecta o ecossistema de agentes da empresa, antes um conjunto de sistemas isolados, com descoberta, chamada e acompanhamento de tarefas assíncronas seguindo uma referência única.

COMO VALIDAR, MONITORAR E AVALIAR AGENTES ANTES E DEPOIS DO DEPLOY

A disciplina de qualidade da ferramenta se organiza em dois momentos, e o primeiro deles acontece antes de qualquer publicação. O Playground é o ambiente de teste iterativo em que se editam prompts, parâmetros de modelo e estrutura de saída sem afetar a produção, com resultados exibidos lado a lado da configuração. A cada execução de teste, a ferramenta gera um trace detalhado com a linha do tempo da execução, mostrando quais ferramentas foram chamadas, quanto tempo cada etapa levou e qual foi o consumo de tokens de entrada e saída em cada passo.

O histórico de execuções permite comparar duas rodadas quaisquer, destacando as diferenças entre elas, e recarregar uma configuração aprovada como base para continuar o refinamento. Para quem administra a plataforma, isso significa que o ajuste de um agente ganha rastreabilidade de cada mudança testada, em vez de depender de tentativa e erro sem registro.

A avaliação estruturada complementa o teste manual por meio de evaluation sets, conjuntos que reúnem perguntas de teste, as respostas esperadas e as métricas a medir. A comparação entre a resposta do agente e a referência gera um índice de correção, e métricas específicas de RAG, como groundedness e relevância da resposta, medem o quanto a saída se apoia de fato no conteúdo recuperado dos documentos.

A orientação da Oracle é reexecutar as avaliações sempre que o agente for alterado ou quando houver atualização de modelo, confirmando que o comportamento se mantém dentro do padrão de qualidade definido. Esse ponto merece atenção no planejamento: modelos de linguagem evoluem por decisão do fornecedor, e sem uma bateria de avaliação pronta a empresa só percebe uma regressão de qualidade quando o usuário reclama.

Depois da publicação, o monitoramento acompanha o comportamento em produção com métricas de operação. A ferramenta registra taxa e contagem de erros, número de sessões, latência nos percentis 50 e 99 e consumo de tokens, incluindo a separação entre tokens de entrada, que abrangem prompts de sistema, mensagens, contexto recuperado, histórico e definições de ferramentas, e tokens de saída gerados pelo modelo.

A latência de percentil 99 em particular ajuda a identificar onde revisar prompts ou estrutura do agente quando uma parcela dos usuários enfrenta esperas longas. Como as métricas do painel dependem de um processo agendado de agregação, vale incluir a configuração desses processos no checklist de implantação, junto aos processos de importação de dados de segurança que a documentação lista como pré-requisito de funcionamento.

O QUE AVALIAR ANTES DE HABILITAR A FERRAMENTA NO SEU AMBIENTE

O primeiro critério é de governança e custo de acesso. Antes de atribuir papéis, a empresa precisa definir quem poderá configurar agentes e em quais módulos, desenhando os job roles customizados na Security Console com a granularidade adequada. O alerta da Oracle sobre consumo de assinatura na atribuição de papéis predefinidos reforça que essa definição tem efeito financeiro, e não apenas organizacional. Também entram nesse critério os processos agendados que sustentam o funcionamento do Studio, da importação de dados de segurança à agregação de métricas, que precisam estar configurados para que acesso e monitoramento funcionem como esperado.

O segundo critério é a seleção dos processos candidatos. A arquitetura da ferramenta favorece quem consegue classificar seus processos em três grupos: os que um template pronto atende com ajustes, os que pedem orquestração dinâmica com supervisor e os que seguem sequência determinística em workflow. Processos com etapas de risco, como envio de e-mails ou atualização de registros, devem ter pontos de aprovação humana definidos desde o desenho, já que a ferramenta permite inserir a revisão em qualquer ponto do fluxo. Uma seleção criteriosa nesse estágio evita o erro mais comum em iniciativas de agentes, que é aplicar orquestração complexa a tarefas que um agente único resolveria com menos custo de manutenção.

O terceiro critério envolve o ecossistema de integração e a estratégia de modelo. Convém mapear quais sistemas externos os agentes precisarão alcançar e por qual mecanismo, seja External REST com autenticação, seja MCP para fontes que já expõem o protocolo, seja o desenho de confiança bidirecional para aplicações que chamarão os agentes do Fusion. Na escolha do modelo, o Fusion oferece LLMs de fornecedores como Cohere, Meta e OpenAI, com a possibilidade de registrar um modelo próprio via credenciais, e essa escolha deve considerar requisitos de qualidade, custo por token e políticas internas de uso de IA.

Por fim, nenhuma habilitação deveria avançar sem a disciplina de avaliação montada: evaluation sets escritos antes do primeiro deploy, critérios de correção definidos e responsáveis pela reexecução após cada mudança. A ferramenta entrega os instrumentos, mas o rigor de uso é uma decisão de quem administra.

A DECISÃO QUE A FERRAMENTA NÃO TOMA POR VOCÊ

O AI Agent Studio coloca a construção de agentes de IA dentro da mesma plataforma que já concentra os dados e os processos da empresa, com herança de segurança, instrumentos de teste e métricas de produção. Isso reduz barreiras técnicas de adoção, mas desloca o peso da decisão para o desenho: escolher os processos certos, definir a governança de acesso, posicionar as aprovações humanas e sustentar a disciplina de avaliação ao longo do tempo.

São escolhas de arquitetura e de operação que determinam se os agentes vão ampliar a capacidade das equipes ou apenas adicionar complexidade ao ambiente. A Amber — parceira certificada Oracle — acompanha empresas nesse tipo de decisão em todo o ciclo, do diagnóstico do cenário atual ao desenho da solução, da implementação à sustentação contínua, com atuação em Oracle e nas principais plataformas corporativas.

Se a sua empresa avalia habilitar agentes de IA no Fusion e quer estruturar essa adoção com método, do mapeamento dos processos candidatos à governança de acessos e avaliação, fale com a gente. Respondemos em até um dia útil, e a conversa inicial já ajuda a dimensionar por onde faz sentido tomar as primeiras decisões. Entre em contato conosco.