A Developer's Guide to Building a Knowledge Graph

Building a knowledge graph doesn't require a multi-year project or a dedicated data science team. For a developer, the goal is to create a focused, durable context layer that compounds in value each time you switch between AI assistants like Claude Code or a local model running with Ollama. The key is to start with a specific problem, get a concrete result, and expand from there.

This guide provides a developer-to-developer path for building a knowledge graph that serves as a single source of truth for your AI agents, independent of any single tool or vendor.

What is a knowledge graph in 2026?

A modern knowledge graph is a structured, queryable map of your domain knowledge. It's the connective tissue for your projects, clients, internal processes, and API capabilities, weaving disparate information into a coherent model that an AI assistant can reason about.

For a developer, this doesn't have to be a monolithic database. A knowledge graph can be a collection of human-readable files managed in git. Using an open standard like the Open Knowledge Format (OKF), each entity or concept gets its own plain markdown file. These files are version-controlled, making every change an auditable commit. This "knowledge as code" approach creates a single source of truth that is legible to both humans and machines.

Start with a question, not a schema

Many teams get bogged down trying to model their entire organization from day one. A more effective path is to identify one critical question you need an AI assistant to answer reliably. This focus shrinks the initial scope and delivers a valuable result quickly.

For example, instead of modeling the entire company, start with: "Which repositories are associated with Project X and what are their CI/CD statuses?" Answering this question forces you to define a few core components:

• An ontology: A simple definition of your key entities (nodes) like Project and Repository, and their relationships (edges) like HAS_REPO.
• A data model: Your choice between a property graph or RDF, which depends on the questions you plan to ask.
• An ingestion pipeline: A process for pulling in entities and relationships from unstructured or semi-structured data.
• A secure access layer: A protocol like the Model Context Protocol (MCP) that lets agents query the graph for information without getting direct access to underlying systems or secrets. MCP defines a standard interface for assistants to interact with context sources like knowledge graphs.

Designing the graph's ontology and data model

The ontology is the blueprint for your knowledge graph. It defines the core concepts (nodes) and their connections (edges). Getting this right makes the graph understandable for your team and readable for the agents that will use it.

Start by identifying the primary entities in your domain. For a software project tracker, this might include:

• Project: The work being done.
• Client: The stakeholder for whom the work is done.
• Repository: Where the code lives.
• APICapability: A function the project exposes.

The relationships, or edges, are the verbs that connect your nouns: a Client HAS a Project, or a Project USES an APICapability. This structure is the foundation of your graph.

Choosing your data model

Once you know what you want to model, you decide how. For knowledge graphs, this choice is typically between property graphs and RDF triple stores.

A property graph is often the more intuitive path for developers. It's the model used by databases like Neo4j and Memgraph. In this model, nodes have key-value properties (e.g., a Project node with a name property) and are connected by directed edges that can also have properties. This approach is effective for network analysis and finding paths between entities.

The other primary option is the RDF graph. Built on W3C standards and queried with SPARQL, RDF models everything as a simple (subject, predicate, object) triple. It is powerful for integrating data from disparate sources but has a steeper learning curve. See this post on building a personal knowledge graph for more perspective.

Most teams find a property graph to be a more direct starting point for domain-specific applications. The choice isn't permanent, but it sets the direction for your initial tooling.

Aspect	Property Graph (e.g., Neo4j, Memgraph)	RDF (e.g., GraphDB, Stardog)
Flexibility	High. Intuitive for modeling real-world networks. Schemas can be enforced or flexible.	Highest. Excellent for integrating heterogeneous data from different sources.
Query Language	Vendor-specific (e.g., Cypher for Neo4j) but often more intuitive.	Standardized (SPARQL). Powerful but can be complex for beginners.
Common Use Cases	Fraud detection, social networks, recommendation engines, dependency analysis.	Semantic web, data integration, library sciences, enterprise knowledge management.
Learning Curve	Generally lower. The node-property-edge model is easier for most developers to grasp.	Higher. Requires understanding triples, URIs, and the formal semantic model.

For most developer-centric use cases, a property graph provides the fastest path from idea to a functioning graph.

A modern way to manage this schema is to treat it like code. Using a framework like the Open Knowledge Format (OKF), you can define each concept in its own markdown file within a git repository. This "knowledge-as-code" approach makes your data model transparent, version-controlled, and easy to evolve.

Automating data ingestion and entity extraction

The raw data needed for building a knowledge graph is often scattered across documents, meeting notes, and code comments. To turn this unstructured data into a connected graph, you need an automated ingestion pipeline.

This is an LLM-driven workflow. Whether you use cloud APIs or run local models, an LLM can parse text to extract relevant information. The process starts by cleaning and normalizing raw text. Then, Named Entity Recognition (NER) scans the text to tag specific entities—people, products, or project codenames.

From recognition to resolution

Spotting entities is the first step. The next is understanding their connections through relationship extraction. Here, the model determines that Project_Alpha is managed by Jane_Doe. These connections are often distilled into (subject, predicate, object) triples, which form the links in your graph.

However, real-world data is redundant. You might have "ClientX," "client_x," and "Client X Inc." all referring to the same company. Entity resolution (or canonicalization) is the critical de-duplication step that merges these variations into a single, definitive node, ensuring data reliability. See the impact of these knowledge graph creation techniques for more on improving data quality.

An automated ingestion pipeline for turning unstructured text into a knowledge graph typically has five stages:

1. Preprocessing: Cleaning and normalizing raw text.
2. Named Entity Recognition (NER): Identifying and tagging entities.
3. Relationship Extraction: Finding connections between entities.
4. Entity Resolution: Merging duplicate entities into a single canonical form.
5. Post-processing: Validating and loading data into the graph.

Automating this flow creates a repeatable process, ensuring your knowledge graph remains a living representation of your domain, updated automatically as new information flows in.

Putting your knowledge graph to work with AI agents

A knowledge graph is only useful when AI assistants can interact with it. Instead of proprietary plugins that create lock-in, an open standard like the Model Context Protocol (MCP) turns your graph into a durable, central source of truth that any connected assistant can use.

Exposing an MCP endpoint allows assistants to communicate with a specialized vault agent, such as the one in Geode. The vault agent is a planner; it receives natural language requests from the assistant and determines the concrete steps needed to interact with the graph. It uses a few core tools:

• query: Ask natural-language questions to pull information from the graph.
• remember: Add new facts or update existing information, which makes the graph more complete.
• list_capabilities: Discover what tools and actions are available for planning.

The term query here refers to asking a question in natural language, invoke refers to executing an external action, and remember refers to storing new information in the vault. The vault agent's job is to translate a user's request into a plan composed of these actions.

Maintaining a secure boundary

A critical aspect of this architecture is its security boundary. The vault agent plans but never executes external actions and never sees secrets. It creates a step-by-step plan, but the final invoke command is always handled by the calling assistant, not the planner.

The Geode kernel, a self-hostable open-source server, intercepts that invoke call. It retrieves the necessary credentials from a secure secret broker and injects them server-side just before execution. Secrets never enter the model's context window. The caller is the application or assistant that initiates the request.

This separation of duties—where the kernel injects credentials at runtime—ensures that secrets remain out of the model and the client application. The vault agent plans the work, but the caller executes it, and the server-side kernel manages the credentials. This makes the knowledge graph a secure foundation, not a liability. For a more detailed explanation, see our deep dive on the Model Context Protocol for AI agents.

Governance and operations

A knowledge graph is a dynamic asset that requires a solid plan for governance. A git-backed approach, paired with a standard like the Open Knowledge Format (OKF), is a robust strategy. This method treats each piece of knowledge as a human-readable markdown file, where every change becomes an auditable commit.

This gives you a complete, transparent history of your graph.

Treat your knowledge as code

Managing your graph with git applies a "knowledge-as-code" philosophy. When an agent modifies the graph (e.g., via a remember call), that action can be treated as an atomic transaction. If it succeeds, it results in a new commit. If it fails, you can roll back to the last known-good state. This prevents the vault from being left in a corrupted state.

Scaling and monitoring your graph

As your graph grows, you will need to monitor its performance and health. Tracking data provenance—where every piece of information originated—becomes non-negotiable. Establishing clear maintenance procedures and monitoring key metrics ensures your graph remains a reliable asset that compounds in value.

For a deeper dive into managing the underlying infrastructure, check out our guide on creating a self-hosted knowledge base that you control.

FAQ

Common questions from developers building their first knowledge graph.

Property graph or RDF graph: which do I need?

It depends on your goal. For network analysis, pathfinding, and intuitive relationship exploration, a property graph (e.g., using Neo4j) is often a good choice. Its query languages are generally easier for developers to learn. For integrating data from many different sources, an RDF graph is the standards-based choice, though its query language, SPARQL, has a steeper learning curve.

Can a developer build a knowledge graph without a data science background?

Yes. The key is to start with a small, well-defined problem. With a tool like Geode, you can begin by creating a few markdown files for core concepts using the Open Knowledge Format (OKF). You can manually link them and interact with the graph immediately using simple API calls like remember and query. This delivers value right away, and you can add automated ingestion later.

How does a knowledge graph prevent AI agents from leaking data?

A well-designed system uses a strict separation of duties. A specialized vault agent plans actions but never executes them or accesses sensitive credentials. When an AI assistant needs to perform a sensitive action (e.g., call an external API), it declares its intent with an invoke command. A secure kernel intercepts that command, pulls the required secret from an encrypted broker, and injects it on the server side. The AI model itself never sees the secret, closing a major security vector.

---

The best way to learn is by doing. Start by self-hosting the open-source Geode kernel and connect your first assistant. Check out the docs and get started for free.