Why agents need ontologies

Let’s start with an example. You’ve built a hypothetical agent that monitors transactions and can flag suspicious activity. You gave it access to your transaction database and customer records. It analyzes patterns, calls the right APIs, and flags high-risk transfers for review.

Three days later, compliance discovers the agent missed a $3M structuring scheme. The fraudster split transfers across seven accounts that share the same beneficial owner, keeping each transaction under the $20K reporting threshold. The agent saw the individual transactions but had no way to know the accounts were related. That relationship existed in KYC documents, a separate beneficial ownership table, and institutional knowledge, but nowhere the agent could query.

Prompt engineering wasn’t the root cause of this failure. Your agent did exactly what you asked. It analyzed transactions and flagged high-risk transactions. The problem is that your system can’t tell the agent what relationships exist, especially at multiple steps removed from the action. It can only show it what data exists.

Agents need ontologies as essential infrastructure for operating safely in production, to give them greater levels of context. As these agents deal with higher levels of complexity, we need to provide more and more efficient ways for them to absorb and relate information, and parse it accurately.

What breaks without a rich ontology

Agents that deal with complexity fail in predictable ways when they lack semantic grounding:

They create invalid states. Agents book shipments before an order is approved, schedules meetings with people who don’t have access to the room, or assign tasks to people who left the company previously. The API calls succeed, and the database accepts the data, but the result violates domain rules that exist outside the system’s enforcement layer.

They can’t explain decisions. You ask an agent why it recommended Supplier A over Supplier B, but it can’t tell you. The reasoning involved relationships between suppliers, certifications, past performance, and current capacity, but those relationships aren’t structured knowledge the agent can reference. It can only say “based on the data I retrieved.” We’re already seeing huge investment into tooling and companies that can help understand why an AI chose to take an action.

They can’t validate their own actions. Before executing an operation, an agent needs to know: Is this allowed? Are the preconditions met? What are the consequences? Without an ontology, it can’t answer these questions. It can only try the operation and see if it fails.

They make assumptions about concepts. Your sales system calls them “customers,” your billing system calls them “accounts,” and your support system calls them “users.” An agent treating these as the same thing will make mistakes. An agent treating them as different things will miss connections. Without an explicit ontology defining the relationships, the agent has no ground truth to model the reality.

Why RAG isn’t enough

If you’re building agents with retrieval-augmented generation (RAG), you’ve already discovered its limits. RAG helps agents find and retrieve relevant information, but it doesn’t solve the validation problem.

When your agent retrieves a document explaining supplier approval policies, it still can’t query “is this specific supplier approved for this specific product category?” RAG gives it text to reason over without any deep structure to explore.

Knowledge graphs get closer; You can store entities and relationships, and agents can query them, but classical property graphs model connections, not core semantics. A knowledge graph might store that Supplier A connects to Category B with a “approved_for” edge, yet it can’t enforce that every procurement must connect to an approved supplier. It can’t express that approval relationships are only valid if the supplier status is “active” and certification hasn’t expired.

The real difference comes from a level of ontological enforcement. In a knowledge graph, you write application code that validates these rules.

In TypeDB, the rules are part of the type system where invalid states can’t be created and functions derive new facts from existing relationships. The ontology is queryable infrastructure, not data you validate against in code.

An agent querying a knowledge graph still needs hardcoded logic to validate its actions. An agent querying TypeDB asks ontological questions and gets answers the database enforces. This makes a fundamental difference for how an agent can operate under complex conditions and systems.

What do agents need?

Beyond retrieval and generation, agents performing operations need to query semantic structure. They need to ask:

• What types of entities exist in this domain?
• What relationships are valid between them?
• What constraints apply to this operation?
• Why is this state invalid?
• What rules govern this decision?

These example queries would be highly relevant, and relate directly to the domain structure. Having an agent assemble those to interrogate table records is expensive and can be very difficult. That structure that allows an agent to readily understand these up-front comes from the ontology.

For an agent to operate safely, the ontology must be:

• Explicit. The agent needs to query it directly rather than forming the concept implicitly in code or documentation.
• Queryable. The agent needs to ask questions and get answers without leaning on diagrams or external docs.
• Enforceable. Invalid states must be impossible to create at the foundation level.
• Introspectable. The agent needs to discover what concepts exist, how they relate, and what operations are valid.

Most databases provide none of these capabilities. They store data and enforce basic constraints, but they don’t represent the semantic structure of your domain in a way agents can use.

The TypeDB difference

TypeDB is built to provide agents with queryable ontologies. The type system is the ontology, and agents can query both the data and the structure that gives it meaning.

Here’s what this looks like in practice. Suppose you’re building an agent that handles fraud detection. In a traditional setup, you might have tables for accounts, transactions, and customers:

CREATE TABLE accounts (
    account_id INT,
    customer_id INT,
    status VARCHAR(20),
    account_type VARCHAR(50)
);

CREATE TABLE transactions (
    transaction_id INT,
    from_account_id INT,
    to_account_id INT,
    amount DECIMAL,
    timestamp DATETIME
);

CREATE TABLE flagged_patterns (
    pattern_id INT,
    account_id INT,
    pattern_type VARCHAR(50),
    risk_score DECIMAL
);

Your agent can query these tables, but it can’t ask “is this transaction suspicious given the relationships between these accounts?” That logic lives in application code, and the agent has no access to it. The agent would need to retrieve account ownership, check for shared devices or addresses, analyze transaction velocity, compare against regulatory thresholds, all with hard-coded logic you’ve given it.

When fraud patterns evolve or regulatory thresholds change, you update the application code. The agent doesn’t see the change unless you also update its instructions.

In TypeDB, you model the domain:

define

entity account,
    owns account-number,
    owns account-type,
    owns status,
    plays ownership:owned-account,
    plays transaction:source-account,
    plays transaction:destination-account,
    plays transaction-beneficiary:beneficiary,
    plays linked-accounts:linked,
    plays device-linked-accounts:linked-account;

entity customer,
    owns customer-id,
    owns customer-name,
    plays ownership:owner;

entity device,
    owns device-fingerprint,
    plays device-linked-accounts:linking-device;

relation ownership,
    relates owner,
    relates owned-account,
    owns ownership-type;

relation transaction,
    relates source-account,
    relates destination-account,
    owns amount,
    owns timestamp,
    owns transaction-type,
    plays transaction-beneficiary:transaction;

relation transaction-beneficiary,
    relates transaction,
    relates beneficary;

relation linked-accounts,
    relates linked @card(0..),
    owns first-seen,
    owns confidence-score;

relation device-linked-accounts,
    relates linked-account as linked @card(0..),
    relates linking-device;

Now the agent can query the ontology:

match
$account isa account, has account-number "ACC-7834";
$customer isa customer, has customer-name "John Smith";
ownership ($account, $customer);

# Find other accounts owned by same customer
ownership ($other-account, $customer);
not { $other-account is $account; };

# Check for shared devices
device-linked-accounts ($account, $device);
device-linked-accounts ($other-account, $device);

fetch {
  $other-account.*
};

This query asks: “What other accounts does this customer own, and do any share device fingerprints with this account?” The ontology answers. If hidden relationships exist, the agent discovers them. If they don’t, the account appears isolated.

More importantly, the agent can discover the rules:

match
$account isa account, has account-number "ACC-7834";
device-linked-accounts ($account, $device);
$device has device-fingerprint $fingerprint;
device-linked-accounts ($linked-account, $device);
not { $linked-accounts is $account; };
$linked-account has account-number $linked-num;
fetch {
  "number": $linked-num, 
  "fingerprint": $fingerprint
};

“What other accounts are linked to this account through shared devices?” The agent gets a direct answer from the ontology, not from parsing fraud rules documentation or trying queries to see what patterns emerge.

Reasoning through functions

TypeDB 3.x introduces functions that let you encode domain logic in the database:

fun is-structuring($account: account, $start: datetime, $end: datetime) -> bool:
  match
    $txn isa transaction ($account);

    # transaction under threshold
    $txn has amount $amt;
    $amt < 10000;  

    # Within timeframe
    $txn has timestamp $time;
    $time > $start;
    $time < $end;

  reduce $total = sum($amt);
  
  match
    # Aggregate exceeds threshold
    $total > 10000;
  
  return check;

This function encodes the regulatory definition of structuring: “Multiple transactions intentionally broken into smaller amounts to evade reporting thresholds.”

An agent queries this function when analyzing transaction patterns:

match
$account isa account, has account-number "ACC-7834";
let $start = 2026-01-18T00:00:00;
let $end = 2026-01-19T00:00:00;
is-structuring($account, $start, $end);

If the function returns results, the pattern is suspicious and requires investigation. If not, the agent knows the transaction volume, while high, doesn’t constitute structuring. The regulatory logic lives in the ontology, not in the agent’s prompt or in scattered application code.

When regulations change – say, the threshold is lowered or the timeframe definition is expanded – you update the function:

fun beneficiary-count($txn: transaction) -> { integer }:
  match 
    transaction-beneficiary ($txn, beneficiary: $beneficiary);
  distinct;
  return $count = count($beneficiary);

fun is-structuring($account: account, $start: datetime, $end: datetime) -> bool:
  match
    $txn isa transaction ($account);

    # transaction under threshold
    $txn has amount $amt;
    $amt < 10000;  

    # Within timeframe
    $txn has timestamp $time;
    $time > $start;
    $time < $end;

    # ***New requirement: multiple distinct beneficiaries***
    beneficiary-count($txn) >= 3;

  reduce $total = sum($amt);
  
  match
    # Aggregate exceeds threshold
    $total > 10000;
  
  return check;

Every agent querying this function immediately operates under the new rule. You don’t update prompts or redeploy services. The ontology changed, and behavior follows.

Validation as structure

TypeDB enforces ontological constraints at the schema level. When you define that a transaction relation requires both a source-account and a destination-account, the database won’t accept a transaction without both.

define

relation transaction,
    relates source-account,
    relates destination-account,
    owns amount,
    owns timestamp;

An agent trying to create an invalid transaction gets a type error, not a runtime exception. The constraint is structural. Invalid operations are inexpressible.

This matters when multiple agents operate in the same system. They all face the same ontological boundaries. An agent can’t accidentally create fraudulent-looking patterns by recording incomplete transaction data, because incomplete transactions can’t be created.

How to explain agent decisions

Start with the capability you want: explainable decisions. Then work backwards to what that requires.

When an agent makes a decision based on ontology queries, the reasoning is explicit. You can trace exactly what relationships and rules led to the decision.

An agent flags a customer for suspicious activity. You ask why. The agent can show:

1. Query: Which accounts does this customer own?
2. Result: ACC-7834, ACC-9102, ACC-4421
3. Query: Do these accounts share device fingerprints?
4. Result: All three accessed from device FP-8472ABC
5. Query: What’s the combined transaction volume in the last 24 hours?
6. Result: $14,200 across 8 transactions
7. Query: Does this exceed the SAR filing threshold?
8. Result: Yes, threshold is $10,000

The reasoning chain is queryable. You can audit it. You can verify each step against the current ontology. The decision isn’t a black box—it’s a series of ontological queries that anyone can reproduce.

This is what regulatory compliance and operational safety require. Not “the model flagged it,” but “here’s the relationships it discovered, here’s the regulatory threshold it applied, here’s why this pattern requires investigation.”

Effective multi-agent coordination

Consider a financial institution with three specialized fraud detection agents: a transaction monitoring agent that analyzes real-time payment flows and flags suspicious patterns, an entity resolution agent that discovers hidden relationships between accounts and beneficial owners, and an investigation agent that builds fraud cases and determines when to file Suspicious Activity Reports.

These agents need to coordinate continuously. When should the monitoring agent escalate a transaction? That depends on account relationships (entity resolution agent), historical patterns (monitoring agent), and regulatory thresholds (investigation agent). If they coordinate through messages, they’re constantly at risk of acting on stale information or missing connections.

With a shared ontology in TypeDB, coordination happens through queries rather than messages.

The transaction monitoring agent queries whether a transfer pattern is suspicious:

match
$account isa account, has account-number "ACC-7834";
ownership ($account, $owner);
$owner isa customer, has customer-name $name;

# Find all accounts with same owner name
$related-account isa account;
ownership ($related-account, $related-owner);
$related owner isa customer, has customer-name $name;

# Get transactions between accounts in last 24 hours
$txn isa transaction ($account, $related-account);
$txn has timestamp $time;
$txn has amount $amt;
$time > 2026-01-18T00:00:00;
$time < 2026-01-19T00:00:00;

reduce $total = sum($amt);

match
# Check against SAR threshold (note: example not in schema)
$threshold isa regulatory-threshold, 
    has threshold-type "SAR-filing",
    has amount-limit $limit;
$total > $limit;

“Do related accounts exceed the SAR filing threshold in the last 24 hours?” The entity resolution agent uses similar queries to discover ownership networks. The investigation agent queries to determine if this pattern constitutes structuring behavior.

When the entity resolution agent discovers a connection, it can create a relationship in the ontology:

insert
$account1 isa account, has account-number "ACC-7834";
$account2 isa account, has account-number "ACC-9102";
linked-accounts (linked: $account1, linked: $account2),
    has first-seen 2026-01-15T08:23:00,
    has confidence-score 0.94;

The transaction monitoring agent sees this link immediately when analyzing patterns. The investigation agent sees it when building fraud cases and determining whether transactions across accounts constitute a coordinated scheme. No messages needed. The ontology maintains consistency across all agents.

This is multi-agent coordination through shared semantic infrastructure rather than message passing. When regulatory rules change—say, the SAR threshold is lowered or new structuring patterns are defined—you update the ontology and all agents see the new constraints.

When agents don’t need ontologies

Not every agent needs this infrastructure. Sometimes, it is overkill to develop, when you only need something much more lightweight. For example:

Assistants that only read and summarize, they don’t need ontologies. They need good retrieval and generation. A documentation chatbot doesn’t need to validate operations or enforce constraints.

Agents in simple, stable domains, they might not need explicit ontologies. If your domain has five entity types and straightforward relationships that never change, the overhead of ontological modeling isn’t worth it.

Single-purpose agents with narrow scope, they might have all the rules they need encoded in their prompts. An agent that only checks expense policy might not need a full ontology—though even here, encoding rules in the database is more maintainable than hardcoding them in prompts.

Ontologies become necessary when:

• Agents perform operations that can create invalid states
• Multiple agents need shared understanding
• Domain rules are complex and change over time
• Decisions need to be explainable and auditable
• The cost of agent errors is high

For agents operating in enterprise domains—procurement, compliance, healthcare, supply chain, financial services—ontologies aren’t optional. They’re the infrastructure that makes agents safe to deploy.

The architecture pattern

The ontology layer sits between your existing data stores and your agents. It’s not replacing your databases—it’s providing the semantic structure that makes them comprehensible to agents.

Your relational databases, document stores, and APIs continue to handle transactions and storage. TypeDB holds the ontology and derives facts from the current state. Agents query TypeDB to understand what operations are valid, what relationships exist, and what rules apply. When they need transactional data, they query the underlying systems.

This is adoptable incrementally. You don’t rewrite your entire system. You model your core domain in TypeDB, give agents access to it, and let them query both the ontology and existing data sources. Over time, more domain logic moves into the ontology layer as you see the value.

What Changes in 2026

Organizations are moving from experimenting with agents to deploying them in production, which creates meaningful new requirements around compliance and safety. Agents that answer questions can work with RAG and vector search. Agents that perform operations – creating records, approving transactions, scheduling resources – need semantic validation.

The first production deployments reveal what doesn’t work. Prompt engineering doesn’t prevent agents from creating invalid data. RAG doesn’t help agents validate their actions. Knowledge graphs provide structure but don’t enforce ontological constraints.

The solution is purpose-built infrastructure: databases designed for agents to query semantic structure. TypeDB represents a strong approach for provide this. Organizations deploying operational agents are building on ontology layers because that’s what makes agents safe to run in production.

Getting started with ontology layers

If you’re deploying agents that perform operations rather than just answering questions, you need an ontology layer. Here’s how to get started with TypeDB:

1. Identify your agent’s domain. What entities does it work with? What relationships matter? What rules govern valid operations? Start small—model the core concepts your agent needs to understand.

2. Model the ontology in TypeDB. Define entities, relations, and the constraints between them. Express business rules as functions. This becomes your agent’s semantic API.

3. Give your agent ontology access. Let it query the schema to discover what concepts exist. Let it query functions to validate operations before executing them. Let it trace relationships to explain its decisions.

4. Deploy with validation. Your agent queries the ontology before performing operations. Invalid actions get caught at the semantic level, not after they’ve corrupted data.

5. Evolve the ontology as rules change. When business requirements shift, you update the ontology. Agents querying it immediately operate under new rules without redeployment.

You don’t need to model your entire enterprise from the beginning. Start with something simple. Maybe one agent, one domain, one set of critical operations. Prove that ontological validation prevents the errors you’re currently seeing and improves overall efficiency. Then expand it over time.

The ontology layer is infrastructure for functional operational agents. If your agents create data, approve transactions, schedule resources, or coordinate with other agents, this is the architecture that makes them safe to deploy.