Agent Skills in Practice: Using Skills to Create Memgraph Query Modules

By Sabika Tasneem

7 min readFebruary 17, 2026

We have all been there. You ask an LLM to write code for a specific engineering task. It generates plausible syntax. But it fails to understand your infrastructure, your deployment rules, or how to actually run the code it just wrote.

General-Purpose (GP) agents lack the operational context that senior engineers have learned the hard way.

In our recent Community Call, Ante Javor from the Developer Experience team showed how to bridge this gap using Agent Skills. He demonstrated how to package complex engineering expertise, like writing and deploying Rust Query Modules, into reusable skills folder that agents can follow safely.

If you missed the live coding session, you should watch the full Community Call recording here.

Here are the key takeaways from the discussion.

Key Takeaway 1: What are Agent Skills

An agent is only as reliable as the instructions you give it. While LLMs are trained on massive datasets, they do not know your internal standards or best practices.

Ante defined Agent Skills as standardized folders containing instructions, scripts, and resources. They act as recipes. Instead of hoping the agent guesses the right workflow, you provide a skill that dictates:

The exact steps to execute a task.
How to recover if a specific step fails.
The resources and documentation needed to finish the job.

This solves the consistency problem. A prompt is a one-off request. A skill is a repeatable, testable capability. It ensures the agent solves problems accurately rather than just generating text that looks correct.

Key Takeaway 2: Why Were Skills Developed

The concept of "Skills" is new but moving fast. Skills are a lightweight, open format for extending agents with specialized knowledge and workflows.

Anthropic introduced it in October 2025, and by December, it became an open standard.

Why did it spread so quickly? Because the industry needed a common format. In just two months, major tools like Claude Code, GitHub Copilot, and OpenCode adopted the standard.

This means you do not need to lock your knowledge into a specific proprietary tool. Because the format is open, different agent environments can consume the same skill folder structure. You define the workflow once, and it works across the ecosystem.

The session also pointed to why this stays manageable at scale. Skills are designed around progressive disclosure:

metadata is loaded up front so the agent knows what skills exist
instructions load only when a task triggers the skill
resources load only when deeper detail is needed, such as API references

That split matters because it keeps context from exploding. It also gives skill authors a clean place to put the implicit knowledge that agents typically miss.

Key Takeaway 3: From Multiple Specialized Agents to One General Agent

A common pattern in teams is to build an agent per workflow. One for research. One for migrations. One for coding.

That approach creates a maintenance problem. If you want to change the behavior, you have to rewrite the agent's core code. Debugging becomes about the agent system rather than the task.

The architecture is shifting toward using one GP Agent (like Claude or GPT-5) equipped with modular skills. Code and text become the universal interface.

You do not need to build a new agent to teach it how to write Memgraph query modules. You simply give your existing general agent the "Query Module Skill." This decouples the model from the capability. You can update the skill file to improve performance without ever touching the agent’s architecture.

Key Takeaway 4: Live Demo – Agent Skills for Memgraph Query Modules

The core of the session was a live demonstration using MAGE (Memgraph Advanced Graph Extensions). MAGE is a library of graph algorithms that runs next to the database, allowing you to run custom procedures written in Python, Rust, or C++.

The Operational Problem

The challenge isn't just writing the code. It is the operational overhead. To write a valid custom query module, a human engineer needs to know:

The language syntax (Python/Rust).
The Memgraph API.
The Docker infrastructure (where files go).
How to test and hot-reload the module.

The Setup

Ante set up a live environment using VS Code with GitHub Copilot (powered by Claude Opus), connected to a running Memgraph container.

Demo 1: Python Query Module for Returning Labels

First, he tasked the agent to write a Python module that returns all node labels. The agent:

Read the Python Query Module Skill.
Generated the correct code using the mgp API.
Automatically deployed the file into the running Docker container.
Ran the procedure to verify it worked.

Demo 2: The Rust Challenge for Counting Nodes

Next, he raised the difficulty level. Rust modules require compilation. This is where the skill proved essential.

A general LLM might try to compile locally or hallucinate a build process. Instead, the Rust Query Module Skill guided the agent to:

Use the specific mgbuild container (which contains the Rust compiler and Cargo).
Clone the necessary Rust bindings.
Compile the binary remotely inside the build container.
Move the resulting .so file to the database container.

The agent succeeded because the skill file provided the deep operational context, specifically the need for mgbuild, that a general model would otherwise miss.

Key Takeaway 5: Skills vs. MCP (Model Context Protocol)

There is confusion about whether Agent Skills replace the Model Context Protocol (MCP). They do not. They play complementary roles.

Skills are the Brain: They contain the knowledge base, the workflow, and the "how-to" logic.
MCP is the USB port: It provides the tools and access to systems, such as connecting to the database to fetch data.

A major issue with MCP is context bloat. It tends to load every available tool definition into the context window immediately. Skills use progressive disclosure. The agent loads only the metadata initially. It reads the detailed instructions only when triggered by a specific task. This keeps the context window clean and the agent focused.

Watch the Full Demo

The concept of Agent Skills moves us away from brittle prompting and toward reliable engineering workflows. Whether you are building GraphRAG pipelines or automating database maintenance, packaging your expertise into skills makes your agents production-ready.

To see exactly how the agent handled the Rust compilation and deployment live, watch the full recording here.

You can also explore the open-standard skills we are building today at the Memgraph Skills Repository.

Wrapping Up

If you are building GraphRAG applications and want to move faster, check out our Enterprise GraphRAG Jumpstart Program. It offers two weeks of dedicated engineering support for promising Proof of Concepts (POCs).

Finally, do not miss our next Community Call on Tuesday, February 17th. Our CTO, Marko Budiselic, will be discussing Atomic GraphRAG.

Q&A

MCP has context bloat when too many tools registered. The Agent skills metadata are all loaded in GP agent prompt. How does that not cause general purpose agent skill bloat the same as MCP context bloat?

With MCP, when you load a tool, you load the description, the name, the arguments, and how the function is called. So there is a lot more context. With skills, it is much smaller: roughly 64 characters for the name, and I think up to 1000 characters for the description (or 500, I’m not sure, it’s on the agent specification page). But the key point is that only these two fields in the metadata are loaded. MCP, on the other hand, loads the full tool description and function prototype immediately, and there are no real limits on how much you expose. What started happening is that people began exposing entire APIs through MCP. So if you have, say, a thousand endpoints in your web API, they expose those thousand endpoints as functions or tools. That takes much more context than a thousand skills with just a name and description. That’s the difference between MCP and skills.