How It Started

How Agents See Code Today

Markdown, grep, glob, regex—these are approximations. Graphs are the actual structure.

So we built it...

1 week. Claude + Python.

We built a parser that turned Python repos into RDF graphs, queryable with SPARQL.

It Worked!

SELECT ?func ?name ?startRow
WHERE {
  ?func a python:function_definition ;
        python:text ?name ;
        python:startRow ?startRow .
}
ORDER BY ?startRow

An agent could ask structured questions about code and get precise answers. No hallucination. No guessing file locations.

Agents are extremely adept at using SPARQL for generalized queries.

Find all functions, trace imports, map class hierarchies—all as graph queries.

What This Unlocked

The Journey Begins

I knew this was a powerful idea. Store codebases as RDF, give agents SPARQL, and they get clear vision of the full repo.

But how could I make this readily available to everyone?

Not just Python. Not just my repos. A universal code intelligence layer that any agent could use against any codebase, regardless of the language.

The Competitive Analysis ca. 6 months ago

It turned out: No, nobody is using SPARQL for code understanding.

Instead I found:

• VS Code plugins — various tooling for working on a local repo. Tightly coupled to one IDE, not composable.
• RAG / embedding tools — quick similarity search over code. Good for finding related snippets, but no structural understanding.
• MCP tools (e.g. Serena) — leverage LSP for code navigation, but a pain to install and use. Not pre-computed or distributable.
• Context aggregators (e.g. Context7) — pull info from the web to give agents more context. Often rely on LLM aggregation, not grounded in structure.
• And interestingly... a defunct Java project called "Web of Code" that sought to link all of Java code into a single linked semantic graph.

Problems I Didn't Want to Solve

Problems I Did Want to Solve

Look at a repo, at a given commit, and give an agent the full picture.

Move to Tree-sitter

173 languages

Tree-sitter gives us fast, incremental AST parsing for basically every language that matters. One parser to rule them all.

Python has function_definition, Ruby has method, Go has function_declaration—same concept, different names.

Ontology-Driven Development

The ontology isn't documentation—it's the source of truth that drives everything:

Change the ontology, and the parser, materializer, and query tool all adapt. Zero code changes.

What the Ontology Looks Like

python:function_definition
    a owl:Class ;
    rdfs:subClassOf ts-core:Node ;
    rdfs:subClassOf repolex:function_definition .

python:name
    a owl:DatatypeProperty ;
    python:isTerminalField true .

repolex:function_definition
    a owl:Class ;
    rdfs:subClassOf ts-core:Node .

# Ruby, Go, Java all map here too:
ruby:method
    rdfs:subClassOf repolex:function_definition .
go:function_declaration
    rdfs:subClassOf repolex:function_definition .

RDFS reasoning materializes the cross-language types at parse time. Query once, get results across all languages.

The Big-AST Graph Problem

Making It Faster: Mirroring Git's Internals

Key insight: Git already content-addresses files. Same content = same blob hash, regardless of filename or location.

Stored as gzipped N-Quads. Append-only commits + content-addressed blobs = efficient incremental updates.

Adding Semantics: LSP via Multilspy

# We see:
import jmespath

# Tree-sitter gives us:
#   import_statement
#     dotted_name: "jmespath"
#
# But where does jmespath
# come from? No idea.

# Now we know:
?import a repolex:lsp.import_statement ;
  repolex:scm.resolution_node ?node .

?node ts-core:sourceFile
  "/site-packages/jmespath/__init__.py" ;
  ts-core:startRow 1 .

SCM queries (.scm files) capture resolution nodes from tree-sitter. Multilspy resolves them to actual definitions.

Currently supporting 11 languages via Microsoft's multilspy. Enables call graphs, cross-file navigation.

The Graph Layers

Each layer is a separate named graph. Compose them for richer queries.

Solving the Dependency Problem: Composable Pre-Parsed Graphs

The dependency question: your code imports libraries. Those libraries import other libraries. How do you query across all of them?

We use deps.dev to resolve dependencies to their actual GitHub repos, and address all code with the org/repo structure. Load multiple graphs into one store. Named graphs keep them organized. SPARQL queries span them all.

What You Can Ask

SELECT ?func ?name
WHERE {
  ?func a repolex:function_definition ;
        ts-core:text ?name .
  FILTER NOT EXISTS {
    ?call repolex:lsp.call_site ?func
  }
}

SELECT ?file ?module
WHERE {
  ?node a repolex:lsp.import_statement ;
    repolex:scm.resolution_node ?res .
  ?res ts-core:sourceFile ?file .
  ?node ts-core:text ?module .
}

SELECT ?class ?method (COUNT(?call) as ?n)
WHERE {
  ?class a repolex:class_definition ;
         ts-core:text ?name .
  ?method a repolex:function_definition .
  ?call repolex:lsp.call_site ?method .
} GROUP BY ?class ?method

SELECT ?yourFunc ?libFunc ?lib
WHERE {
  GRAPH ?yourGraph {
    ?call repolex:lsp.call_site ?libFunc .
    ?call ts-core:sourceFile ?yourFunc . }
  GRAPH ?libGraph {
    ?libFunc a repolex:function_definition . }
}

Distribution on a Budget: repolex-forx

No servers. No cloud compute bills. Just GitHub.

github.com/orgs/repolex-forx/repositories

ASIMOV Integration

Repolex fits into ASIMOV as a perception layer—structured knowledge that feeds into ASIMOV's intelligence architecture.

Verifiable, local-first knowledge. No cloud dependency. The graphs carry provenance—you can trace every triple back to a specific commit, file, and line.

Where We Are

Beyond Code

We've built something that turns Git repositories into composable knowledge graphs.

But Git repos aren't just code.