From System Tables to Ontologies and Kinetics: Building Software That Agents Can Actually Operate

Every company is now trying to point AI agents at their software. Most of them are handing those agents a keyhole and hoping for the best. This is a piece about why that fails, and how we build the missing layer at Hyper. We call the output a Hyper ontology, and it is the difference between an agent that guesses and an agent that operates.

When a platform generates an application it usually generates the agent surface the same way it generates everything else: five tools per table. List, get, create, update, delete. For a system with 86 collections that is roughly 430 tools. Each one is a thin wrapper over a single table. 

An agent handed that surface gets a flat view of the business. It cannot see how anything connects. It has no real verbs, only column writes. It carries no meaning, so it has to reverse engineer your domain from tool names. And it has no guardrails, so updateDeal(stage: “closedwon”) will happily jump a deal straight from prospecting to closed, skip every stage in between, and corrupt your pipeline without a warning. 

The problem is not that the agent is unintelligent. Modern models are very capable. The problem is that we gave the intelligence a black box to reason about. System tables are the black box. The ontology is the structured reality.

An ontology is a typed model of your business that sits above the raw tables. It has two layers. The semantic layer answers what exists and how it connects: object types, their properties, and the typed links between them. The kinetic layer answers what can happen: governed actions with preconditions, effects, and approvals, and a lifecycle state machine that says which transitions are legal. 

Put together, the ontology is a knowledge graph over your data, plus a set of safe operations on it. That combination is what turns a schema into something an agent can operate. And it maps onto a pattern the industry now has a name for: neurosymbolic AI. The agent is the probabilistic, neural half. The ontology is the formal, symbolic half. The ontology is the contract between them, so the symbolic layer keeps the probabilistic one on track.

We build the ontology as a pipeline that runs on the schema you already have. There are three stages, and only one of them needs a human. 

Stage one: generate the structure from the schema

The first stage is deterministic. We read every model in the codebase and extract the object types, their typed properties, and the link graph straight from the foreign key associations. No AI, no invention, no hallucination. 

// gen-ontology.mjs 

const cls = src.match(/export class (\w+) extends Model/)?.[1];  // -> "Deal" 

const prop = /(\w+):\s*\{\s*type:\s*DataTypes\.(\w+)/g;      // -> properties 

const link = /(\w+)\.belongsTo\(\s*(\w+).*as:\s*['"](\w+)['"]/g;  // -> links 

Stage two: enrich with meaning and verbs 

A schema cannot encode meaning. It does not know that a Deal is also called an opportunity, that prospecting comes before qualification, or that closing a deal moves real money and should require a human. Enrichment adds that. A model drafts the semantic and kinetic layers, grounded strictly to the real schema and the real enum values, and a person confirms it.

Extraction, not synthesis. The lifecycle states are pulled from the real enum in code. The transitions, synonyms, and actions are the model applying general business knowledge, pinned to your actual fields so nothing is invented. That grounding is why a Hyper ontology avoids the provenance problems of a knowledge graph a model builds from unstructured text. 

Stage three: the manifest, and seven tools that read it 

The merged output is a single config file, the manifest. It is data, not code. The engine that reads it is a fixed set of seven generic tools. They contain no business logic. They operate on a type, which is a parameter they resolve from the manifest at runtime. 

The tool that matters most is invokeAction. Before any write, it validates the proposed action against the ontology: it checks the action role, confirms the object exists, enforces the legal lifecycle transition, and if the action is sensitive it routes an approval request instead of writing. The guardrails live in the tool layer and the agent cannot skip them.

People hear ontology and reach for a graph database. You do not need one. A graph is about how you model and access relationships, not about the storage engine. Foreign keys are already edges. The ontology lifts them into first class, typed, traversable relationships, so your relational database starts behaving like a knowledge graph while keeping transactions, integrity, and the tooling you already have.

That covers what most teams actually want from a knowledge graph: connected, typed, traversable, cross domain data. The one thing a config driven ontology does not give you is automatic logical inference, the RDF and OWL style deduction of new facts. Most teams do not need it, and Palantir made the same call: the ontology sits over datasets, not a triple store. If you ever do need inference, you add it as a separate layer rather than rebuilding your storage.

Because stage one is deterministic and runs on the schema, we bake the whole pipeline into the platform. When Hyper generates an application, it emits the database, the API, and the MCP tools. Alongside those it emits the ontology manifest and the seven tools that read it. Enrichment is exposed as a step the customer owns, because the long tail of a customer's specific domain is knowledge only they have. 

The result is that every generated application ships as agent ready software by default. Not a table browser with a chatbot bolted on, but a system with a real world model, a governed action layer, and a control plane where a company can see and change its own ontology. Controlling the ontology means controlling what every agent and every copilot can see and do, from one place. 

The takeaway 

The database you already have is not the problem. The missing piece is the layer above it that gives agents structured reality instead of a black box. That layer is the ontology: a typed graph of your business plus a governed set of operations on it, generated from your schema, enriched with meaning, and served through a small fixed set of tools. 

Build that, and the agents stop guessing. They discover your world, traverse it, and act on it safely. That is what a Hyper ontology is for. 

Stack 

Hyper generates the application, and with it the database, the API, and the MCP tools. Postgres holds the relational store whose foreign keys become the ontology's typed links. The ontology itself is a single manifest, read at runtime by seven generic MCP tools, with invokeAction enforcing roles, lifecycle transitions, and approvals on every write. Enrichment is the one human step, and the customer owns it. 

This is a technical blog designed to showcase the capability of the Hyper platform, specifically, it’s ontology layer. The ecosystem it belongs to CodeNinja and is documented at Hyper Ontologies.