© Nink AI Engineering GmbH

The Agent Wanted a File

"And how can AI work with the ontology tool?" A colleague asked me this while I was showing her nai-onto, my web tool for authoring ontologies. She has a talent for harmless questions that reorganize a roadmap. The honest answer that day was: it cannot, yet. This post is about why the fix was not the chat panel everyone pictures, and what got built instead.

The obvious answer, and its bill

The picture the question conjures is an assistant inside the web app: a text box, a model behind it, "add a class" typed in, a class appearing in the diagram. That version sits at the end of this road, but it is the expensive end. An in-app assistant means an agent component in the application, an LLM API behind it, and a token bill that someone has to pay per request. It also means rebuilding, inside one web app, the harness that already sits on every architect's machine. Claude Code, Cursor, Antigravity: capable agents are already installed, already paid for, and already trusted with our repositories.

And those agents share one strong preference. They are at their best on files in a working copy: reading them, editing them, diffing them, checking them. A web application's database is exactly the substrate they cannot hold. So the integration question inverts. Not "how do I put an agent into nai-onto?" but "how do I give the ontology a file form an agent can work on?"

Ontology-as-code

The answer is a CLI for nai-onto and a workflow I call ontology-as-code, borrowed from infrastructure-as-code, where Terraform shows you the exact change before anything touches production:

• nai pull fetches the ontology from nai-onto into a local file.
• The agent edits that file. This is its home turf.
• nai check validates the local state. If the changes do not hold, the agent loops on local edits until they do.
• nai plan shows exactly what would be written back to nai-onto.
• nai apply writes the changes back.

The property that matters is where the trial and error happens: locally, where mistakes are free. However often the agent misreads the metamodel, it fails against nai check on a file on its own disk, not against the live ontology. And the check is a verdict from code, not from the model; the agent cannot talk itself past it. Only a state that has survived the check, and been made explicit by the plan, ever reaches apply.

Vibe modeling, then, borrowing the vibe-coding label: describe the change in prose and let the agent drive the workflow. This already works. I tell the agent:

In the fleet ontology, add a maintenance-event class linked to lorry via a maintained-by relation, with date and cost properties on the event. Use the ontology-as-code workflow.

One prompt, and the class, the relation, and both properties arrive in nai-onto, checked and planned on the way in.

The road back into the app

None of this rules out the in-app assistant; it builds its foundation. If nai-onto eventually gets its own agent component, that component will not need a private path into the database. It will drive the same pull, check, plan, apply sequence from inside the application that Claude Code drives from a terminal today. The workflow is the contract; the surface is a choice. The surface that costs nothing extra, because the agent and its subscription are already on the machine, ships first.

What comes next

Two follow-ups. First, a DSL. The file the CLI pulls today is faithful but verbose, and verbosity is now a double cost: harder on the human reader and heavier on the token budget. A domain-specific textual notation for ontologies and their data would make the working copy cheaper for both. We have argued for years in model-based engineering that textual notation is foundational; an agent that pays per token is the bluntest supporter that argument has ever had.

Second, extend vibe modeling from the ontology to the data that conforms to it. The maintenance-event class is only the schema; the point of a fleet ontology is the fleet. Once the same workflow manages instances, "log yesterday's maintenance on that lorry, with the invoice amount" becomes a prompt too, and the tool crosses from authoring models to managing what they describe.

The harmless question turned out to be a question about substrates. The agent did not need a window into the tool. The tool needed a file the agent could hold.