Ontologies for coding agents

A graph says that a test covers a service. The agent treats that edge as proof that its patch is safe. But the edge came from a model's guess about two file names, and the test has never run against the changed revision.

An ontology defines the kinds of things a system can name, the relations between them, and the rules those statements must satisfy. For coding agents, those definitions help separate a source fact, an inference, and a test result.

Code entities#

Start with the entities needed for a real task. A change-impact query might need repositories, revisions, files, symbols, tests, and deployments. A delivery query may also need tasks and review results.

Give each entity an identity that survives the query. A file path alone is incomplete when two repositories contain the same path. A test result needs the revision it checked. A deployment needs the revision it contains.

Avoid modeling every possible object before the agent has a query to answer. Add a type when it lets the system ask or verify something useful.

Relations#

Relation	Meaning	Evidence
File defines symbol	A declaration exists in a file	Parser output and source location
Symbol calls symbol	A call is resolved under stated analysis rules	Static analysis and its limits
Test exercises behavior	A test reaches a behavior under stated inputs	Test definition or runtime evidence
Run checks revision	A check ran against a particular revision	Recorded run inputs and result
Deployment contains revision	An environment received that code	Deployment record

Keep relation meanings narrow. An import does not mean a function executed. A passed test does not mean every behavior is covered. An agent should be able to inspect the source behind a statement before relying on it.

Constraints#

A graph can reject statements that do not fit its rules. A deployment should name a revision. A call edge should connect valid symbols. A test result should identify the run that produced it.

The W3C Shapes Constraint Language, or SHACL, defines a way to validate RDF graphs against such conditions.¹ A property graph or relational store can enforce some checks through its own schema and application rules. The required check should drive the choice of format.

Validation checks the shape of a statement. It does not prove that the statement is true. A well-formed call edge can still come from an outdated index or an analyzer that missed dynamic behavior.

Time and access#

Record the revision, extraction method, and source location for code facts. Keep inferred relations distinct from directly observed ones. When a file changes, invalidate or recompute the affected facts before presenting them as current.

Apply repository permissions to graph queries. A shared ontology is a common vocabulary; it does not grant an agent access to every fact expressed with that vocabulary.

These rules matter for ontologies for AI agents beyond code. A support agent needs the current contract and customer identity. A coding agent needs the current revision and the correct dependency. In both cases, plausible text can refer to the wrong thing.

A starting query#

Start with a task such as: which callers and tests need review when this interface changes? Define only the entities and relations needed to answer it. Add checks for a missing revision, a deleted symbol, and an unsupported relation.

Then compare the answer with the repository itself. The graph earns its cost when it helps an agent find the right evidence and exposes what it cannot establish.

Read what an ontology buys an agent for the underlying research. Use the code graph and vector search guide to connect that model to retrieval.

Footnotes#

1. W3C. Shapes Constraint Language. ↩

@online{anderson2026ontologiesforcoding,
  author  = {Anderson, Mac},
  title   = {Ontologies for coding agents},
  year    = {2026},
  date    = {2026-10-28},
  url     = {https://macanderson.com/research/ontologies-for-coding-agents}
}