GraphSummit London 2026 — A camada de conhecimento para uma IA confiável, Emil Eifrem

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: GraphSummit London 2026 - The Knowledge Layer for Trustworthy AI, Emil Eifrem · Canal: Neo4j · 49:25 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings

Resumo

Emil Eifrem explica como bancos de dados em grafo ajudam a representar dados conectados e complexos e por que essa arquitetura é importante para a IA empresarial. Ele argumenta que o principal gargalo dos agentes não é a inteligência dos modelos, mas o acesso ao contexto correto, no momento certo, em meio a dados fragmentados e inconsistentes. Para enfrentar esse desafio, apresenta três pilares: significado, alcance dos dados e aprendizado contínuo, apoiados por ontologias, raciocínio multihop e memória. Por fim, descreve a arquitetura da camada de conhecimento e o Neo4j Context Engine como formas de tornar agentes mais confiáveis em organizações.

Pontos-chave

Dados conectados e complexos podem ser representados naturalmente por nós, relacionamentos e propriedades em um grafo.
Com a chegada dos agentes, sistemas de IA passam a ser uma terceira categoria de consumidores de dados, além de aplicações e pessoas.
Em grandes empresas, a confiabilidade dos agentes é prejudicada por entidades não resolvidas, dados desatualizados e informações conflitantes.
O gargalo da IA empresarial é fornecer o contexto correto aos modelos, não simplesmente aumentar a inteligência dos modelos.
A camada de conhecimento precisa oferecer significado, alcance seguro dos dados empresariais e aprendizado contínuo.
Ontologias podem explicitar conceitos de negócio e conectá-los à estrutura técnica dos sistemas e fontes de dados.
O raciocínio multihop permite combinar informações dispersas por diversos sistemas para responder a perguntas complexas.
A memória dos agentes deve fechar o ciclo entre conhecimento, skills e atualização com base em novas informações.
O Neo4j Context Engine reúne ontologia, execução, memória e governança para apoiar a implementação da arquitetura.

Capítulos

Início	Capítulo	Resumo
00:00	A origem da Neo4j e o problema dos dados	Emil Eifrem conta a história da empresa e como dados complexos expuseram os limites das abstrações relacionais no projeto que deu origem à Neo4j.
04:11	Grafos como modelo para dados conectados	A palestra apresenta nós, relacionamentos e propriedades como abstrações adequadas para representar dados interconectados.
06:48	Agentes como novos consumidores de dados	Eifrem explica que agentes se somam a aplicações e pessoas como consumidores de dados e ilustra o desafio com uma decisão de atendimento bancário.
12:28	O contexto como gargalo da IA empresarial	O palestrante argumenta que os modelos já são muito capazes, mas precisam receber dados corretos e contextualizados para agir com confiabilidade.
19:19	Os três pilares da camada de conhecimento	A palestra organiza a solução em significado, alcance dos dados empresariais e aprendizado contínuo.
27:34	Alcance dos dados e raciocínio multihop	Eifrem mostra como agentes precisam percorrer dados dispersos por sistemas e relações para executar tarefas empresariais de ponta a ponta.
34:21	Memória e aprendizado dos agentes	A seção apresenta tipos de memória e a importância de um ciclo que atualize conhecimento e skills quando as informações mudam.
38:04	A arquitetura da camada de conhecimento	O palestrante reúne ontologias, alcance dos dados e memória em uma arquitetura desenvolvida com clientes.
40:41	Como um agente usa a camada de conhecimento	Um exemplo mostra o agente interpretando a intenção, localizando dados, aplicando políticas e registrando rastros de execução para melhorar.
43:13	Neo4j Context Engine	Eifrem apresenta o produto como uma oferta que combina ontologia, execução, memória e governança para acelerar a adoção da arquitetura.
45:17	O modelo em camadas da ontologia	A palestra descreve as camadas de processos de negócio, conceitos, sistemas, capacidades dos agentes e rastros de execução.
47:22	Conclusões: dados e relações para IA confiável	Eifrem conclui que a arquitetura de dados molda o mundo em que os agentes operam e destaca as relações como característica central dos grafos.

Citações

Agora temos agentes que observam esses dados de forma autônoma, avaliam-nos e tomam decisões com base neles. — 07:49

O gargalo é fornecer os dados certos, no momento certo, a esses modelos. — 13:00

Precisamos transmitir aos agentes exatamente três coisas: significado, alcance e aprendizado. — 19:49

Nosso trabalho, como profissionais de dados, é projetar o mundo em que nossos agentes pensam. — 47:52

Conceitos e entidades

Emil Eifrem (pessoa): CEO da Neo4j que apresenta a palestra sobre a camada de conhecimento para IA confiável.
Neo4j (empresa): Empresa de banco de dados em grafo cuja trajetória e produtos são apresentados na palestra.
property graph model (conceito): Modelo de dados que representa entidades como nós, conexões como relacionamentos e atributos como pares chave-valor.
AI context platforms (conceito): Categoria de plataformas citada na palestra para organizar o contexto necessário aos agentes em ambientes empresariais.
ontology (conceito): Especificação formal e explícita dos conceitos de um domínio, usada para dar significado aos dados e conectá-los aos sistemas.
multihop reasoning (conceito): Raciocínio que percorre várias conexões e fontes de dados para reunir informações necessárias a uma resposta.
MCP (ferramenta): Protocolo mencionado na palestra em relação a implementações de memória para agentes.
Neo4j Agent Memory Service (ferramenta): Serviço descrito como uma forma de converter informações em conhecimento e skills atualizadas para agentes.
Neo4j Context Engine (ferramenta): Oferta apresentada como uma implementação pré-empacotada da arquitetura da camada de conhecimento.
Redpoint (empresa): Empresa de capital de risco cujo relatório é citado para descrever etapas de adoção de agentes.
Google Research (empresa): Organização de pesquisa citada por seu trabalho sobre consultas multihop e com múltiplas fontes.
Anthropic (empresa): Empresa citada por discutir as limitações da recuperação de documentos sem encadeamento de fatos.
OpenAI (empresa): Empresa citada por pesquisas sobre responder a perguntas complexas além do alcance da recuperação de passo único.
Oracle (empresa): Sistema de banco de dados usado como exemplo de fonte técnica mapeada por uma ontologia.
Palantir (empresa): Empresa apresentada como uma referência que trabalha com ontologias para conectar dados empresariais a conceitos de negócio.

Tradução completa (pt-BR)

00:00 [aplausos] Bom dia, Londres. É ótimo estar aqui. E nunca foram ditas palavras tão verdadeiras. Eu costumava dizer que tinha o melhor emprego do mundo, mas não posso criar demos em hardware exótico, no modo escuro, como meu amigo Steve Chin faz — e faz tão bem. É fenomenal estar aqui. Começamos na Suécia há cerca de um trilhão de anos. Mas algumas pessoas não sabem que, na verdade, nosso primeiro escritório fora da Suécia foi aqui mesmo.

00:32 em Londres. Ficava no quarto do meu amigo Jim Weber. Ele é nosso cientista-chefe, o funcionário número oito. O quarto dele, em Londres, foi nosso primeiro escritório londrino. E, avançando para hoje, temos várias centenas de pessoas aqui no nosso escritório de Londres, perto da London Bridge. Na verdade, é nosso único escritório que eu chamaria de multifuncional. Temos uma grande equipe de engenharia desenvolvendo muitas das partes fundamentais do produto, mas também temos equipes de go to market e GNA, então é como

01:02 um escritório de ponta a ponta. Londres sempre foi um lugar muito importante para nós. Por isso, é sempre ótimo estar aqui. Começamos há quase 20 anos. Eu era CTO em uma pequena startup na Suécia, e estávamos desenvolvendo o que hoje chamaríamos de gerenciamento de conteúdo corporativo — conteúdo, não contexto. Vamos falar bastante de contexto mais tarde hoje, mas era gerenciamento de conteúdo corporativo. Processávamos arquivos de mídia grandes, ou pelo menos o que na época parecia

01:34 ser arquivos de mídia grandes. Imaginem um monte de fotos, PDFs e coisas assim. Nosso trabalho era desenvolver o que hoje chamaríamos de uma aplicação SaaS multi-tenant para ajudar nossos clientes a entender todos esses dados. Imaginem um grande sistema de arquivos. Vocês enviam suas informações e, então, precisamos armazená-las no backend de alguma forma. Tínhamos uma equipe de engenharia de cerca de 20 pessoas e um problema enorme com nossos dados. E acabou que metade da

02:04 equipe, cerca de 10 pessoas, passava a maior parte do tempo simplesmente brigando com o banco de dados. Isso me surpreendeu muito, porque em todos os meus projetos anteriores o banco de dados tinha sido um grande acelerador. Ele tirava da nossa frente esse problema enorme e cabeludo: pegar os dados, garantir que fossem armazenados em disco, torná-los consultáveis por vários usuários, garantir que, se algo falhasse, tudo permanecesse consistente, fazer backups online enquanto o sistema estivesse em execução — todas essas

02:35 coisas enormes, cabeludas e complicadas saíam da nossa mesa — sem trocadilho — e podíamos nos concentrar em desenvolver a aplicação. Mas havia algo diferente nesse projeto. Acho que hoje, 20 anos depois, como setor, temos uma compreensão clara e uma linguagem para explicar o que estava acontecendo. Mas levamos muito tempo para descobrir. A causa raiz era que havia uma incompatibilidade entre nossos dados e a forma desses dados, de um lado, e as abstrações fundamentais expostas pela nossa estrutura de dados e infraestrutura de dados centrais, do outro.

03:06 E, assim, tínhamos dados enormes, confusos, conectados e complexos, enquanto as abstrações se pareciam com isto: linhas e colunas em um banco de dados relacional. O banco de dados relacional é uma peça incrível tanto da ciência da computação quanto da engenharia. Às vezes, as pessoas querem fazer parecer que, por eu representar outro tipo de banco de dados, odeio o banco de dados relacional e coisas assim. Na verdade, acho que é um software fantástico. Só que ele não é bom para tudo. E tínhamos esse

03:38 problema: havia uma incompatibilidade entre os dados que tínhamos e essa abstração fundamental. Esbarramos no problema e, por um tempo, batemos a cabeça contra a proverbial parede relacional, até que, no fundo, dissemos: “Quer saber? Deve haver um jeito melhor de fazer isso.” E, como éramos jovens e ingênuos, primeiro olhamos em volta e tentamos encontrar outras maneiras de fazer isso. Certamente outras pessoas já tinham se deparado com esse problema. Mas, depois de um tempo, jovens e ingênuos, dissemos: “Dane-se, vamos construir do zero. O que poderia dar errado?”

04:11 E aqui estou eu, 20 anos depois, e ainda estamos trabalhando na construção desse banco de dados. O que acabamos concluindo foi que muitos dos problemas que encontramos podiam ser abstraídos como conceitos ou entidades conectados a outros conceitos ou entidades, ou anéis conectados a outros anéis por pontos — desculpem, por linhas, certo? Ou pontos conectados a outros pontos por linhas. Em outras palavras, nós conectados a outros

04:43 nós por relacionamentos. E, se tivéssemos essas duas abstrações fundamentais — nós e relacionamentos — mais uma terceira, pares de chave-valor que você pode anexar tanto aos nós quanto aos relacionamentos, caramba, poderíamos modelar tudo. Isso acabou sendo comprovado. Provavelmente, três ou quatro décadas atrás, isso foi comprovado com o modelo relacional. É possível pegar qualquer dado e modelá-lo no modelo relacional. O modelo de grafo de propriedades, como passou a ser chamado, é isomórfico ao modelo relacional. Portanto, é possível modelar tudo — qualquer dado — com essas abstrações. Mas isso vale para qualquer tipo de banco de dados. Vale para bancos de dados de documentos, armazenamentos de chave-valor e bancos de dados relacionais, pelo menos os mais populares. Então, a pergunta interessante já não é se você consegue modelar seus dados. A pergunta interessante é se esse modelo é adequado. Descobriu-se que essa forma de representar dados era ótima para muitos casos de uso importantes. Avançando para hoje,

05:13 e vemos que todas as 20 maiores instituições bancárias — pelo menos na América do Norte — são agora clientes e usuárias dessa tecnologia. Todas as 10 maiores montadoras do mundo, todas as 10 maiores empresas farmacêuticas. Algumas pessoas levantaram a mão quando Steve perguntou se estavam aqui há um ano. Quem estava aqui há um ano e prestou atenção vai se lembrar de que dizia nove em cada 10. Então, avançamos desde nosso último encontro. E assim por diante. Oito das 10 maiores

05:47 empresas varejistas, seguradoras e assim por diante. Quase todas as empresas da Fortune 50, e mais de 85 das empresas da Fortune 100, usam o Neo4j em produção. Portanto, tivemos um enorme sucesso. Tudo isso se baseia naquela intuição que tivemos e que articulamos como a declaração de missão da empresa: queremos ajudar o mundo a entender os dados. Dissemos isso antes da IA; já achávamos que era valioso naquela época. Caramba,

06:17 como isso está se tornando cada vez mais valioso a cada dia. Falando em dados e em IA, levei, sei lá, quatro ou cinco minutos no palco como CEO de tecnologia em 2026 antes de dizer a palavra IA. Acho que isso pode ser um recorde. Mas, tendo passado toda a minha carreira focado em dados, vi a maior mudança nos dados acontecer nos últimos 12 meses. E todos sabemos que a IA é o grande

06:48 motor disso. Mas, para ser um pouco mais específico, a grande ruptura é que, durante décadas, havia apenas dois tipos de consumidores de dados. Se você tinha dados em um sistema de arquivos ou em disco, havia dois tipos de consumidores desses dados. O primeiro é uma aplicação. Muitos de vocês aqui são desenvolvedores ou já foram desenvolvedores, certo? Então, vocês escrevem uma aplicação que busca os dados no banco de dados. Esse é o usuário. O segundo tipo de usuário é algum tipo de ser humano,

07:18 normalmente um analista. Pode haver algum dashboard de BI, planilhas ou relatórios envolvidos, mas, no fim das contas, o consumidor desses dados é um usuário humano. E, nos últimos 12 meses, uma terceira categoria entrou em cena: claro, os agents. Agora temos agents que analisam esses dados de forma autônoma, avaliam esses dados e tomam decisões com base neles. E, caramba, isso muda tudo.

07:49 normalmente um analista, e talvez haja um painel de BI, talvez algumas planilhas envolvidas, talvez alguns relatórios envolvidos, mas, no fim das contas, um usuário humano é o consumidor desses dados. E, nos últimos 12 meses, uma terceira categoria surgiu: os agents. Agora temos agents que analisam esses dados de forma autônoma, avaliam esses dados e tomam decisões com base neles. E, caramba, isso muda tudo.

08:22 Mais especificamente, vamos falar de um exemplo disso da perspectiva de uma grande organização, certo? Digamos que estamos numa jornada para identificar nossa grande organização. Talvez eu use um exemplo de serviços financeiros, já que estamos aqui em Londres. Vi as estatísticas: há muitas pessoas de serviços financeiros representadas aqui na sala hoje. Então, digamos que estamos identificando nossa experiência e temos um agent recebendo uma ligação de um cliente. Nesta situação específica, o cliente quer… ele tem um empréstimo

08:53 conosco e quer refinanciá-lo porque um concorrente apareceu com uma oferta melhor, certo? E é um cliente importante, com vários produtos que temos e muitos relacionamentos com diferentes partes do banco. Temos algum tipo de janela, vamos chamar assim; neste caso, dissemos que são 30 segundos para tomar uma decisão. Devemos igualar essa oferta? Devemos superá-la com uma oferta melhor ou simplesmente deixar o cliente ir embora? Então, vamos analisar esse cenário. Certo? Em última instância, precisamos descobrir qual produto posso

09:24 oferecer a esse cliente e a que preço. Então, o que preciso saber se sou o agent tentando resolver isso? Quais são alguns dos dados necessários? Primeiro, preciso entender quem está ligando, certo? E isso é bem fácil, na verdade, porque a pessoa se identificou de alguma forma ao falar com o agent, e tenho acesso a uma quantidade enorme de dados. Por quê? Porque sou um grande banco, certo? Então, quem está ligando? Vamos ver alguns dos dados neste exemplo. No call center aqui, esse cliente se

09:54 identificou como Charlie Dolan, e provavelmente foi isso que disse ao falar ao telefone com o agent: Charlie Dolan. E então tem um empréstimo conosco. Há um sistema de registro de originação. Em um grande banco, originação é todo o trabalho feito antes de aprovar o empréstimo, como KYC e coisas desse tipo, certo? E ali consta que o passaporte foi verificado em nome de Charles Dolan. Depois, no atendimento do empréstimo, que acontece quando o empréstimo é aprovado e envolve todos os pagamentos e coisas desse tipo,

10:24 consta C Dolan, o que obviamente é ridículo — hipotético, já que a originação do empréstimo dizia Charles Dolan e, claro, a transferência para cá jamais terminaria como C Dolan. [fungada] Exceto que toda pessoa aqui que já trabalhou numa grande empresa já viu exatamente isso acontecer muitas e muitas vezes. Então, temos a mesma pessoa identificada por três nomes diferentes. Isso se chama entidades não resolvidas. É um exemplo do tipo de problema que pode ocorrer no mundo

10:55 real em uma grande organização. Certo. Essa é a primeira pergunta que queremos responder: quem está ligando? Certo. A segunda pergunta que estamos tentando resolver é: devemos igualar ou superar a oferta, ou deixar o cliente ir embora? Quanto essa pessoa ganha? Então, procuramos isso nos dados, e essa informação está distribuída por vários sistemas de registro. Temos algum tipo de sistema de hipotecas. Temos um sistema de cartões de crédito. E temos um sistema de gestão de patrimônio. E eles têm números diferentes. Olhamos para isso e nos perguntamos por que têm números diferentes. Bem, o

11:25 sistema de hipotecas remonta à época em que ele solicitou o empréstimo. E consta que sua renda era de US$ 145.000. No sistema de cartão de crédito, o dado é autodeclarado. E, depois, há um KYC na divisão de gestão de patrimônio que foi verificado no mês passado. Então, estamos olhando para isso, e os dados são, na verdade, de épocas diferentes, sem os metadados associados que indiquem quando foram alterados pela última vez. Tenho certeza de que há algum registro de auditoria em algum lugar. Certamente não está disponível para o agent conseguir descobrir. Então, esse é o

11:57 terceiro tipo de… desculpe, o segundo tipo de problema: dados desatualizados, certo? Dados precisos, mas referentes a um momento errado. E o último é que precisamos de algum tipo de categoria para os clientes, certo? E a categoria a que pertencem é um fator importante para o agent tomar uma decisão. Aqui temos informações diferentes. No banco de varejo, consta que é da categoria padrão. No sistema de cartões de crédito, consta que é da categoria prata e, no de gestão de patrimônio, consta ouro. Então, tudo isso está correto, só que de perspectivas diferentes. Neste caso, temos

12:28 dados conflitantes, sem uma hierarquia de prioridade estabelecida que determine qual é a fonte única da verdade para essa dimensão específica do cliente. Então, aqui estão três tipos de problemas de dados — uma lista não exaustiva — com que esse agent se depara no mundo real, em uma grande empresa. Certo. O que está surgindo é uma visão que percebo hoje entre nossa base de clientes e que

13:00 é que, pelo menos dentro de grandes organizações, a IA já não é limitada pela inteligência dos modelos, certo? Temos uma inteligência de nível absolutamente ficção científica presa numa caixinha, à nossa disposição sempre que quisermos. É fenomenal o que esses novos modelos de IA conseguem fazer. Sim, eles são irregulares. Não são perfeitos em todas as dimensões. Têm uma inteligência irregular, mas, caramba, são incríveis. Esse não é o

13:31 gargalo. O gargalo é fornecer os dados certos, na hora certa, a esses modelos. O que as pessoas acabam chamando de contexto. E algo realmente fascinante que aconteceu com o setor nos últimos, digamos, 12 a 18 meses — talvez mais como 9 a 12 meses — é que sinto que todos estão convergindo para exatamente o mesmo problema. Pelo menos quando penso em como o enquadro para fazer a IA funcionar dentro da empresa, dentro de uma

14:02 grande organização: é exatamente o mesmo problema. É alguma versão de: tenho M agents atuando em N fontes de dados heterogêneas, dispersas e desorganizadas, e preciso dar sentido a isso, certo? M agents em N fontes de dados. Como faço para que atuem de forma confiável em escala? A Gartner trabalhou bastante nisso e cunhou pelo menos um

14:34 nome inicial para a solução desse problema: plataformas de contexto de IA. Plataformas de contexto de IA. É um ótimo relatório. Um dos autores está aqui em algum lugar. Oi, Aros, desse relatório. É realmente um ótimo relatório. E acho que até no relatório vocês dizem que talvez esse nome não pegue, mas o problema é muito, muito real. E quero, como aparte sobre o nome, dizer que contexto é uma palavra que ouvimos bastante

15:06 na IA hoje, e, na verdade, temos uma longa história falando sobre contexto. Acontece que, no nosso evento aqui em Londres — não nesta sala —, há quase 10 anos, uma versão mais jovem, um pouco mais jovem, de mim deu uma palestra que abriu uma versão equivalente desta palestra na edição maior desta conferência. Graph Summit é a turnê pelas cidades. Naquela época, nós

15:37 fazíamos o Graph Connect, uma conferência anual que realizávamos duas vezes por ano. Vai entender. Esta edição foi aqui. Chamamos de Graph Connect Europe, embora fosse em 2017, um ano depois do Brexit, porque ainda éramos ingênuos quanto a isso. E minha parte favorita daquela palestra de abertura foi: “Vamos olhar 10 anos adiante”. Tipo: “Certo, para onde está indo o mundo dos grafos?” Ela ainda está no YouTube. Então, vocês podem me cobrar, podem me responsabilizar pelo que falei, assistindo àquilo e

16:09 vendo se faz sentido. Mas falei sobre o futuro dos grafos e disse que um dos principais fatores que impulsionariam a adoção de grafos nos 10 anos seguintes seria a IA. Usei os termos deep learning e machine learning, em vez de IA. E por quê? Porque o contexto proporciona significado e precisão aos sistemas de machine learning. E continuei falando sobre o que contexto realmente é. Este é um exemplo do meu contexto, certo? Este era o meu contexto em 2017. Sou

16:40 pai de duas crianças, e esta foto foi tirada poucas semanas depois de minha filha nascer. Então, lembro que tinha uma pequena animação com um carrinho de bebê entrando pela esquerda. Agora tenho três filhos. Trabalho na Neo4j. Este é nosso logotipo antigo. Sou casado com Meline. Toco piano de vez em quando. Vejo uma TV que parece ser dos anos 50. Não sei bem o que está acontecendo ali. Nasci na Suécia. Diz que dirijo um Tesla. Isso é notícia falsa; dirijo um Volvo, porque sou sueco. Então, se vocês

17:11 Pensem no que aconteceu bem ali: em cerca de 10 segundos, dei a vocês uma compreensão muito mais rica de quem eu sou. Isso acrescentou muito mais cor à minha individualidade. E tudo depende de como me conecto a outros conceitos do mundo. Contexto é como um objeto se relaciona com todo o resto do mundo: as relações. Então, já vemos isso há muito tempo, mas, nossa,

17:43 o mundo alcançou essa ideia. Em apenas três meses, entre abril e junho, todo mundo — todas as principais plataformas de dados e de nuvem — lançou um produto para resolver exatamente esse problema, usando exatamente grafos e ontologias. Alguns exemplos. Este é o Databricks lançando o Genieontology em junho deste ano, incorporando uma visão ontológica de sua plataforma de dados. O Snowflake fez algo parecido com o Cortex cerca de um mês

18:14 antes. A Palantir, é claro, foi fundada como uma empresa de ontologia desde o primeiro dia. Eles são até um pouco mais antigos do que nós e foram fundados com base na ontologia como um dos principais — se não o principal — ingredientes secretos para dar sentido aos dados e às plataformas de nuvem também. Então, o Microsoft Fabric ficou disponível em geral em junho, com o Fabric Graph e o Fabric IQ. O Google lançou seu catálogo de conhecimento baseado em

18:46 grafos. E a AWS tem o AWS Context, que é um grafo de conhecimento sobre todo o conjunto de dados deles. Então, todos estão chegando de forma independente à conclusão de que, para resolver o problema de M agents em meio a N fontes de dados desorganizadas, devemos usar grafos e ontologias. Isso é uma ótima notícia, porque, depois de passar os últimos 12 a 18 meses realmente imerso especificamente nesse problema,

19:19 com os agents usando dados como motivação, temos uma visão extremamente clara de como fazer isso. Como vocês sabem, trabalhamos com grafos há mais de 20 anos. Temos IA em produção há mais de uma década e, especificamente, modelos de IA baseados em transformers — chamem isso de IA moderna — em produção há cerca de dois anos. E o que está surgindo é uma

19:49 compreensão muito, muito clara de exatamente como resolver esse problema. Preciso que meus agents atuem de forma confiável, em escala, em todo o meu cenário de dados, com fontes de dados dispersas. E, para resolver esse problema, há exatamente três coisas que precisamos transmitir aos nossos agents. Nem mais, nem menos. Exatamente três coisas. A primeira é transmitir o significado dos dados. A segunda é dar aos nossos agents acesso a todo o ecossistema de dados da empresa, de uma forma que respeite a segurança e as políticas. E

20:23 precisamos que o sistema aprenda sozinho, para que amanhã acorde mais inteligente do que hoje. Significado, acesso e aprendizado. Então, vamos examinar cada um deles em detalhes. Começando pelo significado: do que estamos falando? Digamos que temos esta aplicação. Ela usa dados deste banco de dados. Neste exemplo, vou usar algo simples, como um formulário de pedido ou um registro de pedidos, eu acho, certo? Em que temos algum ID do pedido, o status do

20:54 pedido e um valor por pedido, algo assim. O status deste pedido específico aqui é 2. O que o status 2 significa, conforme mostrado em azul, está codificado em código imperativo, em Java, neste caso, nesta aplicação. Se o status for igual a 2, faça estas coisas: retenha o pedido e notifique a equipe de análise, ou algo assim. É isso que 2 significa. Esse significado está codificado no software da

21:25 aplicação. Certo. Os mesmos dados são consumidos por um segundo tipo de consumidor: o analista humano. Na cabeça dele, 2 significa suspenso, aguardando análise, e isso pode estar em um post-it. Pode estar em algum Google Doc. Pode estar codificado em algum painel de BI do Tableau, mas, no fim das contas, está fora da cabeça do analista humano. Para o agent, ele vai olhar para esses dados e não vai ter a menor

21:56 ideia do que 2 significa. [limpa a garganta] E agora, como setor, chegamos a um consenso: como resolver esse problema do significado? Todos dizem que as ontologias vêm ao resgate. Passei 20 anos da minha vida no universo dos grafos tentando evitar essa palavra, porque ela simplesmente transmite uma ideia de complexidade. Agora, de repente, todo mundo está falando de ontologias. E acho que isso acontece por causa da IA, mas, sinceramente, também porque

22:27 a Palantir tornou o termo aceitável, de certa forma. Ainda há muita gente que tem opiniões sobre ontologias. Por exemplo, que é preciso ter mais de 40 anos para sequer discutir ontologias. E eu entendo, certo? Porque, na verdade, se vocês pensarem na palavra ontologia, ela remonta aos antigos gregos. Aristóteles, em Metafísica 4, fala sobre a estrutura da própria realidade, certo?

22:57 Lá atrás, em uma época um pouco mais moderna — que ainda parece ter sido há bastante tempo —, Tom Gruber, de Stanford, apresentou em 1993 uma ótima definição do que é uma ontologia para a ciência da computação. É uma especificação explícita de uma conceitualização. Gosto muito dessa definição, mas ela é uma daquelas coisas em que, se você já sabe o que é uma ontologia, pensa: “Sim, é exatamente isso”. Mas, se não sabe o que é, ela não ajuda em nada. Certo?

23:29 E a Palantir tem várias maneiras de falar sobre ontologia. Esta é uma delas: um gêmeo digital que conecta os dados brutos de uma organização aos conceitos de negócio do mundo real. Gosto desta definição. Esta é de uma Graph Connect em Nova York, em 2018, onde o Dr. Jesus Barasa fez uma palestra sobre como armazenar ontologias no Neo4j. Jesus, você está

23:59 por aqui? Está ali. Jesus é PhD em representação do conhecimento em IA. Passou sete anos na empresa de ontologia. Depois, uma década na Neo4j. Muitos de vocês trabalharam com ele ou com a equipe dele, que lidera uma grande parte da nossa organização de arquitetos de soluções. E, nos últimos um ou dois anos, ele tem sido nosso CTO de campo para IA. Então, ele tem uma equipe dedicada que trabalha com algumas das empresas mais avançadas

24:29 do mundo para colocar grafos e IA em produção. Não há ninguém no planeta que saiba mais sobre como colocar grafos e IA em produção. Então, depois desta palestra, não venham atrás de mim; vão atrás daquele cara. E dá para ver como ele é confiável, porque claramente tinha menos de 40 anos na época, certo? E ainda assim discutia ontologias. Hoje em dia, porém… [risos] Ele fala de ontologias assim: é um modelo de domínio — não compliquem demais —, uma conceitualização de uma

25:00 especificação. Não: um modelo de domínio. Mas ele precisa ter três características. Precisa ser formal, para que seja legível por máquina; precisa ser explícito, ou seja, não pode ser prosa em algum Google Doc; e a ideia é que seja compartilhado, talvez entre aplicações, talvez entre equipes. É por isso que gosto muito dessa definição. Outra definição é: os substantivos e verbos da sua empresa. O que está acontecendo de fato? Quem são seus clientes? O que eles fazem? O que eles têm? Certo? E a forma como eu realmente penso nisso é

25:30 muito simples. É o sistema de tipos dos seus dados. No fim das contas, minha formação é como engenheiro de software, certo? Os dados são as instâncias, e a ontologia são as classes, os tipos, certo? O sistema de tipos. Certo. Este é um exemplo real de uma ontologia. Vou falar um pouco mais sobre de onde isso vem: não há apenas um exemplo de ontologia, mas várias ontologias para uma determinada

26:00 aplicação ou empresa. Mas este é um ótimo exemplo de como as pessoas que adoram ontologias costumam errar: começam com uma complexidade esmagadora. Na verdade, quando vocês começam, em escala empresarial, para grandes organizações, só precisam de duas. Uma ontologia voltada ao domínio, voltada ao negócio, e uma ontologia técnica. A primeira descreve seus clientes,

26:33 suas contas bancárias, suas transações, seus cartões de crédito, seus planos de seguro, seja lá o que for que sua empresa faz, aquilo sobre o que seus colegas falam quando falam da empresa. Acontece que os agents, por assim dizer, “pensam” na linguagem da sua empresa. É assim que se codifica isso na ontologia de domínio voltada ao negócio. Essa é a primeira. A segunda, muito importante, é a ontologia técnica. Essa é uma

27:03 corresponder ao estado dos seus dados. Isso diz que, naquele endereço IP, há uma instância do Oracle. Dentro dela, há um esquema com uma tabela de clientes, e essa tabela de clientes tem uma coluna chamada F_name, certo? E, muito importante, você tem o mapeamento entre as duas coisas. De repente, quando seus agents querem o primeiro nome de um cliente, eles sabem que os clientes têm um primeiro nome por meio da ontologia voltada para o cliente

27:34 e então têm o mapeamento até aquela coluna F_name específica naquele banco de dados Oracle específico. Essas são as duas ontologias fundamentais de que você precisa para começar a trabalhar com agents em IA. Certo, essa é a primeira. A segunda é o alcance. Esta é absolutamente fundamental, realmente muito, muito importante. E, quando converso com pessoas, com outras plataformas de dados e com analistas, essa é a que a maioria não percebe. Elas não entendem o quanto isso é absolutamente crucial

28:07 para fazer os agents funcionarem. Então, pensem nisso sob a perspectiva de para onde estamos indo no universo, certo? Este é um ótimo relatório de uma empresa de venture capital do Vale do Silício chamada Redpoint, publicado no início deste ano, que fala sobre onde estamos em termos de adoção de agents. Está um pouco desatualizado, porque tem uns seis, sete meses, e vocês sabem como esse universo muda rápido, mas ainda continua muito, muito válido. E o que dizem é que, em 2025 e antes, estávamos na era do chat e dos copilots, e o tempo de execução independente de um agent era de

28:38 segundos, certo? E, em geral, conversávamos com nossos agents. Onde estamos em 2026 é no universo dos agents de tarefas. Portanto, o tempo de execução independente agora costuma ser de minutos, e eles assumem aspectos táticos relativamente específicos do nosso negócio, que ainda podem ser extremamente valiosos. Aliás, o que vimos internamente na Neo4j é que, ao longo de 2026, fizemos uma

29:09 pequena mudança nos agents de tarefas. No começo do ano, a maioria dos nossos clientes usava agents de tarefas com humanos no loop. Por exemplo, eles podiam redigir uma mensagem, mas ainda era o ser humano que clicava em enviar e a mandava para os clientes. Foi assim que começamos 2026. Agora, muitos dos nossos clientes estão tornando esses agents completamente autônomos. Ainda dentro de escopos relativamente específicos, mas completamente autônomos.

29:39 O próximo passo são os agents de workflow de ponta a ponta. Isso significa assumir uma função empresarial inteira, orquestrando esse processo de várias etapas de ponta a ponta, com um tempo de execução de horas; depois, por fim, vamos avançar para dias, chegando ao que chamam de agents autônomos. Esse é mais ou menos o ponto em que estamos e o que acabará acontecendo à medida que passarmos dos agents de tarefas para os agents de workflow de ponta a ponta. Vamos precisar conseguir ir muito mais fundo. Nossos

30:10 agents precisarão conseguir ir muito mais fundo em todo o nosso patrimônio de dados. Então, vamos falar disso com um exemplo. Digamos, mais uma vez, que somos uma grande instituição de serviços financeiros. Oferecemos hipotecas. Temos muitos clientes e queremos enviar mensagens oferecendo um refinanciamento aos nossos clientes, algum tipo de oferta de venda adicional. Pode ser por mensagem de texto, por e-mail e, com o tempo, talvez até por um agent de voz. Mas, por enquanto, vamos nos concentrar nas mensagens de texto. Se vocês pensarem em

30:40 como resolver esse problema para esse agent, o que é preciso fazer? Primeiro, é preciso encontrar o cliente, certo? Certo. Este é um cliente específico para quem queremos redigir uma oferta de venda adicional de refinanciamento, e precisamos consultar os dados dele. Esse cliente tem uma casa e, na verdade, tem duas hipotecas com um banco. É importante sabermos disso, obviamente, se vamos enviar a ele algum tipo de mensagem sobre refinanciamento. Mas não é só isso: também precisamos de todas as comunicações anteriores, que

31:13 temos em três modalidades. Temos e-mails, mensagens de texto, mensagens SMS e transcrições de chamadas, certo? Todas essas três são cadeias profundas pelas quais precisamos navegar. Então, para redigir essa oferta de venda adicional de financiamento, precisamos percorrer todo esse patrimônio de dados, que tem, sei lá, 5, 10, 20 saltos de profundidade ou algo assim. E, idealmente, queremos conseguir fazer isso em tempo real. Mas, é claro, no mundo real, que é uma bagunça, esse

31:44 cliente tem um cônjuge e outra casa que é de propriedade conjunta, e esse cônjuge tem exatamente a mesma situação. Outro empréstimo, com um banco diferente, além de transcrições de chamadas e comunicações com essa pessoa. É preciso levar tudo isso em consideração quando o agent redige a oferta perfeita de refinanciamento com venda adicional. Depois, você pega essa estrutura de dados e vê onde ela poderia estar armazenada na sua empresa; raramente está toda no

32:16 mesmo sistema. Ela fica espalhada por vários silos. E imaginem se todos eles fossem bancos de dados relacionais, como ainda acontece, certo? Mesmo que um deles seja um banco de dados de grafos, isso é muito, muito difícil, porque aqui não estamos falando de 5, 10, 20 saltos. Provavelmente são uns 100 saltos de profundidade ou algo assim. E queremos conseguir fazer isso em tempo quase real, para fazer isso em escala com muitos clientes. Esse nível de alcance é muito, muito

32:47 importante para que um agent consiga ter. Isso se chama raciocínio multissalto. E, embora eu tenha acabado de dizer que poucas pessoas no mundo dos dados estão falando disso, os laboratórios já entenderam. Eles falam sobre isso. O Google Research afirmou que os sistemas atuais de RAG de etapa única não foram projetados para as consultas multissalto e de múltiplas fontes dos workflows empresariais modernos. Isso foi o Google Research, em junho de 2026, há alguns meses. A mesma ideia aparece na Anthropic, que diz

33:20 que você tem um conjunto de documentos não estruturados e nenhum documento contém a resposta completa. A recuperação RAG, ou geração aumentada por recuperação — RAG. Isso significa RAG apenas vetorial. O que o Steve mostrou à esquerda, na demonstração dele, não vai encadear os fatos para você. Você precisa de um grafo de conhecimento; isso é da Anthropic. E então a OpenAI disse, quase um ano atrás: “Certo, esse método permite responder a perguntas complexas e multifacetadas, além do que a recuperação de salto único consegue

33:50 fazer. Na verdade, aqui na sua região, foi publicado muito recentemente um ótimo relatório de pesquisa. Vocês podem vê-lo aqui. National Innovation Center, com “RE”, não “ER”. Está aqui em algum lugar. Ele traz benchmarks muito bons, cientificamente robustos e reproduzíveis, mostrando como a precisão aumenta muito quando se adiciona um grafo de conhecimento ao caminho de recuperação dos seus

34:21 agents. Esse é o segundo pilar, então: alcance. Agora, vamos ao terceiro pilar: aprendizado. Talvez este seja o mais intuitivo. Acho que todos sentimos, intuitivamente, que os agents precisam melhorar com o tempo, mas é importante lembrar que isso precisa se aplicar aos dois pilares. Precisa se aplicar ao nível do esquema ou dos tipos, ao nível ontológico, e ao nível das instâncias. E por quê? Bem, primeiro, o

34:53 panorama empresarial está sempre mudando em termos dos seus dados, certo? Por quê? Porque o mundo está sempre mudando. Então, seus agents precisariam aprender mesmo que fizessem exatamente a mesma coisa, porque tudo está mudando. Mas, é claro, uma grande parte de atingir a velocidade de escape com IA é esse loop de RL, o loop de aprendizado por reforço, em que seus agents acordam amanhã mais inteligentes do que eram hoje. Fizemos muito trabalho nisso na Neo4j. Acontece que a memória é

35:27 uma estrutura de dados intrinsecamente moldada como um grafo. Tenho certeza de que todos aqui sabem o que é MCP. Quando faço a pergunta desse jeito, ninguém se atreve a não levantar a mão. [risos] O protocolo de contexto de modelo, na verdade, já vem na primeira versão do MCP com uma implementação minúscula de memória em memória — é difícil dizer isso —, uma implementação minúscula de memória em memória. Ou seja, uma implementação de memória agentic na RAM, que é só um brinquedo. São 300 linhas de Python. Mas

35:59 Na verdade, é um grafo, e há muitas startups construindo memória agentic sobre o Neo4j. Então, muitas pessoas estão concluindo por conta própria, sem nem falar comigo, que a memória é uma estrutura de dados em forma de grafo. Em linhas gerais, penso principalmente em três tipos de memória. Há a memória de curto prazo, que é a conversa principal e o que está acontecendo ao vivo neste momento, ou no curto prazo, com seu agent. Há a memória de longo prazo

36:31 e, depois, há os rastros de execução do agent, ou a memória de raciocínio. E a coisa mais importante que vejo as pessoas fazerem errado com agents é que elas acabam armazenando a memória, mas não têm um sistema de ciclo fechado que lhes permita agir com base nela. No serviço da NAM — o serviço de memória de agent da Neo4j —, vou mostrar um link daqui a pouco. Estamos codificando isso em todo o software. Então, você começa com suas

37:02 informações brutas e as transforma em conhecimento, identificando os nós e conceitos; mas, muito importante, depois você expressa isso em uma skill, que é representada no grafo, e pode materializá-la como um arquivo Markdown de skills normal para seus agents consumirem. Quando as informações brutas mudam aqui, sua base de conhecimento é atualizada, o que invalida as skills.mmd existentes, que são geradas novamente para que seu

37:33 agent aja imediatamente com base no novo conhecimento que o sistema aprendeu. Há um QR code ali embaixo. É uma ótima postagem de blog que explica como isso funciona na prática com um sistema de memória de agent da Neo4j, o NAS. Certo, falamos sobre esse problema muito valioso: preciso que minha stack de agents funcione de forma confiável, em escala, em meio ao meu ambiente desorganizado de dados, e sobre os três pilares necessários para chegar lá. O primeiro

38:04 — significado — resolvemos com ontologias; alcance, com recuperação multihop ou raciocínio multihop; e aprendizado, com memória de autoaprendizado. E a ótima notícia é que, no último ano, ano e meio — nos últimos 12 a 18 meses —, dedicamos muito tempo a isso junto com muitos clientes, alguns pequenos, outros grandes, alguns aqui nesta sala, na verdade, incluindo grandes bancos, uma enorme plataforma global de tecnologia da Costa Oeste dos EUA e uma empresa líder de tecnologia imobiliária, para nos concentrarmos de verdade em resolver esse problema específico. E o que está surgindo é esse blueprint que chamamos de arquitetura da camada de conhecimento. Então, sem surpresa, a arquitetura da camada de conhecimento tem três pilares. O primeiro pilar é o da ontologia. Aqui você pode ver o modelo de domínio, o modelo de domínio voltado para os negócios. Você pode ver a ontologia técnica, que são os metadados dos sistemas que indicam exatamente onde seus

38:35 dados estão, e também suas regras e ações de negócio. O segundo é o alcance. É a capacidade de aprofundar e percorrer seus dados. Há variações disso. Você verá alguns exemplos mais adiante na sessão do produto. E então, claro, há a memória: memória de longo prazo, de curto prazo e procedural; e também a memória de raciocínio, ou o grafo de contexto. Essa é a arquitetura da camada de conhecimento. E há, na verdade, várias configurações possíveis. Uma

39:06 delas é o que chamamos de camada semântica baseada em ontologia. É uma maneira muito fácil de começar. Camadas semânticas são outro daqueles termos muito, muito sobrecarregados no mundo da IA: algumas pessoas falam de camadas semânticas centradas em BI, que são muito centradas em métricas; outras vêm do mundo RDF, e assim por diante. Esta é uma camada semântica baseada em ontologia e uma configuração dessa arquitetura em que você usa todos os pilares da ontologia, junto com alguns dados de referência. Por exemplo, a ontologia

39:38 pode descrever todas as regiões geográficas em que você atua, mas os dados de referência podem ser, digamos: se tivermos uma lista suspensa com todas as cidades, como a preenchemos previamente? Esse é um exemplo. E há uma configuração em que você começa com a camada semântica baseada em ontologia e acrescenta memória a ela. Sobre essa configuração específica, fiz uma palestra na AI Engineer World’s Fair em junho. É uma palestra bem curta, de 9 minutos. Se você quiser uma visão geral bem breve do que estou falando aqui, para enviar ao seu

40:10 chefe, por exemplo, acho que essa é uma boa explicação. E você também pode começar com a ontologia mais os dados. Portanto, há várias maneiras e formas de configurar essa arquitetura. Mas como isso se parece na prática? Digamos que você tenha implementado isso e tenha um agent em execução. Vamos analisar. De forma bem pragmática, um fluxograma. Digamos que temos um agent que quer

40:41 responder a uma pergunta parecida com uma que fizemos antes: qual é nossa exposição a este cliente? O primeiro passo é o agent interpretar a intenção, e, para isso, ele recorre à ontologia de domínio voltada para os negócios: o que é um cliente, afinal? O que queremos dizer com exposição? Esse tipo de pergunta. Depois, ele precisa montar o contexto. Então, consulta a ontologia técnica. É como se dissesse: “Certo, entendi os conceitos. Agora, onde eles estão no meu ambiente de dados?” E, muito importante,

41:11 em qualquer grande organização, é preciso aplicar uma política, certo? Então: quem sou eu e a que tenho permissão para acessar? Quais são minhas autorizações? Depois disso, ele já montou as partes principais do contexto e precisa descobrir como obter os dados. Há duas maneiras de fazer isso com uma camada de conhecimento. Uma é consultar em profundidade, certo? A ontologia técnica apontou para aquele banco de dados Oracle. Então, você faz uma consulta aprofundada nesse banco de dados Oracle para obter os dados. A outra maneira é

41:41 que eles já estejam pré-materializados no grafo. Assim, você pode fazer a travessia aprofundada imediatamente. Essas são as duas maneiras. Depois que terminar, você deixa o agent esgotar e registra todos os rastros de execução gerados durante a execução, para poder aplicar RL a eles e aprimorar continuamente tanto a ontologia quanto os dados de instâncias principais. Esse é o fluxo completo de como um agent pode usar uma camada de conhecimento na

42:12 prática. Como mencionei, no último ano, mais ou menos, desenvolvemos essa arquitetura com clientes, e o que aprendemos é que ela é extremamente poderosa. São essas três coisas de que um agent precisa para funcionar na realidade, no mundo desorganizado das grandes organizações. Mas isso também leva um tempo. É algo que você precisa construir do zero sobre a plataforma de inteligência de grafos que passamos 20 anos

42:42 construindo. Então, percebemos: não seria ótimo se pudéssemos pegar isso, empacotar previamente e oferecer uma solução que não chegasse a 100%, porque cada grande organização é única, mas que talvez chegasse a 80% ou até 90%? E é por isso que chamamos isso de context engine: o Neo4j Context Engine. O que ele faz é reunir toda essa arquitetura e todos os aprendizados que

43:13 tivemos ao longo do último ano, ano e meio — mas, na verdade, dos últimos 20 anos trabalhando com grafos e 10 anos trabalhando com grafos em IA — e colocar tudo em um único produto que fica sobre a plataforma de inteligência de grafos, tratando o contexto da mesma forma como aprendemos a tratar nossos dados: como um elemento de primeira classe. E, surpreendentemente, ele é composto por três pilares principais. Vocês já os conhecem. O primeiro é

43:43 a ontologia. E, aqui, não se trata apenas dos recursos para trabalhar com ontologias: o produto já vem com uma ontologia existente, que, ao longo dos anos, percebemos que acaba abrangendo muitos dos aspectos centrais da maioria dos clientes. E, claro, há diferentes configurações por setor. Ele tem um runtime para que você possa executá-lo em produção. Naturalmente, a parte fundamental disso é o banco de dados Neo4j, que está em produção há muitos, muitos anos.

44:16 a ontologia. E, aqui, não se trata apenas dos recursos para trabalhar com ontologias: ele já vem com uma ontologia existente que aprendemos, ao longo dos anos, que acaba abrangendo muitos dos aspectos centrais da maioria dos clientes. E, claro, há configurações diferentes para cada setor. Ele tem um ambiente de execução para que você possa executá-lo em produção. Claro, a parte fundamental disso é o banco de dados de grafos, que está em produção há muitos e muitos anos.

44:47 E então temos as partes de memória de que falei antes, incluindo a conectividade de ponta a ponta durante todo o ciclo de vida, por meio de skills, arquivos Markdown e todo o ciclo completo de feedback. Além disso, acredite ou não, há uma camada de governança centrada nas pessoas, com um estúdio onde você pode entrar, analisar tudo, incluir pessoas no processo, definir aprovações; tudo isso é realmente muito importante hoje e continuará sendo por muitos

45:17 e muitos anos no futuro. Por isso, incorporamos tudo isso diretamente à oferta do context engine. Na prática, isso se parece com um metamodelo de seis camadas, ou um bolo ontológico de seis camadas, que você pode combinar como quiser e que acaba representando muito bem esse alcance de significado e aprendizado. No topo estão essas duas

45:48 camadas. A primeira é uma camada de processos de negócio, na qual você pode dizer: “Tenho uma conta bancária”; isso é um processo de negócio. Tenho as várias etapas pelas quais preciso passar para poder abrir uma conta. A segunda camada contém todos os conceitos centrais do negócio. O que é um cliente? O que é um cartão de crédito? O que é uma conta bancária? Todas essas coisas. Depois, há a camada física, que pode conter produtos de dados, dependendo de se vocês usam esses

46:20 conceitos no negócio, e os sistemas propriamente ditos, sobre os quais falamos antes. Em seguida, há os recursos centrais de que seus agents podem precisar. Eles podem consumir informações de um registro MCP e de outras coisas desse tipo. E, por fim, há os registros de execução dos agents, o rastro deixado por eles. Essa ontologia de ponta a ponta é um ótimo ponto de partida, pelo menos, para colocar essa camada de conhecimento corporativo em funcionamento

46:50 em uma grande organização. Se acharem isso interessante, se parecer algo que possa interessar à sua organização, adoraríamos trabalhar com vocês. Esta é uma jornada que ainda está no começo. Acho que o mundo está aprendendo a fazer isso agora: como fazer os agents agirem de forma confiável em escala. Adoraríamos trabalhar mais de perto com vocês como parceiros de design para ajudar a moldar essa nova oferta.

47:22 Certo, hoje passei muita coisa para vocês. Foi muita informação. Queria tentar dar um passo atrás e resumir, de forma concisa, o que tentei transmitir aqui. Em primeiro lugar, nossos modelos, nossos modelos de IA, são incríveis. Hoje, pelo menos dentro de grandes organizações, a IA não é limitada pela inteligência dos modelos. O que a limita são os dados que fornecemos a

47:52 esses modelos no momento certo. E acho que nosso trabalho, como profissionais de dados, é projetar o mundo em que nossos agents pensam. E acontece que a arquitetura de dados é esse mundo. E, o mais importante para mim, é claro, é que o grafo é uma arquitetura de dados muito, muito natural para a IA. Essas são as três coisas principais que

48:23 gostaria que vocês lembrassem. Trabalho com isso há cerca de duas décadas e quase sempre termino minhas palestras da mesma forma: em outras conferências de dados, as pessoas falam sobre escala, precisão, desempenho e todo esse tipo de coisa. Acho isso muito importante. Como entusiasta de bancos de dados, passei a maior parte da minha vida me concentrando em como fazer os dados funcionarem de forma confiável em escala e todo esse tipo de

48:54 coisa. Mas, fundamentalmente, o que nos diferencia é o modelo de dados central: o fato de termos relacionamentos como elementos de primeira classe entre nossos elementos de dados. Então, quero incentivar vocês, aqui nesta conferência, a não serem documentos tragicamente isolados. Saiam e conversem com os outros participantes, criem conexões e aproveitem o resto do dia. Obrigado a todos. Muito obrigado.

49:25 [aplausos]

Transcrição original

[00:00] [applause] Good morning, London. Uh, great to be here. And truer words have not been said. I used to say that I have the best job in the world, but I don’t get to build demos on exotic hardware in dark mode like my friend Steve Chin does and does so well. Uh, it’s phenomenal to be here. Uh we were started in Sweden about a trillion years ago. But some people don’t know that actually our first office outside of Sweden was actually

[00:32] here in London. It was in my friend uh Jim Weber. He’s our chief scientist, employee number eight. It’s his bedroom in London was our first London office. And uh fast forward to today and you know we have you know several hundred people here in our London office near um London Bridge. And it’s actually our only I call it our only crossf functional office. So we have a big engineering team building many of the key parts of the product but we also have go to market and GNA and it’s like

[01:02] an endto-end office. Uh so London has always been this really important place for us. So it’s always great to be here. So um we got started uh almost 20 years ago today and I was the CTO at a small startup in Sweden and we were building what we today would call enterprise content management content not context. We’ll talk a lot about context later today but enterprise content management. So we were processing large media files or at least what at the time felt like

[01:34] large media files. So you can imagine tons of pictures and PDFs and things like that. And our job was to build what we today would call a multi-tenant SAS application to help make sense of all that data for our customers. So imagine a big file system. You upload your information and then we need to store that on the back end in some way. We had an engineering team of about 20 people and we had a massive problem with our data. And it turned out that half the

[02:04] team about 10 people spent the majority of their time just fighting with the database. And this is a big surprise to me because in all my prior projects the database had been this big accelerant. It took this super big hairy problem of let’s take the data let’s ensure that it’s stored on disk make it queryable multiple users if things crash it needs to always be consistent online backups while it’s running like all of those

[02:35] really big hairy messy thing took them off our table no pun intended so we could focus on building the application but something was different with this project and I think Today, 20 years later, as an industry, we have a clear understanding and a language for what was going on. But it took us a long time to figure it out. The root cause was that we had data that was a mismatch. The shape of that data was a mismatch with the core abstractions exposed by our core data structure and core data

[03:06] infrastructure. And so we had data that was really big and messy and connected and complex. And we had abstractions that look like this. rows and columns in the relational database. The relational database is an amazing piece of both computer science and engineering. Sometimes people want to make it out such that, you know, because I represent another type of database that I hate the relational database and stuff like that. I actually think it’s a fantastic, you know, piece of software. Um, it isn’t good for everything though. And we had that

[03:38] problem where there was this mismatch between the data that we had and this core abstraction. And we ran into the problem. We banged our head against the proverbial relational wall for a while until fundamentally we said you know what there’s got to be a better way of doing this and because we were young and naive we said you know what we actually first we looked around and tried to find other ways of doing it certainly other people had run run into this problem before but after a while young and naive we said screw it let’s just build it from scratch quote how hard can it be

[04:11] and here I am 20 years later we’re still working on building that that database. What we ended up concluding was that many of the problems that we ran into could actually be abstracted out as concepts or entities that are connected to other concepts or entities or rings that are connected to other rings through dots, sorry, through lines, right? Or dots that are connected to other dots through lines. In other words, nodes that are connected to other

[04:43] nodes through relationships. And if we had those fundamental two abstractions, nodes relationships, plus a third one, key value pairs that you can attach to both the nodes and to the relationships, holy crap, we could model everything. Subsequently, it has been proven out that you can model everything. Uh probably three or four decades ago that that was proven out with a relational model. You can take any piece of data and model in the relational model. The property graph model as this now has

[05:13] been been termed is isomeorphic with a relational model. Thus you can model everything every piece of data you can be model with these abstractions. But that’s true of any type of database. It’s true of document databases of key value stores of relational database at least the big popular ones. So that’s no longer the interesting question like can you model your data? The interesting question is it a good fit? It turned out that this way of representing data was a great fit for a lot of important use cases. So, fast forward to today and

[05:47] every single one of the 20 biggest banks at least in North America are now customers and users of this technology. Every single one of the 10 biggest car companies in the world, every single one of the 10 biggest pharmaceutical companies. There were a few people who raised their hand when Steve asked if you were here a year ago. The eagle-eyed people from a year ago will remember it said nine out of 10, you know. So, we’ve made progress since we last met. Um, and so on and so forth. Eight of the 10

[06:17] biggest retailers, insurance companies, and so on and so forth. Almost all of the Fortune50, 85 plus of the Fortune 100 now use Neo Forj in production. So huge amount of of success. All this on the back of this instinct that we had that we articulated as the mission statement of the company which is we want to help the world make sense of data. This we said pre- AI we thought it was valuable even back then. Holy crap

[06:48] is it becoming more and more valuable by the day. Speaking of data and speaking of AI, it took me I don’t know four or five minutes on stage as a tech CEO in 2026 before I said the word AI. So I think that might be a a record. But having spent my entire career focused on data, I’ve seen the biggest change happen in data in the last 12 months. And we all know that AI is the big

[07:18] driver of this. But to be a little bit more specific, the big discontinuity is that for decades, there were only really two types of consumers of data. If you had data in a on on a file system or on on disk, there were two types of consumers of that data. The first one is an application. Many of you in here are developers or were developers, right? And so you write an application that gets the data out of the out of the database. That’s the user. The second type of user is some form of a human

[07:49] typically analyst and there might be some BI dashboard there might be some spreadsheets involved there might be some reports involved but ultimately a human end user is the consumer of that data and in the last 12 months a third category has come online and it’s of course that of agents. Now we have agents that are looking at that data autonomously, assessing that data, making decisions based on that data. And holy crap, that changes everything.

[08:22] A little bit more specifically, let’s talk about an example of this from the perspective of a large organization, right? So let’s say that we’re on a journey to identify our big organization. And maybe this is I’ll use an example from financial services since we’re here in London. Lots of I’ve seen the the stats that lots of people from financial services represented here in the room today. So let’s say that we’re identifying our experience and we have an agent receiving a call from a customer. In this particular situation, the customer wants to they have a loan

[08:53] with us and they want to refinance because a competitor has off came come in with a better offer, right? And so it’s an important customer with several products that we have, lots of relationships to various parts of the bank. And we have some kind of window, let’s call it, in this case we said 30 seconds to make a decision. Should we match that offer? Should we beat the offer with a better one or should we just let the customer walk? So let’s unpack that scenario. Right? Ultimately, we need to figure out what product can I

[09:24] offer this customer and at what price point. And so what do I need to know if I’m the agent trying to figure this out? What’s some of the pieces of data? So first of all, I need to understand who’s calling, right? And that’s actually pretty easy, right? Because they’ve identified in some kind of way when they’re talking to to the agent and I have access to a ton of data. Why? Because I’m a big bank, right? So who’s calling? So let’s look at some of the data in this example. So, in the call center over here, that customer has

[09:54] identified themselves as Charlie Dolan, and that’s probably what they said when they talked on on the phone with with the agent, Charlie Dolan. And then they have a loan with us. So, there’s an origination system of record. Origination in a big bank is all the work that you do prior to approving the loan, like the KYC and all of that kind of stuff, right? And there it’s passport verified to say Charles Dolan. And then in the actual loan servicing which happens once the loan is approved and that’s all the payment and all that kind

[10:24] of stuff it says C Dolan which is ridiculous obviously hypothetical because we had loan origination saying Charles Dolan and of course the handoff over here would never end up with C Dolan [snorts] except every single person here has ever worked at the big company has seen exactly this happen many many times. So we have the same individual identified by three different names. This is called unresolved entities. One example of the type of problem that might occur in the real

[10:55] world in a large organization. Okay. So that’s the first question we want to answer. Who’s calling? Okay. The second question we’re figuring out like should we match or beat or let the customer walk? So how much do they earn? So we look inside of the data for that and that exists across several systems of records. We have a some kind of a mortgage system. We have a credit card system. And we have a wealth system. And they actually have different numbers. And we look at this. And why do they have different numbers? Well, the

[11:25] mortgage one, that’s back to when he actually applied for a loan. And it says $145,000 was was his income. With a credit card, it’s self reported. And then there’s a KYC in the wealth division that was verified last month. So, we’re looking at this and the data is actually from different time eras without the metadata associated saying when it last changed. I’m sure it’s some audit logs somewhere. Certainly isn’t available to the agent to be able to figure out. So, that’s the

[11:57] third type of sorry the second type of problem stale data same right accurate data but wrong time unit. And then the last one is have some kind of tier for the customers, right? And what tier are they is an important factor when they’re the agent is going to decide. And here we have different things. In the retail bank, it says that it’s a standard tier. In credit cards, it says it’s silver and in the wealth it says gold. So this is all accurate just from different perspectives. So in this case we have

[12:28] conflicting data without an established priority hierarchy of what is the single source of truth for this particular dimension on the customer. So three like a non-exhaustive list of data problems that this agent is running into in the real world at a large enterprise. Okay. So what is emerging is this view that I see across our customer base today which

[13:00] is at least inside of large organizations AI is no longer constrained by model intelligence right we have freaking sci-fi level intelligence trapped in a little box that is available to us on tap today it is phenomenal what these new AI models can do. Yes, they are uneven. They’re not perfect across every single dimension. Jagged intelligence, but holy crap are they amazing. That’s not the

[13:31] bottleneck. The bottleneck is giving the right data at the right time to these models. What people end up calling context. And a really fascinating thing that has happened to the industry over the last call it maybe 12 to 18 months, maybe more like 9 to 12 months. I feel like everyone is now converging on exactly the same problem. At least when I think of when I frame it down to getting AI to work inside of the enterprise, inside of

[14:02] large organization, exactly the same problem. It’s some version of I have M agents running across n heterogeneous, disperate, messy data sources and I need to make sense of that, right? M agents across N data sources. How do I get them to act reliably at scale? So, Gartner has done a lot of work on this and they have coined at least an

[14:34] initial name for solving this problem that they call AI context platforms. AI context platforms. It’s a great report. We have one of the authors here somewhere. Hi Aros uh of that report. It’s a really great report. Um and even like I think the name even in the report you say that the name may not stick but the problem is very very real and I want to as an aside on on the name uh context is a word that we hear a lot

[15:06] in AI today and context we have a long history of talking about context actually it turns out at our event here okay in London not in this this room almost 10 years ago. A younger a slightly younger version of me uh gave a talk kicking off an equivalent of this talk at our the bigger version of this conference. Graph Summit is the city bycity tour. Back in those days we

[15:37] did Graph Connect which was an annual conference that we held twice per year. Go figure. Um, this one was here. We called it Graph Connect Europe, even though it was in 2017 because a year after Brexit, because we were still naive about that. Um, and my favorite section of that keynote was the let’s look forward 10 years. It’s like, okay, where is the world of graphs going? It’s still on YouTube today. So, you can you can uh hold me to my hold me accountable to my BS by looking at that and uh see

[16:09] if it makes sense. But why talked about the future of graphs and I said one of the key drivers of the of the adoption of graphs over the next 10 years is going to be AI. I use the word deep learning and machine learning rather than than AI and why because context drives meaning and precision for machine learning systems. And I went on to talk about what context actually is. And this is an example of my context. Right? So this is my context in 2017. I am the

[16:40] father of two kids and this was just a few weeks after my my uh daughter was born. So I remember I had a little animation with a stroller coming in from the left. So now three kids. I work at Neo forj. This is our old logo. I’m married to Meline. I play the piano occasionally. I watch a TV that looks like it’s from the 50s. I’m not sure what’s going on over there. I was born in Sweden. It says that I drive a Tesla. That actually is fake news. I drive a Volvo because Sweden. Um, so if you

[17:11] think about what happened right there in about 10 seconds, I gave you a much richer understanding about who I am. That added a lot of color to me as an individual. And it’s all about how I connect to other concepts in the world. Context is how you how an object relates to everything else in the world. the relationships. So, we’ve seen this for a long time, but boy

[17:43] has the world caught up. Just in three months between April and June, everyone and their mom in terms of the key data platforms and cloud platforms launched a product to solve exactly this problem using exactly graphs and ontologies. A couple of examples. This is data bricks launching Genieontology in June of this year, incorporating an ontolo ontological view of their data platform. Snowflake a month or so

[18:14] earlier did a similar thing with with Cortex. Palunteer of course has been founded as an ontology company from day one. They’re even slightly older than than we are and founded on ontology as the one of the key if not the key secret sauce to make sense of data and the cloud plat platforms as well. So, Microsoft Fabric went GA in in in June with fabric graph and fabric IQ. Google launched their knowledge catalog with based on based on

[18:46] graphs. And AWS has AWS context which is a knowledge graph on top of their data estate. So everyone is independently coming to this conclusion that in order to solve the M agents across N messy data sources, you should use graphs and ontologies, which is great news because after spending the last 12 to 18 months really immersed in specifically this problem as

[19:19] as um with a driver being agents using using data. We have a extremely clear view on how to do this. We as you know have been doing graphs for 20 plus years right now. AI in production for over a decade and specifically transformer-based AI models call it modern AI for about two years right now in production and what’s emerging is an

[19:49] very very crisp understanding of exactly how to solve this problem. I need my agents to act reliably at scale across my data my landscape of disperate data sources. And to solve that problem, there are exactly three things that we need to convey to our agents. No more and no less. Exactly three things. The first one is we need to convey the meaning of data. The second one is we need to give our agents reach across the enterprise data ecosystem in a way that respects security and policies. And we

[20:23] need the system to be self-learning so that it wakes up tomorrow smarter than it was today. Meaning, reach and learning. So let’s double click on each and every one of these. So meaning so what are we talking about here? So let’s say that we have this application. It’s using data in this database. In this example, I’m going to use just some simple order form type thing going on like an order log I guess, right? right? Where we have some kind of order ID, we have a status of

[20:54] the order and then we have an amount per order something like that. The status is two for this particular order over here. The the one in blue what status is two equals to means is encoded in imperative code in Java in this case in this application. If status equals two, go on and do these things hold the order and notify the the review team or something like this. That is what two means. That meaning is encoded in software in the

[21:25] application. Okay. The same data cons you know consumed by the second type of consumer the human analyst. It’s in their head two means suspended pending review and it may be on some post-it note. It may be in some Google doc somewhere. It may be encoded in some Tableau BI dashboard, but ultimately it it’s out of the head of the human analyst for the agent. The agent is going to look at this data and two it has no

[21:56] idea. It has no idea what two means. [clears throat] And so now as an industry we’ve converged. How do we solve this meaning problem? Everyone is saying ontologies to the rescue. And I’ve spent 20 years of my life in the graph universe trying to avoid that world word because it just conveys complexity. Right now all of a sudden everyone is talking about ontologies. And I think there’s it’s because of AI but honestly also because

[22:27] Palunteer has kind of made the term acceptable. Now there’s still a lot of people who have opinions about ontologies. for example, that you have to be over 40 to even discuss ontologies. And I get it, right? Because actually, if you think about the word ontology, it goes all the way back to the old Greeks. Aristotle in metaphysics 4 talk about the structure of reality itself, right?

[22:57] Way back in the days in a little bit more modern time, still feel feels like a while ago. Tom Gruber at Stanford in 93 had a great definition of what an ontology is for computer science. It’s an explicit specification of a conceptualization. I actually really like that definition, but it’s one of the categories of of things where if you know if you already know what an ontology is, you’re like, “Yes, that’s exactly what it is.” But if you don’t know what it is, it doesn’t help you at all. Right.

[23:29] Um, and then the palunteer, they have several ways of talking about ontology. This is one of them. It’s a digital twin that connects an organization’s raw data to the real world business concepts. Um, I like this one. This is from Graph Connect uh in New York in 2018 uh where Dr. Jesus Barasa uh gave a talk about how to store ontologies in in Neo4j. Jesus, are you

[23:59] here somewhere? He’s over there. So, Jesus uh um spent he’s a PhD in knowledge representation in AI. Spent seven years at the ontology company. Um and then a decade at NeoAJ. Um many of you have worked with him or his team running a big part of our solution architect organization. And for the last year or two, he’s been our field CTO for AI. So he has a dedicated team that works with like our most frontier

[24:29] companies in putting graphs and AI in production. There’s no one on the planet that knows more about putting graphs and AI in production. So after this keynote, don’t come up and chase me, chase that guy. And you you can just see how credible he is because clearly he was below 40 at the time, right? And still discussing ontologies. these days however [laughter] so he talks about ontologies as this it’s a domain model don’t be too silly about it conceptualization of a

[25:00] specification no domain model it needs to be three things though it needs to be formal so machine readable it needs to be explicit so not pros in some Google doc kind of thing and the point is to have it be shared right shared across maybe applications shared across teams that’s what is I really like that definition another one is the nouns and verbs of your business. What’s actually going on? Who are your customers? What do they do? What do they have? Right? And how I really think about it, it’s

[25:30] very simple. It’s the type system for your data. I’m ultimately a software engineer by background, right? And this, you know, the the data is the instances and the ontology is the the classes, the types, right? The type system. Okay. So, this is a realworld example of an ontology. uh you know you I’ll talk a little bit more where this is this is coming from right where you have not a single example of an ontology but you have multiple ontologies uh for a given

[26:00] application or a given enterprise but this is a great example of where the people who love ontologies tend to go wrong. It’s like overwhelming with complexity off the start. And actually when you get started there’s really only at at enterprise scale for large organizations there’s really only two that you need. It’s a domainfacing it’s a businessfacing ontology and it’s a technical ontology. The first one describes your customers,

[26:33] your bank accounts, your transactions, your credit cards, your insurance plans, your whatever it is that your business is about, what your colleagues, how they talk about your business. It turns out that agents quote unquote think in the language of your business. This is how to encode that in your businessfacing domain ontology. So that’s the first one. The second really important one is the technical ontology. That one is a

[27:03] map to your data state. It says that over there at that IP address is an Oracle instance. Inside of that is a schema where there’s a customer table and that customer table has a column called F_name, right? And then very importantly, you have the mapping between the two. All of a sudden when your agents want a customer’s first name, it knows that the customers have first name through the ontology the customerf facing ontology

[27:34] and then it has the mapping down into that particular f_name column in that particular Oracle database. So those are the two fundamental ontologies that you need to get started with agents um in in AI. Okay, so that’s the first one. The second one is reach. This one is absolutely fundamental, really, really important. And when I talk to people, when I talk to other data platforms, when I talk to analysts, this is the one that most people miss. They don’t understand how absolutely crucial this

[28:07] one is to make agents work. And so, think about this one from the perspective of where we’re going in the universe, right? So, this is a great report from a a Silicon Valley venture firm called Redpoint earlier this year, and they talked about where we are in terms of adoption of agents. It’s a little bit dated because it’s like six, seven months old and you know how fast this universe moves but it still holds up really really well. And what they’re saying is 25 and earlier we were in the let’s call it chat and co-pilot era and the independent runtime of agent was in

[28:38] seconds right and we were mostly conversing with with with with our agents. Where we are in 2026 is in the universe of task agents. So the independent runtime now is typically in the minutes and it takes on fairly narrow tactical a aspects uh of our business which might still be extremely valuable. What we’ve seen by the way internally at Neo Forj is that throughout 2026 we did have made a

[29:09] little bit of a switch inside of task agents where earlier in the year most of our customers used task agents with humans in the loop like for example they would end up drafting some message but still the human being would be clicking send and sending it out to our customers. So that’s where we started in 2026. By now, many of our customers are making them completely autonomous. Still within fairly narrow remits, but completely autonomous.

[29:39] The next step is end to end workflow agents. So, this is taking on an an entire business function orchestrating this multi-step process end to end with runtime in the hours and then ultimately we’re going to drive it up towards towards days to get what they call autonomous agents. So that’s kind of where we are and what’s going to end up happening as we move from task agents to endtoend workflow agents. We’re going to need to be able to go much deeper. Our

[30:10] agents need to be able to go much deeper across our data estate. And so let’s talk about this from the perspective of an example. Let’s say that again we’re a large financial services organization. We do mortgages. We have lots of customers and we want to go in and we want to offer send send messages that offers a refinance uh to to our customers some kind of upsell offer. It might be over text, it might be over email, over time, maybe even like a voice agent. But let’s just focus on text for a moment. If you think about

[30:40] that that solving that problem for that agent, what do you need to do? So first of all, you need to find the customer, right? Right. Okay. So, this is a particular customer that we want to to draft a a refinancing upsell offer for and we need to look at their data. So, this customer has one house and on that house they actually have two mortgages with one bank. So, that’s important for us to know obviously if we’re going to send some kind of a refinancing message to them. Uh but not just that, we also need all the prior communications which

[31:13] we have across three modalities. We have emails, we have text messages, SMS text messages, and then we have call transcripts, right? All those three are deep chains that we need to traverse. So, in order to draft this upsell financing offer, we need to traverse this entire data estate which is I don’t know 5 10 20 hops deep or something like this. And we ideally want to be able to do it in real time. But then of course in the messy real world then this

[31:44] customer has a spouse and another house that is jointly owned and that spouse has exactly the same thing. Another loan with a separate bank and they call transcripts and communications with them. All of this you need to take into consider consideration when the agent drafts the perfect upsell rate refinancing offer. And then you take this data structure and you look where it would might be stored inside of your enterprise and it rarely sits in the

[32:16] same system. It’s going to be spread out across multiple silos. And imagine if all of them are relational databases, which is still the case, right? And even if one of them is a graph database, that’s very very hard because here we’re talking not 5, 10, 20 hops. This is probably a 100 hops deep or something like this. And you want to be able to do it in near real time to be able to do this at scale with many customers. That level of reach is very very

[32:47] important for an agent to be able to have. Um this is called multihop reasoning. And even though I just said that few people in the data world are talking about this, the labs have figured this out. So they talk about it. So Google research talked about current singlestep rag systems were not designed for the multissource multihop queries of modern business workflows. This is Google research in June of 2026 a few months ago. The same from an anthropic saying

[33:20] you have a pile of unstructured documents no single document contains the answer. Rag retrieval so retrieval augmented generation rag. So vector only rag is what this means. what uh Steve showed you on the left in his demo uh won’t chain the facts for you. You need a knowledge graph that’s enthropic. And then OpenAI almost a year ago said, “Okay, this method allows you to answer complex multiaceted questions beyond what single hop retrieval can

[33:50] accomplish. Uh actually in your neck of the wood, there’s been a great uh research uh report released very recently. You can see it here. National Innovation Center with an RE, not an ER. It’s here somewhere. Um, which uh has really great like scientifically robust, reproducible benchmarks talking about how accuracy goes way up when you add a knowledge graph on the retrieval path uh for your

[34:21] uh for your agents. So that’s the second pillar then reach. Now to the third pillar, learning. This is maybe the most intuitive one. I think we all feel just intuitively that agents have to become better over time, but it’s important to remember that it has to apply to both of those pillars. It has to apply to the schema level or the type level, the ontological level and the instance level. And why is this? Well, first of all, the

[34:53] enterprise landscape is changing all the time in terms of your data, right? Why? because the world is changing all the time. So your agents, even if they just did exactly the same thing, would still need to learn because everything is changing. But then, of course, a huge part of getting to escape velocity with AI is this RL loop, the reinforcement learning loop where your agents wake up tomorrow smarter than they were today. We’ve done a ton of work with this at Neo Forj. So it turns out that memory is

[35:27] an intrinsically graphshaped data structure. Um MCP I’m sure everyone here knows what MCP is. When I ask the question that way no one dares not to raise their hand. [laughter] Um so the model context protocol actually the first release of MCP ships with a tiny little this is a hard thing to say a tiny little in-memory memory implementation. So an in RAM agentic memory implementation um which is a toy. It’s 300 lines of Python. Uh but it’s

[35:59] actually a graph and there’s a ton of startups that are building agentic memory on top of of Neo forj. So lots of people are are independently concluding without even talking to me that memory is a graph shaped uh data structure. Um there’s at the high level three types of memory that I think mostly about. There’s short-term memory which is your core conversation and what’s going on live right now or in the or in the short term with your agent. There’s long-term

[36:31] memory and then there’s the agentic execution traces or the reasoning memory. Um, and the most important thing that I see where people go wrong with agents is that they end up storing the memory, but they don’t have a closed loop system to be able to act on that memory. In the NAM’s service, this is the Neo Forj agent memory service. I’ll throw up a link in a moment. We are encoding that in the entire piece of software. So where you start with your

[37:02] raw information you convert that into your into knowledge with what are the nodes and concepts but then very importantly you then express that in a scale and that skill is represented in the graph and you can materialize it as a normal skills markdown file for your agents to consume. When things change over here in the raw information, your knowledge base gets updated and that invalidates your existing skills.mmd which gets regenerated so that your

[37:33] agent actually immediately uh acts on the new knowledge that the system has learned. Uh there’s a QR code down there. It’s a great uh blog post outlining how this works uh in in practice with a Neo Forj agent uh uh memory system NAS. Okay, so we’ve talked about this really valuable problem. I need my agent stack reliably at scale across my messy data state and the three pillars that are required to get there. The first one

[38:04] meaning we solve with ontologies reach through multihop retriever or multihop reasoning and then learning self-learning uh with with memory. And the really good news is that over the last year, year and a half, 12 to 18 months, we spent a ton of time on this together with lots of customers, some small, some big, some here in this room actually, including large banks, uh, a massive global tech platform, uh, out of

[38:35] the US West Coast, and a leading property tech company to really focus in on solving this this particular problem and what’s emerging is this blueprint that we call the knowledge layer architecture. So the knowledge layer architecture unsurprisingly has three pillars. The first pillar is the ontology pillar. Here you can see the domain model the business facing domain model. You can see the technical ontology which is the systems metadata of exactly where your

[39:06] data sit and then your business rules and actions. The second one is reach. This is an ability to go deep and traverse your your data. And there’s variants of that. You’re going to see some examples of this later on in the product session. And then you have memory of course long short-term procedural memory and then the reasoning memory or the context graph. This is the knowledge layer architecture. And there’s actually multiple configurations of this. So one

[39:38] is what we call the ontology based semantic layer. This is a really easy way to get started. Semantic layers is another one of those terms that is really really overloaded in the word world of of AI right where some people talk about it as BIcentric semantic layers which is very metric centric uh other people come from the RDF world and so on and so forth this is an ontology based semantic layer and it’s a configuration of this architecture where you take all the ontology pillars just with some reference data so the ontology

[40:10] might describe all the geos that you’re in, but the reference data might be, hey, if we have a drop-own list of all the cities, how do we prepopulate that? So, that’s an example. Um, and then there’s a configuration where you start with the ontology based semantic layer, you add memory to it. This particular one, I gave a talk at the AI engineer world’s fair in June. Uh, it’s a very short 9-minute talk. If you want a really brief overview of what I’m talking about here that you want to send

[40:41] your boss for example, this is a good articulation I think. And then you can also start with the ontology plus uh the data. So there’s various ways and shapes that you can configure uh this this architecture. What does it look like in practice though? So let’s say that you have implemented this and you have an agent running. So let’s look at that. um just very pragmatically a flowchart. So let’s say that we have an agent which wants to

[41:11] answer like a similar version of a question that we asked before. What’s our exposure to this customer right step one is for the agent to interpret intent and it calls upon the business facing domain ontology for that what even is a customer what do we mean with exposure those types of questions and then it needs to assemble the context. So after that it goes to the technical ontology. It’s like okay I understand the concepts now where do they sit in my data landscape and then very importantly in

[41:41] any large organization you got to enforce a policy right so what things am I who am I and what am I allowed to access what are my entitlements after that it it’s now assembled the key parts of the context and then it needs to figure out okay how do I get the data and there’s two ways of doing that with a knowledge layer one is you deep query Right? So the technical ontology pointed to that Oracle database. Right? So you deep query into that Oracle database to get the data out. The other one it’s

[42:12] prematerial pre prematerialized already in the graph. So then you can do the deep traversal right away. So that’s the two ways. And then after you’re done, you leave the agent exhaust all the runtime traces from the agent you leave behind so that you can RL on that and self-improve both the ontology and the core instance data. So that’s the full flow of uh how an agent might use a knowledge layer in in

[42:42] in practice. So as I mentioned for the last year or so we’ve been building out this architecture with customers and what we’ve learned is that this is super powerful. It is those three things they are what an agent need in order to work in reality in the messy world of large organizations. [snorts] But it also takes a while. It is something that you have to build from scratch on top of the graph intelligence platform that we’ve spent 20 years

[43:13] building. So what we’ve realized is that hey wouldn’t it be great if we could take this and prepackage it and give you an offering where you can’t get to 100% because every single large organization is unique but maybe 80% or even 90% there. And so we call this the context engine. the Neo Forj context engine. And what it is is taking this entire architecture and all the learnings that

[43:43] we’ve had from the last year, year and a half, but really the last 20 years of doing graphs and 10 years of doing graphs in AI. Pour that into one product that sits on top of the graph intelligence platform that treats context in the same way that we’ve now learned how to treat our data in a completely first class citizen way. And it consists shockingly of three core pillars. You know them. The first one is

[44:16] the ontology. And in here, it’s not just the capabilities of working with ontologies, but actually ships with an existing ontology that we’ve learned over the years that this ends up encapsulating much of the core aspects of most customers. And there’s of course different configurations per vertical. Um, it has a runtime so that you can run this in production. Of course, the fundamental part of this is the near database which has been running in production for many many years now.

[44:47] And then you have the memory pieces that I talked about before, including the end-to-end full life cycle connectivity through scales markdown files and and all the the full feedback loop of that. And then on top of that is a human centric, believe it or not, a governance plane where you have a studio where you can go in, you can look at it, you can put humans in the loop, approvals, all of that kind of stuff is really really important today and will be for many

[45:17] many years in the in in in the future. So we build that right into the context engine offering. So in practice what this looks like is there’s a six layer meta model or a six layer ontology cake that you can mix and match but that ends up representing this meaning reach and learning really really well and at the top are these two

[45:48] layers. The first one is a business process layer where you can say hey I am have a bank account that’s a business process I have the various steps that I have to walk through to be able to open an an account and the second layer has all the core business concepts. So what is a customer? What is a credit card? What is a bank account? All of that stuff. And then you have the physical layer which might have data products depending on if if if you use that that

[46:20] those concepts in in your business and the actual systems that we talked about before. And then you have the core capabilities that your agents might need. This might consume information from an MCP registry and other other things like that. And then ultimately the exhaust of the agents the agent execution traces. This end-to-end ontology is a really good at least start to get that um enterprise knowledge layer up and

[46:50] running in a large organization. If you think this is looks interesting, if this feels like something that uh is um interesting to your organization, we’d love to work with you. This is a journey where you know it’s early in that journey. I think the world is learning how to do this today. like how do you get agents to act reliably at at scale and we’d love to work with you more closely as design partners to help shape this this new offering.

[47:22] Okay, so I’ve given you a ton today. That was a lot of information. Uh I wanted to try to take a little bit of a step back to just kind of summarize in a pathy way of what I’ve tried to convey here. So first of all, our models, our AI models are amazing. AI, at least inside of large organizations, is not constrained by model intelligence today. They’re constrained by the data that we give to

[47:52] those models at the right time. And I think our job as data people is to design the world that our agents think in. And it turns out that the data architecture is that world. And most importantly of course for me is that graph is this very very natural data architecture for AI. So those are the three key things that I

[48:23] would love for you uh to to remember. I’ve done this for about two decades right now and I almost always end my talks with in the same way which is at other data conferences you know people talk about scale and precision and performance and all that kind kind of stuff and I think that’s really important as a database geek that’s what I’ve spent most of my life focusing on how do you get data to actually work reliably at scale and all that kind of

[48:54] stuff But fundamentally what sets us apart though is the core data model. The fact that we have relationships as first class citizens between our data elements. So I want to encourage you here at this conference to not be tragically isolated documents. Please go out and talk to your fellow attendees, make connections and really enjoy the rest of the day. Thank you everyone. Thank you very much.

[49:25] >> [applause]