Transformando a memória de agentes em skills que funcionam — Will Lyon, Neo4j

Autoria: AI Engineer · Assistir no YouTube

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: Turning Agent Memory Into Skills That Work — Will Lyon, Neo4j · Canal: AI Engineer · 18:05 · Assistir no YouTube

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

Resumo

Will Lyon apresenta uma abordagem para transformar a memória de agentes em conhecimento acionável, representando entidades, relações e decisões em um context graph. Ele explica como skills podem ser geradas a partir desses grafos, com etapas executáveis, dados de origem rastreáveis e mecanismos para detectar quando uma skill fica desatualizada. A palestra também descreve o protocolo APE e o serviço NAMS, que reúne ferramentas para memória de agentes e destilação de skills. Uma demonstração mostra a criação de uma skill para um processo de admissão de pacientes.

Pontos-chave

Recuperar trechos semelhantes não basta: a memória de agentes precisa representar conhecimento conectado, tipado e rastreável.
Um context graph pode reunir memória de curto prazo, de longo prazo e de raciocínio.
Os decision traces registram decisões, evidências, políticas, tool calls, resultados, uso de tokens e duração das execuções.
Skills podem ser destiladas da memória em etapas executáveis e fundamentadas em dados observados, em vez de serem apenas arquivos de texto.
O protocolo APE representa skills como grafos de execução tipados, com etapas e schemas definidos.
A cobertura e a coerência ajudam a avaliar se uma skill está bem fundamentada ou deveria ser dividida em várias.
A governança acompanha mudanças nos dados de origem para identificar skills desatualizadas ou que sofreram drift.
O NAMS oferece um serviço de memória de agentes com API REST, ferramentas MCP e recursos para criar e consultar skills.

Capítulos

Início	Capítulo	Resumo
00:12	Memória de agentes como context graph	Lyon explica por que a recuperação de trechos não é suficiente e apresenta a memória como um grafo de conhecimento conectado, tipado e rastreável.
03:59	Registrando o raciocínio e as decisões	A palestra aborda decision traces que guardam raciocínios, evidências, políticas, tool calls e informações de execução para compartilhar aprendizados entre agentes.
06:07	De memória a skills executáveis	Lyon apresenta as skills e o protocolo APE, que organiza suas etapas como grafos de execução com schemas definidos.
09:56	Destilação e governança de skills	O palestrante descreve como destilar skills fundamentadas na memória e avaliar sua cobertura, coerência e atualização ao longo do tempo.
14:16	Demonstração do NAMS	A demonstração percorre o serviço NAMS e mostra a criação de uma skill de admissão de pacientes, com etapas vinculadas a tool calls e entidades.

Citações

Agentes precisam de conhecimento conectado, tipado e rastreável — não apenas recuperável. — 01:50

Queremos armazenar o raciocínio, os fatos, não apenas os dados. — 04:29

Queremos que isso seja fundamentado em dados que observamos de fato. — 10:27

A maioria dessas etapas é determinística. — 13:06

Conceitos e entidades

Will Lyon (pessoa): Palestrante e gerente de produto na Neo4j.
Neo4j (empresa): Empresa associada ao serviço de memória de agentes apresentado na palestra.
agent memory (conceito): Memória de agentes organizada em componentes de curto prazo, longo prazo e raciocínio.
Context Graph (conceito): Grafo que conecta entidades, relações e informações contextuais para apoiar agentes.
reasoning graph (conceito): Representação das decisões de um agente, incluindo raciocínios, evidências e ações.
APE (conceito): Protocolo que representa skills como grafos de execução tipados, com etapas descritas por um schema.
Agent Skills (conceito): Padrão aberto de skills com metadados e referências que podem ser carregadas progressivamente.
SkillsBench (benchmark): Benchmark citado na palestra para avaliar a aplicação do protocolo APE a skills selecionadas por pessoas.
NAMS (ferramenta): Serviço de memória de agentes da Neo4j apresentado na demonstração.
MCP (ferramenta): Protocolo cujas ferramentas o NAMS pode disponibilizar aos agentes.

Tradução completa (pt-BR)

00:12 Vamos começar. Vejo algumas pessoas querendo entrar. Fiquem à vontade para entrar. Esta sessão será toda sobre conhecimento acionável e grafos de contexto. Meu nome é Will. Sou gerente de produto na Neo Forj. Houve muita discussão nesta conferência até agora sobre loops, certo? O loop ReAct, os loops Ralph. Às vezes, sinto que talvez estejamos em um

00:43 tipo de loop amnésico, certo? Em que nossos agents passam por essa fase de raciocínio e ação. Eles concluem uma tarefa com sucesso, mas depois meio que esquecem o que aprenderam. E os sistemas de memória atuais se concentram, em grande parte, em fazer embedding de texto e, na hora da recuperação, encontrar os dados mais relevantes para inserir no contexto, certo? Então, em algo assim, encontramos trechos de dados semelhantes no nosso corpus e os injetamos na

01:17 context window, confiando que o agent será capaz de fazer algo útil com isso. O desafio que temos agora é que a recuperação não é exatamente conhecimento acionável. Um dos desafios que encontramos, por exemplo, é não termos uma representação canônica de uma coisa, certo? Se tivermos três formas diferentes de nos referirmos à Dra. Nwin — Robert N., a cardiologista —, dependendo do contexto desta discussão, precisamos ter alguma

01:50 representação canônica da coisa, certo? Os agents realmente precisam de conhecimento que seja conectado, tipado e rastreável, não apenas recuperável. A recuperação é só parte do problema quando falamos de memória de agent. Na NearJ, é assim que pensamos sobre memória de agent. Pensamos nela como um grafo conectado composto por memória de curto prazo, de longo prazo e de raciocínio.

02:21 Vamos analisar isso com um pouco mais de detalhes. Mas acompanhem comigo esta ideia de grafos de contexto para memória de agent, certo? Quais são alguns dos componentes principais? Um deles é passar de dados não estruturados para um grafo de conhecimento, certo? Passar por esse processo de mensagens do agent — tanto as mensagens do usuário quanto as do assistant — por um processo de extração de entidades, no qual identificamos quais são as entidades e

02:53 como elas se conectam. Fazer isso em um grafo com tipos bem definidos, certo? Temos um relacionamento que descreve como essas entidades se relacionam. A fase de resolução de entidades é uma das partes mais importantes da construção desse grafo de conhecimento, certo? Entender e garantir que você tenha uma representação canônica da coisa. Então, quando falamos da Dra. Win, sabemos que ela é uma profissional de saúde, sabemos o

03:25 nome dela, o cargo que ocupa e assim por diante. Uma ontologia compartilhada também é uma parte importante disso, então ter alguma descrição do seu modelo de dados e do domínio com que você está trabalhando. Essa é uma das partes principais para garantir que você tenha sucesso ao passar desses dados de texto não estruturados para um grafo de conhecimento. Para quem já trabalhou com memória em agents, isso deve parecer um pouco familiar. Mas há uma coisa que, na minha opinião, é realmente

03:59 importante quando falamos de memória de agent e conhecimento acionável: essa ideia do grafo de raciocínio. Se observarmos nossos três componentes da memória de agent, a memória de raciocínio é um elemento fundamental. Falamos de curto e longo prazo: são as mensagens, as entidades extraídas. Mas e as ações que o agent realmente executa? E o raciocínio? Queremos garantir que estamos registrando

04:29 isso, porque também é uma parte importante. Queremos garantir que estamos armazenando o pensamento e os fatos, não apenas os dados, certo? Ou seja, como um agent tomou uma decisão. Isso normalmente é representado como rastros de decisão. Cada decisão que nosso agent toma está vinculada ao raciocínio fundamentado em evidências. Temos políticas que modelamos explicitamente e entendemos, para aquele plano de execução, as ferramentas que o agent chamou e os

05:02 resultados dessas chamadas de ferramentas. Também queremos registrar coisas como quantos tokens isso consumiu, quanto tempo levou e assim por diante. Tudo isso faz parte do registro da memória de raciocínio. E isso é importante não apenas para que um único agent melhore da próxima vez que fizer exatamente a mesma coisa, mas também para pensar em sistemas com centenas ou milhares de agents que compartilham um conjunto de ferramentas às quais têm acesso. Assim, conseguimos persistir essas execuções de agents, esses

05:36 rastros de decisão no grafo e, então, compartilhá-los com outros agents da nossa organização, para que tenhamos um grafo de contexto compartilhado que permita, essencialmente, que nossos agents aprendam uns com os outros por meio dessa memória compartilhada. Certo. Essa é a parte da memória. Esse é um sistema que construímos na Near Forj, um padrão que muita gente segue para trabalhar com memória de agent. Mas e essa ideia de

06:07 conhecimento acionável? Como permitimos que nossos agents ajam? Memória: uma maneira de pensar nela é que ela representa bem o que aconteceu, certo? Sabemos de quem estávamos falando e como essas pessoas se conectam. Temos esses rastros de decisão. O próximo passo geralmente é criar skills, certo? Quantas pessoas usam skills com seus agents hoje? A maioria. Legal. Quantas pessoas já escreveram skills

06:38 por conta própria? Legal. A maioria. Quantas pessoas já fizeram um agent escrever uma skill para vocês? Certo. Legal. Sim. É disso que estamos falando aqui: passar deste grafo de memória, deste grafo de contexto, para usar isso na criação de skills executáveis e fundamentadas. Se vocês não conhecem uma skill, este é um padrão aberto que a Anthropic publicou. Acho que o padrão aberto está hospedado em agentskills.io.

07:11 A ideia básica é que temos alguns metadados, uma descrição do que é essa skill. E temos essa divulgação progressiva, certo? Tenho muitas informações mais detalhadas. Muitas vezes, elas ficam em arquivos Markdown e referências que podemos escolher progressivamente. Se estivermos seguindo um caminho específico dentro da skill, podemos recuperar e carregar esses dados no contexto. Isso nos dá uma unidade compartilhável que podemos

07:45 pegar, empacotar e reutilizar em diferentes agents. Mas as skills têm um desafio parecido com alguns dos problemas que vimos antes, quando falamos de memória: normalmente trabalhamos com prosa. Então, ainda somos limitados pelo desafio de entender se estamos falando da coisa canônica e de garantir que tenhamos etapas e resultados que possam ser depurados.

08:19 Para lidar com alguns desses desafios que vemos nas skills, algumas pessoas da equipe de pesquisa da NeoRaj fizeram pesquisas interessantes e publicaram um trabalho sobre APE, uma representação em grafo para aprender e governar skills de agent. Esta é uma captura de tela do artigo. Zach está por aqui em algum lugar. Se ele não estiver aqui, está no estande da NearJ hoje. Então, conversem com Zach se tiverem interesse nisso. Mas

08:49 podemos pensar no APE como essencialmente uma extensão do protocolo agent skills, com alguns metadados adicionais que agora tratam suas skills como grafos de execução tipados. Temos etapas modeladas como nós. Temos um schema bem rigoroso que rege como descrevemos essas etapas acionáveis. Pensem nisso como uma forma de

09:20 representar uma skill como um grafo dividido em etapas executáveis, com uma descrição regida por um schema. Esse é o protocolo APE. E, no benchmark usado no artigo, descobriram que isso realmente faz diferença: quando aplicaram isso ao SkillsBench, houve um aumento significativo na conclusão bem-sucedida de tarefas ao aplicar o protocolo APE a skills selecionadas por humanos

09:56 skills. Isso parece interessante. Como podemos aproveitar algumas dessas ideias, algumas dessas pesquisas para a destilação de skills? Essencialmente, o que queremos fazer é pegar esse grafo de memória, certo? Esse grafo de contexto, que talvez tenha o escopo de um workspace ou de um projeto em uma organização, e destilá-lo em uma skill, mas não apenas em um arquivo Markdown.

10:27 Queremos que isso se baseie em dados reais que observamos. Queremos que seja determinístico, certo? Queremos etapas procedurais bem compreendidas no nosso grafo. E queremos poder governar isso ao longo do tempo, certo? Se os dados subjacentes que compõem nossa skill mudarem na memória, queremos conseguir entender isso e ficar sabendo. A fundamentação é uma parte importante aqui, certo? Garantir que os dados que compõem nossa skill estejam fundamentados

10:58 no nosso sistema de memória. Mas isso não basta para que ela seja útil, certo? Há outras heurísticas que precisamos considerar. Por exemplo, a cobertura: estamos garantindo que as etapas e descrições ao longo da skill estejam fundamentadas? Coerência. A coerência é interessante. É uma forma de detectar, talvez, se as informações, o trecho do subgrafo que entra na destilação da skill, está dividido entre

11:30 vários tópicos. Nesse caso, podemos sugerir que talvez seja melhor criar várias skills, e assim por diante. Essas são algumas das partes que levam à geração da skill. A governança da skill é uma parte importante que mencionei. Precisamos conseguir entender, conforme a skill muda e os dados mudam, se podemos atualizar a skill. Com o carregamento dinâmico, dá para pensar em um registro de skills governado, que nos permita recuperar para qualquer agent a skill mais recente e atualizada, entender se ela pode estar desatualizada ou ter sofrido algum desvio. Certo. Legal. Implementamos isso no serviço de memória para agents NEFJ, ou NAMS. Trata-se de memória para agents como serviço, parte do nosso trabalho no NearJ Labs. Também temos ferramentas open source que implementam esses padrões. Essencialmente, funciona assim: temos um grafo de contexto com escopo de workspace

12:02 para que qualquer agent entenda qual é a skill mais recente e atualizada, caso ela esteja desatualizada ou tenha se desviado, certo? Legal. Então, implementamos isso no serviço de memória para agents da NEFJ, ou NAMS, como o chamamos. Isso é uma memória de agent como serviço, parte do nosso trabalho na NearJ Labs. Também temos ferramentas open source relacionadas que implementam esses padrões. E, essencialmente, o funcionamento é o seguinte: temos um espaço de trabalho

12:36 que contém nossos três tipos de memória para agents: memória de curto prazo, de longo prazo e de raciocínio. Temos workers em segundo plano capazes de executar esse processo de destilação. Vamos ver como isso funciona em um minuto. Depois, há um processo de curadoria em segundo plano que continua cuidando da governança e sinaliza quando nossas skills ficam desatualizadas com base nos dados que temos no

13:06 sistema de memória. Este é o pipeline pelo qual passamos para gerá-las. Não vou explicar isso em detalhes. O ponto que queremos destacar é que a maioria dessas etapas é determinística. Só usamos um LLM para sintetizar algumas das afirmações e gerar parte do texto usado na descrição da skill. Outra coisa que quero destacar é que a primeira parte é identificar o escopo: onde

13:38 começar a destilação de uma dessas skills? É em torno de uma determinada entidade, do subgrafo ao redor dela, de uma conversa específica ou algo do tipo? Assim, podemos decompor a forma como representamos a skill e garantir que cada um desses componentes esteja fundamentado, novamente, nos dados subjacentes. É isso que analisamos para determinar se a skill ficou desatualizada. Se algum desses dados subjacentes mudar, for removido ou se tornar contraditório.

14:16 Legal. Como mencionei antes, também podemos compor skills. É aí que entra a coerência. Usamos algoritmos de grafo, como detecção de comunidades. Se estivermos misturando tópicos de várias comunidades, isso pode indicar que precisamos decompor nossa skill, e vamos detectar isso na parte de governança da skill. Legal. Tenho mais alguns minutos. Vamos ver como isso funciona. Este é o NAMS, o Near Agent Memory Service. Atualmente, é gratuito.

14:48 Qualquer pessoa pode entrar e experimentar. Este é o painel. A ideia básica é que temos uma API REST e ferramentas MCP que podemos disponibilizar aos nossos agents, correspondentes à ingestão, recuperação e uso de memória de longo prazo, de curto prazo e de raciocínio. Estamos passando por esse processo de extração e resolução de entidades. Posso ver

15:18 uma representação em grafo da memória do meu agent aqui. Posso percorrê-la e assim por diante. Podemos ver as entidades que foram sinalizadas. Uma parte importante aqui é a ideia de uma ontologia. Neste caso, usamos uma ontologia da área da saúde. Então vamos trabalhar com dados sobre atendimentos, profissionais de saúde e coisas do tipo. E eu ingeri várias

15:49 conversas aqui. Podemos ver as conversas que foram ingeridas relacionadas a um agent de saúde, certo? Agora estamos prontos para destilar uma skill. Como dissemos, a primeira parte é decidir qual será o escopo dessa skill. Podemos fazer isso para um workspace inteiro, mas geralmente não é isso que queremos. Podemos fazer isso em torno de uma entidade específica, de conversas específicas ou de uma classe da ontologia. Vamos fazer isso

16:22 em torno da nossa conversa mais recente. Isso vai iniciar o processo na fila de destilação, buscar os dados, percorrer o pipeline de sete etapas, construir a skill como um grafo e, então, empacotá-la para nós. Aqui está uma. Enquanto isso é executado, vamos dar uma olhada nesta. Esta é uma que

16:52 executamos anteriormente. Ela foi executada em uma conversa de admissão de paciente. Como podem ver, extraímos as etapas que compõem a skill, desde o processo de admissão do paciente até o registro das informações no prontuário. Podemos ver que cada uma dessas etapas está fundamentada nas chamadas de ferramentas reais e nas entidades que formaram os componentes subjacentes da skill. Empacotamos tudo isso com um arquivo SKILL.md. Se baixássemos

17:29 este arquivo, ele seria empacotado com outras referências e assim por diante, seguindo o padrão de divulgação progressiva que usamos com agent skills. Legal. Essa foi uma breve apresentação de como pensamos na memória de agents como parte desse grafo de contexto com a NearJ. Vou deixar alguns recursos na tela. Vocês podem acessar os slides aqui. Há um link para os slides e um código QR. O serviço de memória para agents da NearJ que eu

18:05 mencionei também está listado aqui, junto com bastante documentação e recursos para algumas das nossas ferramentas open source. É isso. Meu tempo acabou, mas temos um estande da NearJ; também estarei por lá, junto com várias outras pessoas da equipe da NearJ. Então, nos vemos lá. Obrigado, pessoal.

Transcrição original

[00:12] Let’s go ahead and get started. I see some folks wanting to to come on in. So, feel free to to come in. Uh, this session is going to be all about actionable knowledge and context graphs. So, my name is Will. I’m a product manager at Neo Forj. Um there’s been a lot of discussion in this conference so far about loops, right? The uh React loop, the Ralph loops. Sometimes I feel like we’re in maybe

[00:43] like a an amnesic loop, right? where our our agents go through this uh reasoning phase acting. They successfully complete some task but then kind of forget uh what they’ve learned. And memory systems today are largely focused around uh embedding text then at retrieval time sort of finding the most relevant data to to stuff into the context, right? Um so so something like this we find you know similar chunks of data in in our our corpus we inject that into the

[01:17] context window and trust that the agent is able to do something useful with that right now the the challenge that we have is you know recall isn’t really like actionable knowledge so one challenge we run into is like for example we don’t have a canonical representation of a thing right so if we have you know three different ways that we refer to Dr. Nwin, Robert N, the cardiologist, right? Like depending on the the context of this discussion, we need to have some

[01:50] canonical representation of the thing, right? So really agents need knowledge that is both connected, typed and traceable, right? Not just retrievable. So retrieval is is uh just a part of the problem when we’re talking about uh agent memory. So at NearJ this is how we think of agent memory. We think of it as a connected graph composed of short-term, long-term and reasoning

[02:21] memory. Uh we’ll take a look at uh this in a bit more detail. Uh but bear with me on on this idea of context graphs for agent memory. Right? So what are a few of the the key components here? Well, one is going from unstructured data to a knowledge graph, right? Going from the this process of agent messages, right? Both user and assistant messages going through some entity extraction process where we’re identifying what are the entities uh and

[02:53] how are they connected. um doing this in a graph where we have strong types, right? We have a a relationship that describes how these entities are related. The entity resol resolution phase is one of the most important parts of building up this this knowledge graph, right? Understanding and making sure that you have a canonical representation of the thing. Uh so when we’re talking about Dr. win we know this is a provider his

[03:25] name the role that he has uh and so on and a shared ontology is an important piece of this right so having some description of your data model of the domain that you’re working with this is one of the key pieces uh making sure that you are successful in going from that unstructured text data to uh to a knowledge graph so for folks that have that have worked with memory uh in agents in the past like this this should look a little familiar. Uh one thing though that I think is really

[03:59] important when we’re talking about agent memory and actual knowledge is this idea of the reasoning graph right so um if we saw in our our uh sort of three components of agent memory here reasoning memory is a first class citizen right we’ve talked about short-term and long-term these are the messages the entities extracted but what about the actual actions that the agent takes what about the the reasoning um we want to make sure that we’re capturing

[04:29] that because that is an important piece as well. We want to make sure that we’re storing thinking the facts not just uh not just the data right so how an agent decided and this is typically represented as decision traces right so every decision uh that our agent makes is linked to uh the reasoning grounded in evidence right we have policies um that that we’re modeling explicitly and we understand for that execution plan the tools the agent called the

[05:02] results of those tool calls. Uh we also want to capture things like how many tokens did this burn, the the timing that this took and so on. This is all part of uh capturing the reasoning memory. And this is important like not just so that a single agent can get better the next time you do it to do the exact same thing, but rather think about systems where you have hundreds or or thousands of agents that have some shared grouping of of tools that they have access to, right? So we’re able to persist these agent runs, these these

[05:36] decision traces in the graph and then share that with other agents in our organization, right? so that we have one shared context graph uh that enables our agents to essentially learn from uh each other in this shared memory piece. Okay. So that that that’s the memory piece. Like this this is um uh a system that we’ve built at at Near Forj, a pattern that that lots of folks are are following for working uh with agent memory. But what about this idea of of

[06:07] actionable knowledge, right? How do we enable our agents to to take action? Uh memory. One way to think of memory is is this is a good representation of what happened, right? We know um the people we were talking about, how they’re connected. we have the these decision traces. Um the next step is typically creating skills, right? How many people are are using skills with their agents today? Mo most folks. Cool. How many people have have written skills

[06:38] yourself? Cool. Mo most folks. How many folks have had an agent write the skill for you? Right. Cool. Yeah. So that that’s what we’re we’re talking about here is going from this memory graph, this context graph to how can we use that to create like grounded uh executable skills. So if you’re not familiar with uh with a skill, this is um an open standard anthropic um put this out uh agentskills.io IO I think is where

[07:11] the um open standard is hosted. And the basic idea here is that we have some uh some some metadata, right? Some description of like what this skill is about. Uh and then this progressive disclosure, right? So I I have lots of more detailed information. These are often in like markdown files, references that we can um progressively choose. If if we’re going down this path of one piece of the skill, we can uh retrieve and load that data uh into context. Right? So this is this then gives us some like sharable unit uh that we can

[07:45] then uh take the skill, package it up uh and reuse that across different agents. But skills have a a similar challenge to some of the issues that we saw uh previously when when we were talking about uh memory, right? is that we’re we’re typically working with pros. Um, and so we’re still often limited in in this uh challenge of understanding is this the canonical thing that we’re talking about, making sure that we have like debugable steps and and output. Um

[08:19] and so to address some of these challenges that uh we’re seeing with skills uh some folks on the NeoRaj research team um have done some interesting research and published some work on APE uh graph representation for learning and governing agent skills. Um this is a screenshot from the the paper. Zach is uh is here somewhere. If he’s not here, he’s he’s at um the NearJ booth today. So definitely uh chat with Zach if you’re interested in this. But

[08:49] you can think of this uh APE is essentially an extension of the agent skills um protocol with some additional metadata that now treats your skills as typed execution graphs. Right? So we have uh steps modeled as nodes. We have uh very um very strict schema that governs how we describe that how these uh steps are actionable. Right? So think of think of this as a way of of

[09:20] representing um a skill as a graph broken up into steps that are executable with a schema governed description. Um that’s the the ape protocol and this is from the uh the benchmark that was used in the the paper found that yeah like this actually matters when when they applied this to um skills bench saw like a significant increase in uh task successfully completed when looking at applying uh the a protocol to human uh curated uh

[09:56] skills. So that looks interesting. How can we leverage some of those uh some of those ideas, some of that research for skill distillation? Uh so essentially what what we want to do is take this this memory graph, right? This context graph that’s maybe scoped to a a workspace or scoped to a a project in an organization and we want to distill that into a skill, but not just like a markdown

[10:27] file. We want this to be grounded in actual data that we’ve observed. We want this to be like deterministic, right? We want uh well understood procedural steps in our graph. And we want to be able to govern this over time, right? If if the underlying data that makes up our skill changes in memory, we want to be able to understand that and and know about that. Um grounding is is an important piece here, right? making sure that the the data that makes up our skill is grounded

[10:58] in our memory system. But that that’s that’s not enough for it to be useful, right? There are other heruristics that we need to look at here. So, uh things like coverage, are we making sure that the uh steps and descriptions of our um throughout our skill are grounded across the skill? Coherence. Coherence is interesting. This is a way that we can detect uh maybe if the um information the piece the subgraph going into the skill distillation is split across

[11:30] multiple topics and we can suggest well you may want to create multiple skills here um and so on. So those are are some of the pieces that lead up to generating the skill. Uh skill governance is an important piece that I mentioned. Making sure that we can understand uh as that skill changes uh as the data changes are are we able to update the skill? And with dynamic loading, you can think of uh having sort of like a governed skills registry that allows us to retrieve uh

[12:02] for any agent the the most recent up-to-date skill, understand uh if that skill may have been uh stale or or or drifted, right? Cool. So, we’ve implemented this in uh the NEFJ agent memory service or we call NAMS. This is um an agent memory as a service as part of our NearJ labs effort. Um we also have open source tooling around that that implements these patterns. And essentially the way this works is we we have a a workspace

[12:36] scoped context graph, right? That has our three types of agent memory, short-term, long-term reasoning memory. Um we have uh background workers that are capable of going through this distillation process. We’ll take a look at at what this looks like in a minute. Um, and then having some background curation process that is still making sure to take care of that governance to surface when uh our skills become stale based on the data that we have in the

[13:06] memory system. Um, this is the the pipeline that that we go through to generate these. Um, the I won’t go through this in in detail. The the one thing that we’re trying to point out here is that most of these steps are deterministic. Um we’re really only leveraging an LLM here uh for synthesizing some of the claims uh generating some of the the text that we use for some of the skill description. Uh and then the other thing I want to call out here is that the first piece is really identifying the scope like where

[13:38] what is your starting scope for distilling one of these skills. Is it around a certain entity? the subgraph around that is it a specific conversation uh and that sort of thing. And so we can decompose uh the the way we represent the skill and make sure that each of these components is grounded again in underlying data. And that’s the piece that we’re looking at for if that skill uh essentially becomes stale. If any of that underlying data changes, is removed or uh becomes uh contradictory.

[14:16] Um, cool. And then we can also, as I mentioned before, we can also compose skills, right? So, this is where that coherence piece comes in. We use um graph algorithms like community detection, right? So, if we’re mixing uh topics from multiple communities, that can be an indication that we need to decompose our skill and we’ll catch that in um the skill governance piece. Cool. So, I’ve got a few minutes left here. Let’s see what this looks like. Um so this is NAMS the near agent memory service. Um this is this is uh free

[14:48] currently. Anyone can can sign in and and try this out. Um this is what the the dashboard looks like. The the basic idea here is that we have um REST API and MCP tools that we can expose to our agents that map to um ingesting, retrieving, working with long-term, short-term reasoning memory. Um we’re going through this entity extraction and resolution process. So I can uh look at

[15:18] some graph representation of my uh agent memory here. I I I can traverse that and and so on. Um we can look at entities that have been flagged. Um one important piece here is this idea of an ontology. So here we’re using a healthcare ontology. So we we’re going to be working with data about you know encounters, providers, uh that sort of thing. Uh and then I have ingested a

[15:49] bunch of conversations here. So we can see the conversations that have been um ingested related to a healthcare agent, right? And so now we’re ready to distill a skill. Um and we said the the first piece is to decide like what is the the scope of that of that skill. We can do this for you know an entire workspace. That’s often not what the case we want. We can do this around um you know a certain entity specific conversations a a class in the ontology. Let’s do this

[16:22] around um our most recent conversation. And we’re going to see this is going to kick off um in the the distillation queue and go through and fetch the data, go through that sevenstage pipeline and um construct the skill as a graph and then package that up for us. Um here’s one. While this is running, let’s just take a look at this guy. So, here’s one uh that we

[16:52] ran previously. This is uh was run on a patient intake uh conversation. And you can see here that we’ve essentially extracted out the steps that make up the skill to run from a patient intake um all the way through uh charting for the patient. But we can see each one of these steps is grounded in the actual tool calls and the entities that constructed the underlying components of the skill. And we packaged this up with skill um MD file. Uh if we downloaded

[17:29] this, we would this would be packaged up with uh other references and and and so on. uh following that progressive disclosure uh standard that we use with agent skills. Cool. So that was a a quick look at kind of how we think about agent memory as part of this context graph uh with nearj and I’ll leave up some uh resources. You can c grab the slides here. There’s a link uh to the slides and a QR code. Um, the nearf agent memory service that I

[18:05] mentioned um is listed here as well as lots of documentation uh and resources for some of our open source tooling. So that’s it. I’m out of time, but we have a NearJ booth uh so I will be there as well as lots of other folks from the NearJ team. So we’ll see you there. Thanks folks.