Why Your Agents Suck (The Case for Ontology)

There has been much said over the last 6 months on how to provide AI with context. From the viral "trillion dollar opportunity" article (Ashu Garg & Jaya Gupta), to Karpathy's LLMGlossaryLarge language modelA large language model is a neural network trained on large text datasets to understand, summarize, and generate language. For large language model, the useful boundary is the data it uses, the tools it can call, the approvals it needs, the review standard, and the finance decision it may influence before the output is trusted or automated.Open full definition → Wiki, context is the topic du jour.

So what's all the fuss? Well, models got better, agents got more capable, and people saw the massive potential these technologies have to transform business forever.

But there's a catch. Without structure, context breaks down. And without context, intelligence doesn't scale.

The missing layer, the science of capturing the relationships between entities and how they behave in relation to each other, is called OntologyGlossaryOntologyOntology is a formal model of the concepts, entities, and relationships in a domain, including hierarchies and constraints that support inference, distinct from the analytic semantic layer. For ontology, a useful definition states a formal model of the concepts, entities, and relationships in a domain, including hierarchies and constraints that support, who owns it, and which decision it supports.Open full definition →.

What Ontology is

Ontology (also called "an ontology") is a structured framework that defines the concepts, relationships, and rules within a specific domain.

Applied to the enterprise, ontology is your business logic translated into a shared, machine-readable language. It clearly defines what entities exist, what they mean, and most importantly: how they connect.

You may think this just sounds like a schemaGlossaryDatabase schemaDatabase schema is the formal structure that defines how data is organized in a database, including tables, columns, data types, keys, and the relationships between them. For database schema, a useful definition states the formal structure that defines how data is organized in a database, including tables, columns, data types, keys, and the relationships between them, who owns it, and.Open full definition →, but there's an important difference.

Schemas define what objects exist and their data types, while an ontology explains the meaning behind those objects and how they relate to one another across the business.

It's also distinct from a data modelGlossaryData modelData model is an abstract representation of how data elements relate and are organized within a system, spanning conceptual, logical, and physical levels. For data model, a useful definition states an abstract representation of how data elements relate and are organized within a system, spanning conceptual, logical, and, who owns it, and which decision it supports.Open full definition → or operating model. Those models reflect how information is stored within specific systems, whereas an ontology reflects how the business actually works, independent of any particular implementation.

In theory, your business ontology should remain consistent no matter what tools you use, because the core entities (customers, contracts, products, etc.) transcend any single system.

The Building Blocks

Every ontology has 3 basic components:

• Entities
• Relationships
• Definitions

Your business can be represented as a network of entities and relationships (nodes and edges, in graph theory) where each node is a noun, and each edge is a verb.

The nodes (nouns) in this model represent entities, objects, or concepts that form the fundamental components of your business reality.

The edges (verbs) define actions, linkages, or transformations that connect these nouns, determining how they interact.

For example, in a simple ontology:

• A Customer makes a purchase
• A Purchase includes a product
• A Contract governs that purchase
• And Revenue is generated from that purchase

It's easy to see how an agent could traverse this map to get from one node to another, collecting context along the way.

The final building block, definitions, comes in to make sure that every interpretation of the ontology is consistent and unambiguous. Every company defines "Revenue" differently. Some use MRRGlossaryMonthly Recurring RevenueMonthly recurring revenue is the normalized monthly value of committed recurring subscription revenue, usually tracked by new, expansion, contraction, and churn movements. For monthly recurring revenue, the useful boundary is whether the movement comes from customers, contracts, billing, cash timing, or recognition rules.Open full definition → × 12. Some use Annual Run RateGlossaryRun rateRun rate is the practice of annualizing recent performance to estimate a full-year figure, and its limitations. For run rate, the useful boundary is whether the movement comes from customers, contracts, billing, cash timing, recognition rules, churn, expansion, pricing, or usage behavior.Open full definition →, etc. The definitions layer ensures everyone is operating from the same worldview so results are consistent.

Every ontology can be constructed from combinations of these basic building blocks.

Why Agents Need Ontology

AI agents don't struggle because they lack intelligence; they struggle because they lack context.

What most systems do today is force agents to rebuild that context every time by pulling from multiple tools, stitching together fragments of data, and making assumptions about how things connect. That approach works at small scale, but it breaks quickly. It's slow, fragile, and hard to extend.

Ontology changes the game. It gives agents a stable, shared understanding of how the business works, so they're not starting from scratch each time a question comes up. The relationships are already mapped. The meaning is already defined. The structure is already there, so instead of guessing, the agent can understand. Instead of reacting, it can reason.

Ontology in Practice

When an agent needs to understand a customer, the goal should not be to send it on a scavenger hunt across your CRM, billing system, support tickets, data warehouseGlossaryData warehouseData warehouse is a central, structured, schema-on-write store optimized for analytical queries and reporting across data consolidated from many source systems. For data warehouse, a useful definition states a central, structured, schema-on-write store optimized for analytical queries and reporting across data consolidated from many source systems, the source data, owner, timing, evidence, and decision it supports before teams rely on.Open full definition →, and a few stray spreadsheets.

That is how most companies work today. The information exists, but the meaning is scattered. One system knows who the customer is. Another knows what they bought. Another knows the contract terms. Another knows usage, payment history, support issues, expansion potential, and account health.

A human can usually piece this together because they know how the business works. They know that this Salesforce account maps to that billing profile, that the contract belongs to a specific entity, that revenue should be recognized in a certain way, and that one product line matters more than another for this customer.

An agent does not automatically know any of that. It needs business context to be made explicit.

With an ontology, the customer already exists as a resolved entity inside a knowledge graphGlossaryKnowledge graphKnowledge graph is a graph-based representation of real-world entities and the relationships between them, used to connect data across sources and support querying and reasoning. For knowledge graph, the useful boundary is the data, tools, approvals, human review, evaluation standard, and decision the system may influence.Open full definition →. The important connections are already mapped. The agent can see what the customer bought, which contract governs the purchase, how revenue flows from that contract, which products or services are involved, and how that customer relates to other parts of the business.

That means the agent is not just retrieving facts. It is operating inside a model of the business.

This is the difference between asking an agent to "go find the answer" and giving it a map of how the company actually works. One creates fragile workflows that break when data is incomplete or definitions change. The other creates a foundation where agents can reason with much more confidence.

What Ontology Enables

Once you have a well-defined ontology, everything changes.

1. True AI Reasoning: Agents can move beyond pattern matching and begin to reason about your business using structured relationships.
2. Real-Time, Multi-System Context: Instead of pulling from siloed tools, agents operate on a unified layer of meaning across systems.
3. Consistent Decision-Making: Because definitions are standardized, outputs don't vary depending on who (or what) is querying the system.
4. Scalable Intelligence: You don't need to re-engineer context for every workflow. The ontology becomes the foundation everything builds on.
5. Faster Time to Value: New agents, workflows, and use cases can be deployed faster because the underlying logic is already defined.

Final thoughts

Ontology isn't just a theoretical concept. It's the difference between a company that experiments with AI and one that can actually run on it. Right now, most organizations are layering agents on top of fragmented systems and hoping intelligence emerges from better models, and eventually produces ROI. It won't. Without a shared understanding of how the business works, every new agent adds complexity instead of leverage.

Ontology flips that dynamic. It gives you a single source of meaning, not just data. It aligns people, systems, and agents around the same structure, so decisions become faster, outputs become more consistent, and intelligence compounds over time instead of resetting with every query. As AI shifts from isolated tools to integrated systems, this stops being an infrastructure choice and becomes a strategic one.

It is my belief that the companies that get this right early will form a new standard for how businesses operate.

P.S. I'm Seb Fallenbuchl, a biomedical-mechanical engineer-turned-founder building in the agentic financeGlossaryAgentic financeAgentic finance is the practice of using autonomous AI agents to perceive, plan, and execute multi-step finance tasks with limited human intervention. For agentic finance, the useful boundary is the data, tools, approvals, human review, evaluation standard, and decision the system may influence.Open full definition → space. I spend most of my time unravelling the future of AI and what it means for your business. If this resonated, follow me for more on AI, ontology, and the future of how companies operate!

About the author

Seb Fallenbuchl

Chief Growth Officer

LinkedIn →