"An Ontology for AI Agents Actually Needs" — Ananth Packkildurai
Why this is in the vault
Single-argument essay (not DEW's usual curation format — no numbered items, one continuous thesis with a three-link "Further reading" appendix used as citations, not a link roundup) that gives a precise vocabulary for exactly the design problem RDCO's own vault knowledge graph (~/.claude/scripts/graph-ingest.py, graph.duckdb) already lives inside.
The core argument
An "ontology" gets used to mean five unrelated artifacts (metrics layer, catalog, context graph, learned graph, standards model), and treating them as interchangeable makes the ontology a moving target. Packkildurai's fix is a layered system, not a single file:
- Ontology vs. graph vs. context graph, kept separate. The ontology is the schema (classes, properties, relationship rules — "the grammar"); the knowledge graph is the instance layer (actual entities/relationships — "the evidence"); the context graph is the smallest task-specific slice an agent needs right now. Blending these makes the system "either too abstract to use or too brittle to govern."
- Model the business, not the database. Don't rename
cust_mstrtoCustomerand call it done — that just relabels the source system's accidents. Better sequence for unfamiliar domains: discover first (open extraction over the corpus, normalize/resolve with domain experts to produce a seed ontology), then formalize (re-run extraction guided by that ontology, producing validated typed entities). - Two loops, different tempos. A build loop (continuous/daily) turns new data into governed knowledge and feeds back into ontology corrections; a query loop (per-agent-call) interprets the request, traverses the graph for structured facts, uses vector retrieval for fuzzy context, and escalates on ambiguity. "The query loop is only as trustworthy as the build loop's latest state."
- Trust needs a lifecycle. An LLM-extracted relationship is a hypothesis, not a fact, just because two terms co-occur. Store candidate edges separate from verified edges, with provenance/confidence, and a proposed → evaluated → accepted → remapped → retired lifecycle — citing Grab's production pattern of exposing candidates in lower-risk contexts before promotion.
- Operational maturity checklist: interfaces/composition (shared capabilities across object types without deep inheritance), structs for grouped values plus provenance/confidence/recency metadata, derived properties computed from source-of-truth definitions rather than copied stale flags, entity resolution that preserves uncertainty instead of silently merging records, and security/permissions resolved together with meaning (not bolted on after).
- Start with one decision, not an enterprise-wide model — build a seed ontology and one context path, validate, extend only when the next decision demands it.
Cites Nimit Mehta's ontology-market map, Grab's crowdsourced taxonomy verification, and Bojan Ciric's "Knowledge Spine" piece — the same Ciric argument DEW covered via LinkedIn blurb-only in issue #280 (2026-07-27); this issue functions as Packkildurai's own fuller treatment of the same idea, not a repeat pointer to Ciric.
Mapping against Ray Data Co
The vertex/edge type dictionary in 01-projects/graph-db-eval/vertex-edge-dictionary.md is a working answer to exactly the "ontology vs. graph" split this piece formalizes: Document/Person/Publication/Topic/Framework/Cluster are the schema layer, and the actual ingested rows in graph.duckdb are the instance layer. Where the mapping gets uncomfortable is the trust-lifecycle point — RDCO's graph-ingest currently treats every edge (validates, contradicts, cites, synthesizes) as accepted the moment a newsletter-processing sub-agent asserts it, with no candidate/verified split and no confidence or provenance field beyond "which note said so." Packkildurai's Grab example (candidate edges surfaced only in lower-risk contexts, promoted on accumulated evidence) is a concrete pattern for hardening this: a sub-agent's inferred contradicts or extends edge between two vault docs is a hypothesis about semantic relationship, not a verified fact, and today nothing distinguishes a well-checked edge from a one-shot inference under session pressure — the same failure class flagged generally in feedback_workflow_agent_output_integrity. This also sharpens the CAF Fabric "single governed knowledge graph" bet reaffirmed in the 2026-07-27 knowledge-spine note: the build-loop/query-loop split described here is the missing piece of that bet's operating model, not just its storage layer.
Related
- [[2026-07-27-data-engineering-weekly-agent-local-databases-knowledge-spine]] — same sender's prior issue, same Ciric "knowledge spine" source cited here as a citation rather than curated blurb; direct predecessor covering the CAF Fabric implication
- [[2026-08-10-misteli-semantic-layer-control-plane]] — sibling argument on the same meaning-vs-execution split (semantic contract vs. execution contract), converging independently on "meaning must be machine-checkable, not just documented"
- [[2026-04-07-dbt-semantic-layer-vs-text-to-sql-benchmark]] — the metrics-layer side of the same "a semantic layer answers 'how do we calculate this,' an ontology also answers 'what is this'" distinction this piece draws explicitly