Video Hub

Going Meta S03E07: Agent Skills For Creating and Using Ontologies

Building a knowledge graph from scratch used to mean writing careful prompts, doing a lot of copy-paste, and hoping the LLM stayed consistent across a long session. In this episode of Going Meta, Neo4j’s AI CTO Jesús Barrasa shows a cleaner way: package your methodology into a reusable, portable agent skill and let the agent do the heavy lifting – consistently, every time.

The series is now in its third season, and this episode picks up threads from two previous ones: the MCP-based ontology modeling server from October 2025, and the ontology-to-graph pipeline from January 2025. You don’t need to have watched those to follow along, but they give useful context on why ontologies sit at the center of everything Neo4j does with knowledge graphs.

What are agent skills?

Agent skills are an open format for extending what an AI agent knows how to do. Structurally, a skill is just a markdown file – a front matter block describing the skill’s name and when to use it, followed by natural language instructions. That’s it.

What makes them interesting is how agents use them. Rather than loading every skill into the context window at once, an agent maintains a catalogue of front matter descriptions and activates a skill only when a task matches. The full instructions and any referenced code or templates are pulled in on demand. The agentskills.io site has the full spec, but the format is intentionally as open as text itself.

Skills share a lot in spirit with MCP servers – both extend agent capabilities – but where MCP connects agents to external tools and APIs, skills encode methodology: a sequence of steps, a way of thinking, a personal approach to a problem. And because a skill is just a collection of files, it lives on GitHub, gets version-controlled, and travels with your team.

The ontology builder assistant skill

The demo centers on a skill Jesús built called the ontology builder assistant. Its job is to take three inputs –  a set of competency questions describing what you want your graph to answer, some sample data, and optionally existing vocabularies to reuse – and produce a minimal, well-documented OWL/RDFS ontology ready for use.

A few design choices are worth noting:

Purpose-led and evidence-backed. The skill refuses to add anything to the ontology that can’t be traced back to either a competency question or something in the sample data. No speculative classes, no “it might be useful later” relationships. This minimalism is intentional: ontologies are easier to extend than to shrink, and a lean model is much easier for a team to agree on.

A top-level grounding scheme. Rather than letting the agent invent a taxonomy from scratch, the skill prompts it to map domain concepts to a small set of disjoint top-level categories, such as Party, Event, Location, and Object. In the live demo, the agent generates Party, Event, and Clinical Finding entities for the medical domain. This grounding reduces cross-category confusion and makes integration with external vocabularies much simpler down the line.

Maximum taxonomy depth of three. Deep hierarchies are the enemy of maintainable ontologies. The skill caps subclass depth at three levels, and anything that would go deeper is captured as a skos:example annotation instead – useful for guiding entity extraction without inflating the model.

Modular structure. The skill references separate files for its quality checks (a checklist the agent runs before finalising), an output template (which drives the documentation report), and the conversion code that turns the ontology into a GraphRAG schema. The skill itself is the orchestrator; the logic lives in its supporting files.

From requirements to ontology to graph

The demo uses a set of anonymised medical case sheets – plain text records of doctor consultations – as sample data. Alongside these, Jesús passes a YAML requirements document capturing the competency questions, use case description, stakeholders, and scope assumptions. Jesús also showed how this requirements document could be produced by a companion requirements elicitation skill, which can interview you or process notes from a customer conversation.

With those inputs in place, running the skill in Claude Code produces:

  1. A fully documented ontology serialised as RDF, covering classes (Patient, Encounter, Procedure, Observation, Finding), object properties (has patient, has encounter, etc.), and top-level grounding categories.
  2. A rich documentation report mapping every ontology element back to the competency question that justified it.
  3. A GraphRAG schema JSON derived automatically from the ontology, ready for the GraphRAG Python package.

That last step matters. Once the ontology exists, the skill runs existing conversion code to translate it into the schema format that the GraphRAG package expects for entity extraction. The result is a Neo4j graph whose structure is aligned, by design, with the ontology – not because someone hand-tuned a prompt, but because the schema was derived programmatically.

Jesús also pointed to an interesting next step: capturing the agent’s reasoning trace while the ontology is being built. Every decision – why a class was added, why a relationship was rejected, which competency question justified a modeling choice – could itself be stored as a context graph in Neo4j. That reasoning memory could then become another input for future ontology-building runs, helping agents reuse prior modeling decisions and improve consistency across projects. 

Running the graph pipeline against the 15 sample case files produces a graph with patients, encounters, procedures, observations, and findings – each linked back to the source document chunk that provided the evidence, giving you both the domain graph and the lexical graph in one pass.

Skills are composable

One of the more interesting ideas in the session is that skills layer. You can chain a requirements elicitation skill into the ontology builder, and then chain the ontology builder into a knowledge graph pipeline. Each skill stays focused on one thing. Together, they cover an end-to-end process that previously would have required careful manual coordination across multiple tool calls.

Skills also make methodology portable in a way that prompts don’t. A prompt lives in a chat window or a config file. A skill lives in a GitHub repo, gets a version number, and can be forked, reviewed, and contributed to by a team. The ontology builder skill Jesús demos will be shared in the Going Meta GitHub repo – the invitation is to use it, break it, and improve it.

On dynamic ontologies and team collaboration

Two questions from the live session are worth capturing here.

On dynamic ontologies in real-time agentic systems: additive changes – new classes, new properties – are relatively safe. Structural changes that rename or remove elements can conflict with data already in the graph. The practical answer is to treat the ontology like code: version it, understand the downstream impact of a change before merging, and run the pipeline again when the schema updates.

On team collaboration: the skill-based approach naturally produces artifacts that can live in version control. The requirements document, the ontology itself, and the output report are all files. GitHub handles the rest. The deeper point is that markdown is readable by everyone, not just engineers. A domain expert can review a requirements YAML or flag a missing competency question without touching any code.

Key takeaways for developers

  • Skills encode methodology, not just prompts. If you have a repeatable process – ontology design, code review, data modeling – packaging it as a skill makes it consistent, portable, and improvable by a team.
  • Lead with competency questions. Before building any knowledge graph, define what questions it needs to answer. These become the justification for every class and relationship in your ontology.
  • Stay minimal. An ontology that captures only what’s justified by your requirements is easier to build, easier to extend, and easier to explain. Add elements when evidence supports them.
  • The skill is generic; the requirements are specific. The ontology builder assistant works for any domain – medical, legal, Formula 1 telemetry. What changes is your requirements document. The skill itself stays the same.
  • Version everything. Requirements documents, ontologies, schemas – put them in Git. This is what makes collaboration and iteration on ontologies tractable for a team, and it’s what makes skills portable across projects.

Additional resources

Related Resources

Related Videos

Neo4j & Graph-Powered AI
Context Graphs – meetup and demo
Build Knowledge Graph Agents in Minutes with Neo4j Aura Agent
Our Engineering team!
08:08 Neo4j & Graph-Powered AI

Neo4j & Graph-Powered AI

Watch Video
08:22 Context Graphs – meetup and demo

Context Graphs – meetup and demo

Watch Video
05:35 Build Knowledge Graph Agents in Minutes with Neo4j Aura Agent

Build Knowledge Graph Agents in Minutes with Neo4j Aura Agent

Watch Video