- An ontology has two halves. The nouns — object types, properties and links — describe what exists. The verbs — actions and functions — describe what can be done and how it is calculated.
- Agents do better with objects than tables because objects carry meaning and relationships. They do better with named actions than raw write access because actions carry checks, owners and approvals.
- For growth teams, a small ontology of campaigns, products, inventory, targets, alerts and staged actions covers most daily decisions.
“Ontology” is a word borrowed from philosophy, where it means the study of what exists. In software it has a narrower, practical meaning: a model of the things a business is made of, the ways they relate and, in operational systems, the actions that can change them.
For years the idea lived mostly in knowledge-management research and in large enterprise and defence software. It is now showing up wherever agents do: in data platforms, BI suites and sales tools. The reason is simple: an agent reasons about things — a campaign, a product, an order — and most data is stored as rows.
The building blocks
The clearest way to break an ontology down is into a semantic half and a kinetic half, which work like the nouns and verbs of a sentence.
| Element | What it is | Growth example |
|---|---|---|
| Object type | The schema for a real-world entity or event | Campaign, Product, Inventory position, Order |
| Property | A typed characteristic of an object | Campaign.daily_budget, Product.price, Inventory.units |
| Link type | A named relationship between two object types, traversable both ways | Campaign promotes Product; Product stocked as Inventory |
| Action type | A named change: a bundle of edits applied together, with checks and side effects | Change daily budget, pause ad, add negative keyword |
| Function | Server-side logic that reads objects and returns a result | Budget pacing projection, days of stock cover, fatigue score |
| Security | Rules for who can see and change which objects and properties | Media buyers see their accounts; margin hidden from agencies |
Good implementations bind each entity to the tables or event streams it comes from, so the model stays connected to live data. Relationships can carry attributes and cardinality — one campaign has many ad sets — and rules can fire when conditions on entities are met, such as stock cover falling below five days.
What a flat table loses
Most marketing data arrives as a wide table: one row per campaign per day, with columns for spend, clicks and conversions. It is a fine format for reporting and a poor one for decisions, for three reasons.
- Relationships disappear. The row does not say which products the campaign promotes, which listing it points to or whose budget it draws from. An agent has to guess or re-derive those joins every time.
- Meaning is implicit. Whether a “conversion” is a purchase, a lead or an add-to-cart, and on which attribution window, lives in someone’s head or a setup screen.
- There is nowhere to act. A table records what happened. It has no concept of “pause this” or “raise that”, let alone who may do so.
A useful way to think about it: most data architectures model data, while the systems that run a business should model decisions — the data involved, the logic used to weigh options, the action taken and the permissions around all three. The point for agents is practical. If decisions are first-class, an agent can see what was decided before, why and what happened next.
Actions: where agents meet the real world
Giving an agent write access to a platform API is the fastest way to let it make an expensive mistake. Ontologies offer a safer pattern: agents can only change the world through named action types. Each action defines which edits it makes, who may run it, which checks must pass and what happens in external systems.
The details matter. An action’s edits are applied together as one transaction. A writeback call to the external system runs first, and if it fails, nothing changes — the model never records a budget change the ad platform rejected. Notifications and other side effects run afterwards. It is also worth allowing edits only through actions, so the action becomes the single controlled door.
This structure also makes autonomy adjustable. A sensible default is that an agent may only stage actions for human sign-off, with specific, proven processes promoted to run on their own. Recommendations can go wherever the team already works — Slack, email or the app — for a person to approve or reject. Some actions deserve a hard line: anything that reaches a customer, or changes a client’s spend beyond an agreed limit, never runs unless a person started or approved it.
Functions keep arithmetic out of the model
Language models are unreliable calculators. Ask one for the nearest warehouse to a set of pin codes and it may give a confident wrong answer; give it a deterministic distance function as a tool and the answer is right every time.
Growth work is full of the same kind of calculation: projected month-end spend, days of stock cover at the current sell rate, the ROAS a campaign needs to break even, whether a creative’s click-through has decayed past a threshold. Put these in functions attached to the ontology. The agent decides which calculation matters and explains the result; the function does the maths the same way every time.
A starter ontology for growth teams
You do not need hundreds of types. Most daily growth decisions touch a small set.
| Layer | Start with |
|---|---|
| Objects | Brand or workspace, ad account, campaign, ad set, ad, creative, product/SKU, listing, inventory position, budget, target, order, lead |
| Links | Campaign → ad set → ad → creative; campaign promotes product; product listed on marketplace; product stocked as inventory; budget governs campaigns; target applies to campaign |
| Operational objects | Alert, recommendation, staged action, decision — so the work itself is modelled, not only the data |
| Actions | Change budget, pause or resume ad, add negative keyword, swap creative, pause promotion for out-of-stock SKU, acknowledge alert, approve or reject recommendation |
| Functions | Pacing projection, stock cover, break-even threshold, anomaly score, creative fatigue |
Give each action an approval tier. Adding a negative keyword or pausing promotion on an out-of-stock SKU is low risk and easy to reverse. Moving budget between campaigns is higher risk and should stay with a person for longer.
Common mistakes
- Modelling every column. An ontology is a model of decisions. If no decision uses a property, leave it in the warehouse.
- Skipping identity. If the same product has different IDs in Shopify, Meta and Amazon and they are not resolved, the links will be wrong in ways that are hard to notice.
- Actions without owners. Every action type needs someone accountable for its rules and its approval tier.
- Letting agents edit properties directly. Route every change through actions, even small ones, so every change is checked and logged.
- Not modelling decisions. Alerts, recommendations and approvals are objects too. Without them, the system cannot learn from what the team accepted or rejected.