From Conversation to Workflow - How We Use Ontology
Anyone who has tried assigning work to an AI agent hits the same wall.
The first time, it does an amazing job. The second time mostly works too. But by the tenth time, when you are still giving the same explanation, the frustration starts to build.
Explaining over and over which column in the product table means what, what duplicates are judged by, and which fields must always be filled in during research - it gets exhausting.
It is not because the agent is dumb. It is because nothing you agreed on about that work is stored anywhere. It arrives with each conversation and disappears along with it.
We decided not to solve this by "making the agent smarter." Instead, we made the nouns and relationships that appear in the work the core of the product. That is the ontology layer.
Scattered Concepts
Since last year we have been putting real client work onto our agents - managing product databases, producing proposals to send to partners, managing ad performance, and executing new strategies. It ran well. But when we took apart how it ran well, this is what we found.
A single concept, "product," was scattered across at least five places: in the prose of prompts written separately for each function, and in the database tables the agent made up as it went.
The consequences show up at execution time. The agent gropes around the database, fails, exhausts its retries, and only then comes to a human saying "confirmation required." When the human picks it up, it isn't a matter that needs judgment - it's just one missing value.
There was nothing wrong with the agent technology itself. What was missing were nouns and relationships.
Functions Are Actions Applied to Objects
"Ontology" sounds grand, but what we introduced is two of these three things.
- Objects: the things that appear in this work. Products, proposals, detail pages.
- Links: the relationships between them. The detail page of this product, the proposals that went out for this product.
- Actions: the operations applied to objects.
The third one, actions, was already mature. Tools, risk assessment, human approval, and audit records were all attached to that axis. So we did not create a new action entity. We only added one more field to the existing function definition: "applied to what?"
Functions are actions applied to objects.
That single sentence is the starting point of the design. Instead of building a new concept, we gave the existing one an object.
There Is No "Product" in the Code
A client's object definition looks like this.
Product
Attributes: product name*, brand, category, supply price, sale price, origin, specification, research status
Duplicate key: (brand, product name)
Constraints: sale price >= supply price, supply price > 0
Product → Detail page (One. Regenerating replaces it)
Product → Proposal (Many. Accumulates separately per partner)
What matters is that all of these names are data. No matter how hard you dig through our codebase, neither product nor proposal appears. They must not. The moment they do, that client is baked into the code, and the second client cannot be onboarded without a code change.
Setting up this one definition brought several things along at once. The single-product registration form is derived from the definition, duplicate judgment comes down deterministically, constraint violations are caught before execution, and outputs are attributed to their target. "What is the current detail page of this product?" finally becomes a question you can ask.
The position of rejection changed too.
Before: Execute → agent gropes around → fails → exhausts retries → rejects → human checks
After: Validate at intake → if it fails, the agent self-corrects from the tool error → reject only if it still fails
The human's screen is left with only the cases that genuinely need human judgment.
The Promotion Ladder
Here is the real argument of the product. Ontology itself is not the differentiator. That good concept definitions help is not a new claim, and who writes those definitions is not the essence either.
The axis we look at is speed. Work with an agent climbs the four steps below.
| Step | State | What this step is like |
|---|---|---|
| 1 | Conversation | Exploratory and non-deterministic. It goes differently every time |
| 2 | Approved schema | Agreement on what is what. Changes are kept as records |
| 3 | Contracted action | Validation at intake, safe on repeated execution, auditable |
| 4 | Compiled workflow | A path that runs without LLM calls. Predictable and cheap |
Every piece of work starts at step 1. Some work can stay at step 1 forever - research that differs every time, judgment that differs every time, belongs there. But when repeating work stays at step 1, the user gives the same explanation every month and we pay the LLM bill every time.
The differentiator is not "who builds the ontology" but "how fast it gets promoted into a fixed workflow." What the customer buys is the result - predictable, reversible automation - and promotion speed is our cost of producing that result.
To be honest about it: it does not yet cover every case perfectly, and we are still improving. What we have right now is a completed step 3, and one narrow path that partly shows the properties of step 4. When we can show a case that has climbed the whole ladder, we will write again, with numbers.
The Same Ladder for Individual Users
The place this layer was first built was the portal for enterprise clients. But from the start we built it as general technology, not as one client's workflow. An individual user's agent uses the same store, the same tools, and the same duplicate-judgment rules.
What differs are the parts you climb with. On the enterprise track the approver at step 2 is an engineer on our side; on the individual track it is the user themselves. So we set three principles.
The first run is the discovery. We scrapped the model of "do the same thing three times and we'll suggest it a few days later." The trigger is not frequency but shape. If data that can be structured and a repeatable action both appear within a single turn, we make the suggestion on that turn. The path where the user simply says "make this happen every time" is open as well.
Locking it in takes a single card. We don't ask for schema approval and action approval separately. Ask twice, and you'll be turned down twice.
The duplicate-judgment rule is soft at first. No user can answer "what is the unique key of this table?" correctly in the first conversation. So we leave the rule changeable while there is little data, and lock it once data accumulates. We accepted into the design the fact that a perfect definition cannot be extracted in a short time.
And underneath all of it lies one more thing. Approval is light only when it is reversible. Most of the friction in approval comes from "what if I press this and something goes wrong?"
One Strong Conviction
We are certain of exactly one thing. When scattered concepts are tied together into a fixed workflow, AI finally moves past being a "neat toy" and becomes a "dependable professional."
We will keep climbing this promotion ladder, all the way to the top.