Will Lyon, senior product manager at Neo4j, explains why agent memory based on embeddings and retrieval alone fails to produce actionable knowledge. He presents Neo4j's model of agent memory as a context graph combining short-term, long-term and reasoning memory, covering entity extraction and resolution, shared ontologies, and decision traces that let multiple agents learn from one another. He then describes distilling grounded, governed skills from that memory, treating skills as typed execution graphs validated for grounding, coverage and coherence, with detection of stale skills. The talk includes a demo of the Neo4j Agent Memory Service distilling a patient-intake skill from a healthcare conversation. Recorded at AI Engineer World's Fair 2026 in San Francisco. # Channel Identity Observations — "Turning Agent Memory Into Skills That Work — Will Lyon, Neo4j" ## Video Format & Context - **Conference session recording**: The speaker opens by inviting attendees in ("feel free to come on in"), references prior conference discussion ("there's been a lot of discussion in this conference so far about loops"), and closes by directing people to a company booth ("we have a Neo4j booth... I'll be there"). - **Technical talk with live demo**: The final portion is a product walkthrough ("Let's see what this looks like. Um so this is NAMS... this is what the dashboard looks like"). - **Explicit self-identification**: > "my name is Will. I'm a product manager at Neo4j" — the presenter speaks in an official vendor-representative capacity. ## Explicit Self-Description Evidence - **Company affiliation stated directly**: The speaker repeatedly frames work as internal Neo4j effort: - > "at Neo4j this is how we think of agent memory" - > "this is a system that we've built at Neo4j" - > "some folks on the Neo4j research team... have done some interesting research" - **Product ownership claims**: He presents the Neo4j Agent Memory Service (NAMS) as a company offering: > "we've implemented this in the Neo4j agent memory service... as part of our Neo4j labs effort" and notes > "this is currently free. Anyone can sign in and try this out." - **Open-source tooling claim**: > "we also have open source tooling around that that implements these patterns." ## Demonstrated Scope (Observable Presentation) - **Topic domain**: AI agent memory architectures, knowledge/context graphs, and skill distillation — grounded in Neo4j's graph-database framing (entity extraction, resolution, ontologies, community detection algorithms). - **Technical depth**: The talk assumes practitioner-level audience knowledge — references to the ReAct loop, embeddings/RAG retrieval, MCP tools, Anthropic's Agent Skills open standard ("agentskills.io"), and a SkillsBench benchmark. - **Hands-on audience check**: The speaker polls the room: > "How many people are using skills with their agents today?... How many people have written skills yourself?... How many folks have had an agent write the skill for you?" — indicating an audience of AI-agent builders. ## Intended Audience (Observed) - **AI agent developers/engineers** working with memory systems and skills, evidenced by the practitioner polls and implementation-level detail (seven-stage pipeline, REST API, MCP tools, entity resolution). - **Conference attendees evaluating vendor tooling**, given the closing call to action: slides QR code, NAMS signup link, documentation, and booth visits. ## Creator Claims vs. Demonstrated Patterns - **Claimed**: Neo4j's three-part memory model (short-term, long-term, reasoning memory) is a pattern "lots of folks are following": > "a pattern that that lots of folks are are following for working with agent memory." - **Claimed**: The APE/graph skill representation research showed measurable benefit: > "found a significant increase in task successfully completed" on SkillsBench. - **Demonstrated**: The speaker shows a working NAMS dashboard with a healthcare-ontology example, ingested conversations, and a previously distilled patient-intake skill with graph-grounded steps — observable evidence of an actual product walkthrough rather than purely conceptual content. ## Presentation Style Signals - **Interactive, informal delivery**: filler speech, audience polls, and time-checks ("I've got a few minutes left here... I'm out of time"). - **Vendor-educational hybrid**: balances conceptual material (memory taxonomy, grounding/coherence heuristics) with product promotion and free-tool onboarding. # Delivery Observation Report — Will Lyon, Neo4j ("Turning Agent Memory Into Skills That Work") ## Overall Style Live conference talk, apparently unscripted and rapidly delivered, moving from framing → concept → research reference → product demo → wrap-up. The delivery is conversational with heavy verbal fillers and repeated comprehension checks. ## Recurring Verbal Habits - **"right?" as a constant tag question.** The dominant tic, often multiple times per sentence: > "the agent is able to do something useful with that right now" > "we need to have some canonical representation of the thing, right?" > "and then share that with other agents in our organization, right?" - **"Cool." as a transition or audience-acknowledgment marker:** > "Cool. So that that's the memory piece." > "Mo most folks. Cool." > "Cool. And then we can also, as I mentioned before, we can also compose skills, right?" - **Doubled/stuttered words** throughout, indicating live unscripted speech: > "feel free to to come in", "this this session", "the the key components", "uh so so something like this" - **Filler density** — frequent "uh" and "um" at clause boundaries. - **"like" and "sort of" as hedges:** > "sort of like a governed skills registry", "is like for example", "like an amnesic loop, right?" - **"and so on" as a list-closer**, used repeatedly: "his name the role that he has uh and so on", "the timing that this took and so on." - **Repetition of key phrases for emphasis**, most notably **"canonical representation of the thing"** (used at least three times) and "grounded" (grounded in actual data, grounded in evidence, grounded in our memory system). ## Teaching Habits - **Concrete running example anchoring abstraction.** The healthcare scenario ("Dr. Nwin, Robert N, the cardiologist") recurs whenever an abstract point needs grounding: entity resolution, ontology, distillation scope. - **Audience polling in an escalating sequence:** > "How many people are are using skills with their agents today? Mo most folks. Cool. How many people have have written skills yourself? Cool. Mo most folks. How many folks have had an agent write the skill for you?" - **Explicit signposting and time management:** "I've got a few minutes left here", "I'm out of time", "We'll take a look at at what this looks like in a minute", "bear with me on on this idea of context graphs". - **Triadic framing** as a teaching device: > "agents need knowledge that is both connected, typed and traceable, right? Not just retrievable" > "short-term, long-term and reasoning memory" - **Numbered/staged process framing:** "seven-stage pipeline", "most of these steps are deterministic", "the first piece is really identifying the scope". ## Communication Patterns - **Jargon followed by immediate re-explanation:** introduces a term, then defines it plainly ("this is um an open standard anthropic um put this out… the basic idea here is that we have some uh some some metadata"). - **Rhetorical question → answer structure:** "But what about this idea of of actionable knowledge, right?" then answers it directly. - **Person-to-person direction at close:** "definitely uh chat with Zach if you're interested in this", "I will be there as well… So we'll see you there. Thanks folks." - **Live-demo self-narration:** "And we're going to see this is going to kick off um in the the distillation queue", "While this is running, let's just take a look at this guy." ## Pattern vs. Isolated Moment - **Stable-looking patterns:** the "right?" tag, "Cool." transitions, doubled words, "grounded" vocabulary, triadic framing, and the healthcare example are all repeated enough to treat as delivery habits. - **Isolated moments (not patterns):** the "amnesic loop" joke near the opening and the "stuff into the context" phrasing appear once each; no repetition claim is made for them. ## Uncertainty Notes - All quotations are taken directly from the transcript. Timestamp markers appear to be segment indices rather than verified wall-clock times, so no pacing or duration claims are made beyond the transcript's own "I'm out of time" signal. Company/product names are transcribed inconsistently ("Neo Forj", "NearJ", "NEFJ", "NAMS"); the actual spellings cannot be confirmed from audio text alone. # Position Record: "Turning Agent Memory Into Skills That Work" **Speaker:** Will Lyon, presenting as a product manager at Neo4j (self-identified in transcript; name also in title metadata) **Format:** Conference talk with live demo **Topic:** Converting agent memory into governed, executable skills using context graphs --- ## 1. Core Thesis ### 1.1 Retrieval Is Insufficient for Agent Memory - **Stated position:** Current memory systems mostly embed text and retrieve similar chunks at inference time. - **Speaker's characterization:** "recall isn't really like actionable knowledge." - **Stated requirement:** Agents need knowledge that is **connected, typed, and traceable**, "not just retrievable." - **Qualification:** The speaker says retrieval "is just a part of the problem," which frames it as incomplete rather than wrong. ### 1.2 The "Amnesic Loop" Framing - **Stated observation:** Agents reason, act, and complete tasks, then "forget what they've learned." - **Hedge:** "Sometimes I feel like we're in maybe like a... amnesic loop." This is offered as an impression, not a measured finding. --- ## 2. Canonical Representation and Entity Resolution ### 2.1 The Problem - The same entity can be referenced in multiple ways. The example given is three different references to "Dr. Nwin, Robert N, the cardiologist," which depend on context. - **Claim:** Agents need a **canonical representation** of each thing. ### 2.2 Proposed Mechanism - Entity extraction from user and assistant messages. - Entity resolution, described as "one of the most important parts" of building the knowledge graph. - A **shared ontology** that describes the data model of the domain. The speaker calls this "one of the key pieces." --- ## 3. Context Graph Architecture for Agent Memory The speaker describes Neo4j's model as a **connected graph** with three components: | Memory Type | Contents (as stated) | |---|---| | **Short-term** | Messages (user and assistant) | | **Long-term** | Extracted entities and their typed relationships | | **Reasoning** | Decision traces, policies, execution plans, tool calls and results, token use, timing | ### 3.1 Reasoning Memory as "First-Class Citizen" - **Position:** Reasoning memory should be stored alongside data, not just actions and data. - **Stated rationale:** "We want to make sure that we're storing thinking the facts not just... the data." - **Structure:** Each decision is linked to its reasoning, "grounded in evidence." ### 3.2 Scope of Benefit - **Individual agents:** Persisting runs helps a single agent improve, but this is described as a lesser goal ("not just so that a single agent can get better the next time"). - **Multi-agent:** The primary emphasis is on **shared context graphs** across hundreds or thousands of agents with shared tool access, so agents "learn from each other." --- ## 4. Skills as the Next Step ### 4.1 Background - The speaker uses memory as "a good representation of what happened" and positions **skills** as the next step toward action. - **Skill definition (as given):** An open standard from Anthropic, hosted at agentskills.io. It includes metadata describing the skill and **progressive disclosure**, where detailed references, often markdown files, are loaded on demand. - **Stated value:** Skills are a shareable, packageable, reusable unit across agents. ### 4.2 Limitations of Skills (as stated) - Skills have "a similar challenge" to memory: they are typically written as prose. - They still struggle with: - Whether the referenced thing is canonical - Whether steps are debuggable - Whether outputs are inspectable --- ## 5. APE: Graph Representation for Skills ### 5.1 What Is Claimed - **Attribution:** Research by "some folks on the Neo4j research team." The speaker names Zach as a contact but does not name the paper's full author list. - **Description:** APE extends the agent skills protocol with additional metadata. It treats skills as **typed execution graphs**, with: - Steps modeled as nodes - A strict schema governing how each step is described and made actionable ### 5.2 Reported Result - **Claim:** On the **SkillsBench** benchmark, applying the APE protocol to **human-curated skills** produced "a significant increase" in task success. - **Limitation:** No figures, baselines, or effect sizes are given in the talk. The result is reported secondhand, and the speaker says only that it "looks interesting." --- ## 6. Skill Distillation: Proposed Method ### 6.1 Goal Distill a memory subgraph (scoped to a workspace, project, entity, or conversation) into a skill that is: - **Grounded** in observed data, not merely written as markdown - **Deterministic** in its procedural steps - **Governed** over time as underlying data changes ### 6.2 Heuristics for Quality | Heuristic | Description (as stated) | |---|---| | **Grounding** | Skill components trace back to memory data. Described as "an important piece," but "not enough for it to be useful." | | **Coverage** | Steps and descriptions across the skill are grounded throughout. | | **Coherence** | Detects when the source subgraph spans multiple topics. The speaker suggests this may mean "you may want to create multiple skills." | ### 6.3 Coherence Detection - Uses **community detection** graph algorithms. - **Claim:** Mixing topics across communities "can be an indication" that the skill should be decomposed. - This signal is surfaced through the governance process. ### 6.4 Governance - **Goal:** Detect when a skill becomes **stale, drifted, or contradicted** as underlying data is changed, removed, or made contradictory. - **Proposed mechanism:** A governed skills registry with dynamic loading, so agents retrieve the most recent version and can tell if it may be stale. - **Status:** Described as design intent. The demo does not show the staleness detection in operation. --- ## 7. Implementation: NAMS (Neo4j Agent Memory Service) - **Description:** Agent memory as a service, part of Neo4j Labs. - **Access:** The speaker says it is **currently free**, and anyone can sign in. - **Open source:** Tooling implementing these patterns is also available. - **Architecture (as described):** - Workspace-scoped context graph with three memory types - REST API and MCP tools for ingestion and retrieval - Background workers that perform distillation - Background curation for governance ### 7.1 Pipeline Characterization > "Most of these steps are deterministic." - **Qualification:** The speaker says an LLM is used **only** for synthesizing some claims and generating some skill description text. - The speaker says the first step is identifying scope, and that each skill component is then grounded in underlying data. - **Note:** The speaker says the pipeline has seven stages but does not enumerate them. --- ## 8. Live Demonstration ### 8.1 Setup - An ontology is loaded for healthcare, covering encounters, providers, and related concepts. - A set of healthcare-agent conversations has been ingested. - The distillation scope is set to the **most recent conversation**. ### 8.2 Prior Example - A previously run example was distilled from a **patient intake conversation**. - The speaker says the resulting skill covers steps "from a patient intake... all the way through... charting." - **Claim:** Each step is grounded in the tool calls and entities that produced it. - The output was packaged as a `SKILL.md` file with references, following progressive disclosure. ### 8.3 Limitations of the Demo - The live distillation was started but **not shown to completion** in the talk. - No evaluation of the skill's quality, accuracy, or task performance was presented. --- ## 9. Audience Responses (Informal) These were show-of-hands prompts, not claims by the speaker, and are recorded only as context: - Most attendees use skills with agents. - Many have written skills themselves. - Most have had an agent write a skill for them. --- ## 10. Unresolved Tensions and Open Questions - **Evidence gap:** The APE benchmark improvement is asserted without numbers in the talk. - **Demo vs. claims:** The governance and staleness detection are described but not demonstrated. The distillation run was not shown finishing. - **Determinism vs. LLM use:** The speaker says "most" steps are deterministic and an LLM is used for "some" synthesis and text. The boundary between these is not specified. - **Scope of applicability:** The demo is healthcare-specific. The speaker does not discuss how the approach transfers to other ontologies, though the ontology is described as a configurable "shared ontology" element. - **Multi-agent learning:** The benefit of shared context graphs across agents is stated as a goal. No evidence of its effect is presented. - **Coherence threshold:** The speaker says community detection can indicate a need to decompose a skill, but does not describe how that threshold is set. --- ## 11. Summary of Positions - **Retrieval-only memory is insufficient** for agents that need to act. - **Canonical entities, typed relationships, and traceability** are necessary. - **Reasoning and decision traces** belong in memory alongside facts. - **Skills should be grounded, deterministic, and governed**, not hand-authored prose alone. - **Graph-based skill representation (APE)** is reported to improve task success, though the evidence is secondhand. - **Neo4j's NAMS** implements this pipeline, with the caveat that parts of it were shown in design rather than in a completed demonstration. # Attribution Observation: Turning Agent Memory Into Skills That Work **Video ID:** `01a15ca6-e0d6-770c-9d01-a18042a0bd61` **Title (as supplied):** Turning Agent Memory Into Skills That Work, Will Lyon, Neo4j --- ## 1. Speakers and Roles ### 1.1 Primary Speaker - **Will Lyon** - **Self-identified role:** Product manager at Neo4j. The transcript renders the company as "Neo Forj" and "NearJ." - **Speaking role:** Presenter for the full session. The transcript shows no other presenter. - **Affiliation basis:** Self-identification in the transcript and the speaker name in the supplied title. ### 1.2 Referenced but Non-Speaking Persons - **Zach** - Named as a member of the Neo4j research team who worked on the APE paper. - The speaker says Zach is "here somewhere" or at the Neo4j booth. Zach does not speak in the transcript. - **Dr. Nwin / "Robert N"** - Appears as an illustrative example of entity-resolution variants ("three different ways that we refer to Dr. Nwin, Robert N, the cardiologist"). - Described as a provider. Whether this refers to a real person or an illustrative label is not stated. ### 1.3 Unidentified Audience Responses - Brief audience responses appear in the transcript ("Most folks," "Cool") to show-of-hands prompts about skill use and authorship. - These responses are unattributed and not identifiable as individual speakers. Counts were not recorded. --- ## 2. Referenced Sources ### 2.1 Standards and Protocols - **Agent Skills open standard** - **Attributed origin:** Anthropic ("an open standard anthropic um put this out"). - **Hosting reference:** agentskills.io (speaker's stated recollection: "I think is where the um open standard is hosted"). - **Use in talk:** Basis for the skill format described (metadata, progressive disclosure, markdown references). - **APE (graph representation for agent skills)** - **Attributed origin:** Neo4j research team. - **Form:** A published paper (screenshot shown, not captured in transcript). - **Described as:** An extension of the Agent Skills protocol with extra metadata that represents skills as typed execution graphs. ### 2.2 Benchmarks and Evaluations - **SkillsBench** (as spoken, "skills bench") - **Attributed to:** The benchmark used in the APE paper. - **Cited in talk:** Speaker states it "found" a significant increase in task success when applying the APE protocol to human-curated skills. - **Note:** No numeric results, methodology, or dataset details appear in the transcript. ### 2.3 Other Cited Concepts - **"React loop" and "Ralph loops"** - Referenced as topics discussed earlier in the conference. No specific source is named. - **Community detection and graph algorithms** - Described as methods used in the speaker's system. No external source is cited. - **Healthcare ontology** - Used in the live demonstration. Origin is not stated beyond "we're using a healthcare ontology." ### 2.4 Speaker's Own Systems and Materials - **NAMS (Neo4j Agent Memory Service)** - Described as the speaker's company's service, part of "NearJ Labs." - **Open-source tooling** - Described as implementing the discussed patterns. No names or repositories given. - **Slides** - Link and QR code shown on screen. Not available in this record. - **Documentation and resources** - Referenced as listed on screen. Not captured. --- ## 3. Third-Party and Attributed Claims Claims are listed with their stated source. The record does not verify them. - **Claim:** Memory systems today are largely built on embedding text and retrieving similar chunks at query time. - **Attribution:** Speaker's characterization. No external source named. - **Claim:** The APE protocol produced a significant increase in task success on SkillsBench when applied to human-curated skills. - **Attribution:** Neo4j research team, per the speaker's account of the paper. - **Claim:** Most attendees use skills with their agents; many have written or had an agent write skills. - **Attribution:** Audience show-of-hands, informal, not quantified. - **Claim:** Most steps in the distillation pipeline are deterministic, with an LLM used only for synthesizing some claims and description text. - **Attribution:** Speaker's description of their own system. --- ## 4. Promotional Segments > **Promotional content is present throughout.** The speaker is a product manager presenting their employer's product and research. - **Product promotion** - Presentation of NAMS as a system the speaker's company built. - Live demonstration of the NAMS dashboard and skill distillation feature. - Statement that NAMS is "free currently" with sign-in access. - **Call to action** - Invitation to visit the Neo4j booth and speak with Zach and other team members. - Slide link and QR code, plus pointers to documentation and open-source tooling. - **Research promotion** - Presentation of the APE paper and its reported benchmark result, from the sponsoring company's research team. - **Affiliation disclosure** - The speaker is employed by the company whose products are presented. This is stated in the transcript. --- ## 5. Availability and Limits ### 5.1 Sources Not Available - **Slides:** Referenced by link and QR code. Not in the supplied material. - **APE paper:** Shown on screen as a screenshot. Not supplied. - **SkillsBench results:** Mentioned without figures. - **Demo visuals:** Dashboard, graph view, and skill package shown on screen. Only spoken descriptions are in the transcript. - **Agent Skills standard text:** Referenced by URL. Not supplied. ### 5.2 Metadata Limits - Only title and transcript were supplied. - No speaker bio, affiliation confirmation, or event details beyond the transcript. - No comment data or comment availability information. - No timestamps or segment markers. ### 5.3 Transcript Quality Notes - Company name appears as "Neo Forj" and "NearJ" in the transcript. The supplied title uses "Neo4j." This record uses "Neo4j" in its attributions and notes the transcript variants. - Names such as "Dr. Nwin" and "Robert N" may be transcription artifacts or illustrative placeholders. Their identity is not confirmed. - Several passages are repetitive or fragmentary, which may affect how exactly speaker wording can be quoted. 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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 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 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 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 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 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 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 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.