You Gave the Agent Tools. You Never Gave It Your Domain Model.
Most Australian enterprises handed agents a toolkit first and a domain model never. The chatbot can raise a ticket. The claims assistant can fetch a policy. The payments bot can draft a refund. What none of them received is a shared, formal picture of what a customer, a claim, a payment, or a case is in your organisation, and what relationships are allowed to exist between them.
That gap is not a documentation nicety. Agents are probabilistic systems. They invent plausible next tokens for a living. Hallucinations are not only bugs; they are a predictable side effect of how next-token prediction works. Without a structured domain model sitting between the loop and your systems of record, the agent will fill gaps with fluent guesses. Sometimes those guesses look fine. Sometimes they quietly mutate the ledger.
The missing piece is an ontology: a formal shared conceptualisation of a domain. Put simply, it is the entities you care about, the relationships between them, and the properties and constraints that keep those relationships honest. Often it lives as a knowledge graph. Increasingly, production teams pair it with neural agents in what people call neuro-symbolic AI: probabilistic reasoning where it shines, symbolic structure where drift would hurt.
Large language models are extraordinary at language, summarisation, and soft reasoning over messy text. They are also unbound by your enterprise rules unless you put those rules somewhere they cannot shrug off. An agent that can call tools is powerful precisely because it can close the loop: read state, decide, write state, read again. That loop is also where things break.
Loops drift between agents when each one carries a slightly different idea of what a "case" or a "payer" means. They burn tokens chasing dead ends. They retry side effects. They invent statuses that your CRM has never heard of. The failure mode is rarely a single catastrophic hallucination. It is a slow smear of almost-right mutations across systems that were never designed for conversational write paths.
Symbolic structure does not replace the model. It constrains it. Rules, graphs, and OWL or RDFS-style constraints give you a place to say: this type is disjoint from that type; this property is functional; this status may only be one of these values; this relationship is transitive. Free text cannot carry those guarantees. Typed contracts at the tool boundary can.
Enterprise domains evolve. Product lines merge. Case types sprout subtypes. A payment that once always had one payer now sometimes has two. Rigid relational tables struggle when the shape of the world keeps moving, because every new relationship tends to mean a migration, a nullable column, or another join table nobody owns.
Graphs cope better with that kind of change. You add nodes and edges for the new concepts without pretending the old schema was complete. You can still enforce constraints. You just stop pretending that yesterday's columns are the whole domain.
An ontology is the agreement layer on top of that graph. It answers questions your warehouse never did:
Those are not academic questions. They are the difference between an agent that updates the right record and an agent that invents a plausible sibling record because nothing told it the first one was unique.
Building a domain model is not a choice between ivory-tower design and chaotic discovery. Healthy programmes use both directions.
Domain experts name the entities that matter: account, policy, claim, payment instruction, case, agent of record. They define the relationships that must hold even when the UI is messy. This is where disjoint types and functional properties earn their keep. A customer is not a support rep. A claim has one primary policy. A refund has one payer of record unless your business has explicitly modelled otherwise.
Real work always surfaces concepts the workshop missed. Exception queues, shadow statuses, "temporary" fields that staff rely on. Bottom-up modelling adds those entities and relationships from observed operations, then folds them into the shared conceptualisation instead of leaving them as tribal knowledge in spreadsheets.
You do not need to invent every vocabulary from scratch. Public schema patterns for organisations, people, offers, and events are useful starting points when they map cleanly. Reuse the shape of thinking, not necessarily a product badge. The point is shared meaning across teams and tools, not brand loyalty to a particular ontology stack.
When agents propose tool calls, the dangerous mistakes are often structural, not stylistic. Inference and constraints catch them before anything lands in a system of record.
These checks are dull in the best way. Dull is what you want between a probabilistic loop and a money movement.
Agent loops become survivable when you refuse to mutate systems until validation passes. A practical pattern looks like this.
Every tool the agent may call exposes a typed input and output contract. Not "a blob of JSON the model invented", but a schema the runtime can reject. Argument names, enums, identifiers, and required fields are explicit. If the model proposes a status that is not in the enum, the call never leaves the sandbox.
Before any write, a validation layer checks the proposed mutation against the ontology and against the current ledger state. Does this party exist? Is this relationship allowed? Would this update violate a functional property? Is the transition legal? Only then does the runtime execute the side effect. Reads can be generous. Writes stay strict.
When checks fail, the loop should not invent a workaround. It should escalate: surface the proposed action, the failed constraint, and enough context for a human to decide. That is not a defeat for automation. It is how you keep automation honest when the world is weirder than the graph.
This pattern also helps with token burn. Agents that thrash against soft failures burn budget. Agents that hit a hard validation wall early stop, escalate, or replan with clearer feedback.
None of the following are client stories. They are illustrations of where domain models and guardrails change the risk profile.
Imagine a retail bank assistant that can draft refunds for disputed card transactions. Without a domain model, the agent might invent a second payer, reuse an outdated account identifier, or mark a refund complete before clearing checks finish. With an ontology, a refund instruction has one primary payer, a linked dispute case, and a status enum that refuses "paid" until validation and clearing flags agree. The tool contract rejects malformed payloads. The ledger check refuses the write. A human sees the failed constraint instead of a polite email that already went out.
An insurer pilot lets an agent triage incoming claims into queues and request missing documents. Probabilistic classification is useful here. Unconstrained writebacks are not. Disjoint types keep a claimant distinct from an assessor. Allowed transitions stop a claim jumping from intake to settlement. Document requests reference real claim entities, not hallucinated claim numbers that look right in chat and wrong in the core system.
A public-sector style agency routes citizen cases across programmes. Agents that summarise and suggest next steps can save staff time. Agents that reassign ownership without hierarchical and jurisdictional constraints can create privacy and fairness problems. Transitive reporting and programme-membership relationships encoded in the ontology give the runtime something firm to check before a reassignment tool fires.
Skipping the ontology usually feels fast in week one. By week six the symptoms are familiar:
None of that is fixed by a longer system prompt. Prompts are soft. Ontologies and typed contracts are hard in the places that matter.
TruFyre works with Australian and APAC organisations that want agent capability without ledger roulette. The work is rarely "add another model". It is putting domain models and guardrails around agent tools so loops stay honest: shared entities and relationships, constraints that fire before side effects, typed contracts at the boundary, and clear human escalation when validation fails.
If your agents already have tools, ask a sharper question. Do they also have your domain model? If the answer is a shrug, the next incident will teach you the difference.
Ready to put structure under the loop? Talk to TruFyre about ontology-backed guardrails for enterprise agents in Australia and the wider APAC region.
