Muitos agentes de IA em produção ainda operam focados em sessão. Eles desempenham bem tarefas pontuais, porém perdem o contexto relevante quando a conversa termina. O usuário sente isso como fricção: repetir informações, corrigir respostas e reconstruir um contexto que já havia enviado. A empresa sente de outro jeito. Agentes que não melhoram com o uso, pouca personalização e um custo em tokens que se repete a cada conversa.
Existe também um problema organizacional. Agentes nascem em times, plataformas e domínios distintos, e em algum momento um precisa do que o outro sabe. O protocolo aberto A2A (Agent to Agent) existe para que agentes se descubram e troquem tarefas sem uma integração construída caso a caso.
O produto
O Oracle AI Database Private Agent Factory é a plataforma da Oracle para construir, testar, publicar e operar agentes de IA sem código, junto ao dado corporativo. É uma aplicação em container instalada ao lado de um Oracle AI Database 26ai, e o banco é o repositório de tudo o que compõe o agente: definições, usuários e papéis, fontes de dados, vetores dos documentos e, a partir da versão 26.7, a memória. O mesmo banco que guarda pedidos e clientes guarda o que o agente sabe e o que ele aprende, com a mesma segurança, o mesmo backup e a mesma governança.
Na interface, o Agent Builder é um canvas visual que conecta modelos de linguagem, bases de conhecimento, consultas ao banco em linguagem natural, procedimentos PL/SQL, APIs REST e ferramentas MCP (Model Context Protocol). Três agentes prontos cobrem os casos mais frequentes: o Knowledge Agent, para documentos; o Data Analysis Agent, para dados estruturados; e o Deep Data Research Agent, para pesquisa em acervos extensos.
O canvas acima é o fluxo usado nos testes, um agente de atendimento de uma empresa fictícia, montada só para o laboratório:
- Chat input recebe a mensagem do usuário.
- Agent escolhe o modelo, recebe as instruções e aciona ferramentas conforme a pergunta.
- Knowledge Agent responde sobre a política comercial a partir de um PDF.
- MCP server expõe ferramentas externas.
- Select AI Bridge converte perguntas sobre pedidos em SQL e as executa no banco.
- Chat output devolve a resposta.
A versão 26.7, publicada em 14 de agosto de 2026, trouxe dois recursos para os problemas descritos acima: a memória durável, para que o agente retenha fatos e preferências entre conversas, e o suporte ao A2A, para que ele delegue trabalho a outros agentes e receba trabalho deles. Este artigo apresenta o que foi observado ao testar os dois em um Private Agent Factory 26.7 instalado pelo OCI Marketplace com um Autonomous AI Database 26ai. Todos os tempos citados são desse ambiente de teste e variam conforme instalação, modelo e carga.
Memória durável
A memória de longo prazo são fatos e preferências que o produto extrai da própria conversa, guarda no banco e recupera em conversas futuras do mesmo usuário com o mesmo fluxo. Ela é diferente do histórico da conversa em curso, que vale só para a sessão ativa, e da base de conhecimento, que é igual para todos os usuários.
Ligar a memória tem dois passos. O administrador escolhe, em Application Settings → Agent Memory, o modelo de embedding que indexará as memórias. No teste, o escolhido foi o multilingual-e5-base, que roda na própria máquina do produto, sem enviar texto a nenhum serviço externo. Quem monta o fluxo encontra, no nó Agent, uma aba Memory com dois controles, ambos ligados por padrão: Enable memory ativa a memória para o fluxo, e Share memory between chat threads permite a uma conversa nova usar as memórias de conversas anteriores do mesmo usuário. A documentação fixa o escopo: a memória é do usuário e do fluxo, e não é compartilhada entre usuários nem entre fluxos.
O schema do repositório mostra qual motor grava e recupera essa memória: o Oracle AI Agent Memory, o SDK em Python que a Oracle publica para dar memória persistente a agentes sobre o Oracle AI Database. As memórias ficam em tabelas com uma coluna VECTOR e índice do AI Vector Search, no mesmo banco que guarda os pedidos e os clientes. Elas herdam o controle de acesso e a auditoria do banco, podem ser consultadas com SQL e apagadas registro a registro. Para quem programa, o mesmo motor está disponível com pip install oracleagentmemory.
No Chat history, a ação Inspect Memory mostra as memórias recuperadas em cada turno, as mensagens armazenadas e as conversas de origem.
Por trás do painel, a sequência de um turno é sempre a mesma. Ao receber a mensagem, o produto busca memórias relevantes, em 80 a 230 milissegundos no ambiente de teste, e as insere como texto antes da pergunta. O agente responde. Depois, em segundo plano, o produto extrai novos fatos e preferências e os grava no banco, entre 28 e 45 segundos após o turno nos lotes observados. A extração não afeta a experiência do usuário, que já recebeu a resposta.
O retorno mais visível apareceu em uma pergunta simples, “qual é o meu segmento?”. Com memória, o agente respondeu em 3,3 segundos, sem acionar ferramenta nenhuma. Sem memória, acionou o Select AI, consultou a tabela de clientes e respondeu em 20,7 segundos com uma lista genérica de segmentos, porque nada na pergunta dizia quem era a pessoa. Neste exemplo, a memória devolveu personalização, poupou uma ida ao banco e reduziu o tempo de resposta em mais de 80%. Quanto mais um fato é reutilizado, mais recuperações e mais tokens ele evita, e por isso a memória compensa mais onde as mesmas pessoas voltam com o mesmo contexto, como atendimento, suporte e operação.
Dois cuidados observados nos testes: a extração é generosa e registra tudo o que a conversa diz, inclusive uma instrução usada só para medir tempos. Vale revisar o Inspect Memory nas primeiras semanas e tratar a memória como um dado que se cura, não como um log que se acumula.
Falar com outros agentes: A2A
O A2A é um protocolo aberto para que agentes se descubram e troquem tarefas, independentemente da tecnologia em que foram construídos. Cada agente publica um Agent Card, um documento JSON que descreve o que ele faz, onde recebe mensagens e como se autentica.
Na 26.7, o Private Agent Factory fala A2A nas duas direções. Para expor um agente, publica-se o fluxo e habilita-se o A2A. O produto gera a URL do Agent Card e uma chave de API específica daquele agente. Para consumir um agente de fora, registra-se a URL do card em Utilities → A2A Agents, e o agente externo aparece no canvas como o nó External Agent. A documentação delimita o suporte: A2A 1.0 com compatibilidade 0.3, JSON-RPC sobre HTTPS, conteúdo em texto, sem streaming nem notificações por push nesta versão.
Para testar a interoperabilidade de verdade, o outro lado foi um agente construído com o SDK aberto do protocolo, em Python, que informa a capital de um país e assina cada resposta. Depois de três ajustes no Agent Card, o agente apareceu como Connected, e um fluxo com o nó External Agent respondeu à pergunta sobre a capital do Chile com a resposta assinada pelo agente externo, em cerca de um segundo. Na direção contrária, um cliente A2A escrito com o mesmo SDK leu o Agent Card do fluxo, autenticou-se com a chave e perguntou o prazo de devolução. A resposta veio do Knowledge Agent. Um agente de outra plataforma usou o conhecimento corporativo que o Private Agent Factory governa, sem nenhuma integração escrita à mão.
Memória e A2A, cada um no seu lugar
A memória durável pertence ao usuário humano identificado. Uma chamada A2A vem de outro agente, agindo em nome de quem sabe quantos usuários finais. No teste, ao habilitar o A2A no fluxo, o controle Share memory between chat threads apareceu desligado, sem intervenção manual, e o cliente externo recebeu a política completa de devolução, não a versão personalizada que o mesmo agente dá à usuária no chat.
Daqui sai uma regra de arquitetura simples: memória é para conversas com pessoas identificadas. Quando os dois recursos precisarem coexistir, o desenho natural é separá-los em fluxos distintos: um conversacional com memória, voltado ao usuário, e fluxos de integração sem memória, voltados aos agentes.
Em resumo
Com a 26.7, um agente construído sem código no Private Agent Factory passa a aprender com o uso, e tudo o que ele aprende fica no Oracle AI Database que a empresa já governa, ao lado dos vetores e do dado de negócio. E passa a conversar com qualquer outro agente que fale A2A, nas duas direções. Para quem já tem o banco, é um caminho curto entre a prova de conceito e um agente em operação.
Por onde começar
- Instalar pelo OCI Marketplace e preparar o banco conforme Database Preparation and Grants.
- Escolher o embedding da memória em Application Settings → Agent Memory (Configure Agent Memory). A decisão é única.
- Ligar a memória na aba Memory do nó Agent (Agent Builder) e testar em duas conversas, com um minuto entre elas.
- Habilitar o A2A no fluxo publicado e registrar agentes externos em Utilities → A2A Agents (A2A Agents).
O workshop The Private Agent Factory: Turn Data into Action cobre a instalação e os primeiros agentes, e o motor de memória está documentado em Oracle AI Agent Memory.