TL;DR
OntoTower is a way to describe a single working system so that the agent gets a ready-made spec sheet in its prompt. For every sensor or field it records: what it is, what units it uses, how it was verified, its known failures and gotchas. Then come the links between nodes, assumptions (“we assume pressure is 1013 hPa”), derived quantities and lessons from the operations log. There are few entities (in the study, a few dozen points), but there’s a lot of knowledge about each one. It’s the opposite of “broad” vocabularies with many object types, each described in a single line.
Without such a spec sheet, the agent sees only labels and numbers. It grabs the most plausible wrong explanation: say, a humidity label hints at one location while the sensor actually sits in another. Another non-obvious result: the agent uses lessons from the log only if they sit right in the context. If a lesson is buried in the log behind a search tool, the agent almost never gets to it. The spec sheet raised the share of cases where the agent sidestepped the task’s main trap by about 20 percentage points. A small model with the spec sheet caught up with the largest one on overall score.
The method in three moves. First: build a text spec sheet of the system, narrow and deep. Second: add lessons from the incident log to it as separate notes on the points they concern. Third: put the whole spec sheet in the prompt instead of leaving it behind search. Meanwhile, all agent actions on the real system go through an immutable safety layer.
Important caveat: the available text of the paper has no results section. The numbers below are taken from the abstract.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: Pick ONE system, list its points (sensors, fields, parameters)
→ a list of dozens of entities, not hundreds
STEP 2: Describe each point in depth
→ what it is / units / how it was verified / known faults /
which quantities are computed from it / which assumptions it rests on
STEP 3: Describe links and automation
→ which nodes affect which, operating ranges, internal logic
STEP 4: Assumptions — as separate items with a status
→ “we assume X” / “confirmed” / “pending verification”
STEP 5: After every incident — a lesson as a note on the affected points
→ “the "normal" flag can hide an abnormal cycle”
STEP 6: All of this as one text in the agent’s prompt (not behind search)
→ spec sheet ~45,000 characters in the study
STEP 7: Any agent action on the live system goes through a safety layer
→ allow list, permitted range, change step, pauses,
human priority, “accepted / rejected” record
Steps 1–6 are text; you can do them in a chat. Step 7 is implemented in code in the paper.
Example
Task: You run marketing for an online store. End-to-end analytics are stitched together from Google Analytics 4 and HubSpot. An analyst agent digs into anomalies: “on Wednesday, conversion to payment dropped by half.” Without context, it sees the “Deal date” field and treats it as the payment date. But it’s the date the deal record was created. The agent confidently blames the drop on the wrong thing. The “Source” field is filled in by hand for some deals — that’s the second trap. In the spring you figured out that over holidays, reps close deals in batches with backdated entries. The lesson stayed in the team’s Slack channel.
Prompt:
You are an end-to-end analytics analyst for an online store. Below is the system spec sheet.
Read it before drawing conclusions from the data. If a conclusion rests on an
assumption with the status “not verified,” say so explicitly.
<System>
Google Analytics 4 + HubSpot, exported once a day to a Google Sheet.
</System>
<Points>
- hs_deal_date: the date the deal record was CREATED in HubSpot (not the payment date).
Units: date, ET. Verified: 03/12, reconciled against the bank export.
Known gotchas: when a deal moves between pipelines, the date doesn’t change.
- hs_paid_date: the date the deal moved to the “Paid” stage. Filled in by the sales rep.
Known gotchas: on holidays, entered in batches with backdated dates.
- ga_source: visit source from Analytics. Verified: automatically.
- hs_source: source, filled in manually by the sales rep.
Known gotchas: ~15% of deals have it empty or “Other.”
</Points>
<Links>
conversion_to_paid = hs_paid_date / hs_deal_date (by creation cohort).
Analytics → HubSpot are joined by client_id, match rate ~92%.
</Links>
<Assumptions>
- client_id match rate is assumed to be 92% — status: not verified since January.
- Exchange rates are ignored, all amounts in USD — status: confirmed.
</Assumptions>
<Lessons>
- 01/01 and 02/17: conversion “dropped,” but the real cause was batch payments
entered with backdated dates. Before concluding there was a drop, check whether it’s a holiday period.
- Never treat hs_deal_date as the payment date under any circumstances.
</Lessons>
Task: on Wednesday, May 14, conversion to payment dropped from 4.1% to 2.0%.
Name the most likely causes. For each, state which points in the spec sheet
confirm it and which assumptions support it.
Result: The model will first check against the spec sheet: see whether it’s a holiday period and avoid confusing creation date with payment date. Then it will give a list of causes. Each cause will list the spec-sheet points it relies on and the assumptions with their statuses. The model is less likely to hand you a bare “demand fell” as the only explanation.
Why it works
The weakness. An agent without a spec sheet sees names and numbers. Names often lie: the field is called “deal date,” but it’s the creation date. The model picks the most plausible explanation, and it’s often wrong. These traps aren’t visible from the data; only the people who operate the system know them.
The strength. Models make good use of whatever sits right in the context. If the text says “on holidays, dates are backdated,” the model will factor that into its reasoning. A narrow spec sheet for one system fits in the prompt entirely, so the agent doesn’t need to search for anything.
How the method exploits this. “Narrow and deep” means: don’t describe the whole world — describe in detail what the agent actually works with. Lessons from the log turn into notes on specific points, and those notes are always visible. A log behind search works poorly: the agent doesn’t know what to look for. Assumptions are pulled out as separate items with a status. So when an error is discovered, you can see which conclusions need to be recalculated.
Knobs: - Depth of each point’s description. More fields (units, verification, gotchas) give more accurate answers but a longer prompt. Start with the gotchas: the traps have the biggest effect. - Spec sheet size. About 45,000 characters in the study. For smaller tasks, a page or two is enough. - Assumption status. Add “not verified” and simply require the model to cite it. It will start showing the weak spots in its conclusions. - Lessons. Record every incident, not just the “important” ones: the spec sheet gets more accurate with every month of operation. - Delivery format. Whole in the prompt, not behind search. The paper tested this.
Prompt Template
You are a {role} for the “{system}” system. Below is this system’s spec sheet.
Read it in full before analyzing. Don’t draw conclusions that contradict
the spec sheet. If a conclusion rests on an assumption with the status “not verified,”
say so.
<System>
{short description: what it is, what it consists of, how it works}
</System>
<Points>
- {point_name}: {what it really is}.
Units and scale: {units}. How verified: {when and how}.
Known gotchas: {how the name is misleading, where the sensor lies}.
Computed from it: {which quantities}.
- {point_name_2}: ...
</Points>
<Links_and_automation>
{which nodes affect which; how the automation works; operating ranges;
constraints one node imposes on another}
</Links_and_automation>
<Derived_quantities>
- {quantity} = {formula} (inputs: {points}; assumptions: {which})
</Derived_quantities>
<Assumptions>
- {assumption} — status: {confirmed / not verified / pending verification}
Affects: {which quantities}
</Assumptions>
<Operational_lessons>
- {date, incident}: {what happened}. Lesson: {how to read the data now}.
Concerns points: {names}.
</Operational_lessons>
<Action_boundaries>
Allowed to change: {list}. Permitted range: {from — to}.
Maximum step at a time: {number}. Pause between changes: {time}.
If a human intervened recently — don’t act, report it.
</Action_boundaries>
Task: {task}
In your answer, for each conclusion state which points, assumptions and lessons
from the spec sheet it rests on.
What to fill in: {system} — one specific system, not the whole business. {point_name} — real names of fields, sensors or parameters. Gotchas — the most valuable field: put in everything that “everyone knows but nobody wrote down.” Lessons — take them from the incident log, chats, postmortems.
🚀 Quick start — paste into a chat:
Here is a system spec-sheet template for an LLM agent (the OntoTower method). Adapt
it to my task: {describe the system and what the agent should do}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about the real names of your points, their gotchas, assumptions and past incidents. Only you have this knowledge, and the method rests on it. It will take the structure from the template and assemble a spec sheet for your system.
Limitations
⚠️ One installation: Everything was tested on a single test rig (air dehumidification), on nine tasks, four of them diagnostic. The authors discuss transfer to other systems but didn’t test it.
⚠️ Not all parts of the tower were tested: Derived quantities and assumptions exist in the tower, but they weren’t in the text given to the agent, because at this plant the formulas live in code. The comparison mostly covered the descriptive part of the spec sheet; the contribution of computed quantities wasn’t tested separately.
⚠️ A lesson outside the context barely works: If you leave lessons in the log behind search, the agent rarely uses them. Don’t expect it to find and apply an old entry on its own.
⚠️ The spec sheet needs maintenance: It’s useful as long as lessons keep being added. Outdated or wrong entries do as much harm as missing ones.
⚠️ The safety layer is code: In the study, action constraints were implemented in software and checked every command. Writing the rules into a prompt isn’t the same thing: a prompt doesn’t guarantee they’ll be followed.
⚠️ Incomplete data in the text: The available excerpt has no detailed results. The numbers come from the abstract; details by model and task aren’t visible.
⚠️ LLM judge: Answers were scored by a language model. Agreement with a second judge was good, while agreement with the first author on a small sample was slightly below the stated threshold.
How the research was done
The idea was simple: what exactly does an agent need to know about a plant, and in what form should it be given? The authors took a real pilot air-dehumidification unit used daily by several research groups. From its records they built nine tasks: five on reading measurements and four on diagnosing real incidents. Each task had pre-defined “traps” — plausible wrong conclusions the data nudges you toward.
Knowledge was given to the agents at five increasing levels: from raw addresses and numbers, to named tags, the spec sheet, procedure summaries and log search. Plus six variants with a different delivery format (for example, the whole tower as JSON, or three tools for querying the tower). They tested four open models, from 9 to roughly 750 billion parameters. The main comparisons used 1,304 runs. Hypotheses were pre-registered, and answers were scored by a different LLM that knew neither the model nor the condition.
A separate experiment tested whether it matters where the lesson lives. The lesson from each incident was given in three ways: as a node in the spec sheet, as a log entry in the prompt, and as an entry hidden in the log behind search. That made 144 runs. Conclusion: lessons work when they’re built into the spec sheet or sit in the prompt, and barely work behind search. A surprising result: a small model with the spec sheet caught up with the largest one on overall score. Knowledge about the system makes up for part of the gap in model size.
Finally, agents changed setpoints on the live unit through the safety layer. In 12 of 14 runs, the target variable reached the desired range. Agents learned the limits from the safety layer’s rejections, not from a hint.
Adaptations and extrapolations
💡 Adaptation: post-incident lesson → knowledge node. In the paper, for two tasks the node was written by a separate model: it was given the incident record, the node format and a pointer to the log entry. You can replicate it like this:
Here is an incident record: {text}. Here is the format for a lesson entry in the spec sheet: “{date, incident}: what happened. Lesson: how to read the data now. Concerns points: {names}.” Write one entry in this format. Don’t add anything that isn’t in the incident record. If no lesson follows from the record, write “no lesson.”Check the result by eye: the model may invent extras.
🔧 Technique: add an assumption status → the agent points out its own weak spots. In the assumptions block, mark “not verified” and require, at the end of the answer, a list of conclusions that collapse if the assumption turns out false. This carries the paper’s idea (assumptions as nodes with a status) over to an ordinary chat.
🔧 Technique: action boundaries in words → a soft safety layer for an agent with tools. In the agent’s instructions (for example, in an instructions file), list what it may change, within what limits, and when to stop and ask a human. This doesn’t replace a code-based safety layer, but it lowers risk where there’s no code. Important: in the paper this protection is implemented in code and wasn’t tested in prompts.
Resources
- Paper: Narrow and Deep: An Ontology Tower as the Knowledge of an LLM Agent for an Industrial Equipment System, preprint.
- Authors: Younghwan Joo, Sung-il Kim.
- Affiliations: Korea Institute of Energy Research; University of Science & Technology (Daejeon, Republic of Korea).
- Ontologies mentioned: Brick, SAREF, Asset Administration Shell, ISO 15926.
- Models used: Qwen3.5-9B, gemma-4-31B-it, EXAONE-4.5-33B, GLM-5.2.