📅 Book a 30-min Demo📞 Call/text (571) 293-0242
Agentic Ontology

The knowledge layer your agents reason over

The knowledge layer a bank's or insurer's AI agents reason over: accounts, transactions, alerts and loans from core banking, the policy system and the warehouse, queryable in place over MCP with every access logged. On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network. No need to choose build vs. buy — you get both.

Higher EducationCorporateSmall BusinessK-12GovernmentLegalFinancial ServicesHealthcare
1.6M+Platform Users
400+Organizations
Syracuse UniversitySUNYGoogleNVIDIAMicrosoftOpenAIKaplan

“ibl.ai does amazing work and are great people.”

Paul LeBlanc, former President and CEO, Southern New Hampshire University
Don’t take our word for it?See what our partners say →
Want to read the source?View the code on GitHub →
We host itStart at $0 on the ibl.ai cloudFree tier with renewable monthly credits, no credit card, usage-based from there. Move to your own infrastructure anytime, nothing to rebuild.Hosted deploymentSee pricing
You own itTake the whole codebaseBackend and infrastructure under a perpetual license, so you own all the code and the data. Your cloud, on-premise or air-gapped, under your control.Full code license
Available on

What makes it agentic

Not a data warehouse and not a RAG index. A map of your organization's nouns and verbs that agents reason over, built on the systems you already run, queried in place over MCP — with the data, the cache and the permissions staying inside your network.

No data extractionDatabases and SaaS apps are exposed as MCP tools where they live; the layer is itself one MCP server behind your firewall and identity provider. No VPN to a vendor cloud, no third party holding your data.MIT · github.com/iblai/ontologyNouns and verbs, not tablesEntity types, attributes and relationships for what exists; actions, functions and permissions for what can happen. Agents read the same reality your people do, in the terms they already use.Semantic + operational layersEvery agent compoundsModel an entity once and every agent inherits it, with the user's own role enforced on every query. This is the layer an AI Transformation engagement delivers first.Delivered by AI Transformation

How is Agentic Ontology different from a managed vendor's knowledge layer?

Managed AI vendors extract your data through a VPN into their cloud and rent you access to a map of your own organization. Agentic Ontology keeps the map in your network, open source, and yours.

Where the data goesAgentic OntologyStays in your network, queried in place over MCP.A managed knowledge layerExtracted into the vendor's cloud.
Who holds the mapAgentic OntologyYou do: open source (MIT), self-hosted.A managed knowledge layerThe vendor; you rent access.
IdentityAgentic OntologyYour identity provider, the user's own role on every request.A managed knowledge layerThe vendor's accounts and service keys.
Models and runtimesAgentic OntologyAny LLM, any authorized MCP client; switch anytime.A managed knowledge layerThe vendor's models.
PricingAgentic OntologyUsage or a flat license; no per-seat or per-connector fee.A managed knowledge layerPer seat, per connector, per year.
ExitAgentic OntologyThe layer keeps running after the contract.A managed knowledge layerThe map leaves with the vendor.
Your Code. Your Data.Full ownership, zero vendor lock-in
Any LLM, Your ChoiceAir-gapped or any cloud provider’s
85% Lower CostSignificantly cheaper at scale
Engineers IncludedOur team builds it with yours

MCP Architecture Guide for Financial Services

How to connect your financial systems (core banking, CRM, compliance, trading) to AI agents — with regulatory compliance.

Read the Guide
Models & Runtimes — any model, any agent runtime
Google GeminiMicrosoft CopilotAmazon BedrockOpenAI GPTAnthropic ClaudeOpenClawNemoClaw
Services
AI TransformationAir-Gapped AIStudio Production

How does the ontology fit between your systems and your agents?

Your systems of record stay where they are. The ontology models them as nouns and verbs, exposes the result as one MCP server behind your firewall, and every authorized agent runtime reasons over it with the user's own role.

The Concept

What Is an Organizational Ontology?

A structured representation of your organization that AI agents can reason over

The Semantic Layer

The nouns — what exists in your world

  • → Entity types model real-world things — students, courses, departments, equipment
  • → Attributes capture characteristics — enrollment date, grade level, capacity
  • → Relationships define how entities connect — a student enrolls in a course, a course belongs to a department

The Operational Layer

The verbs — what can happen in your world

  • → Actions define permissible changes — enroll a student, update a grade, approve a request
  • → Functions encode logic — calculate GPA, assess risk scores, route approvals
  • → Permissions govern who can do what — role-based access at every level
Together, these layers form a digital twin of your organization — a complete, navigable map that AI agents use to understand context, make decisions, and take action
The ontology becomes the single source of truth for every agent
The Why

Why Build an Ontology?

Five principles that make ontology-driven AI fundamentally different

1

Shared understanding at scale

  • Every team, department, and agent operates from the same definitions — no conflicting spreadsheets, no siloed dashboards
  • New data sources are modeled into a common language rather than spawning another disconnected view
  • Local decisions gain global context — a department head sees how their choices affect the wider organization
2

Human-readable by design

  • Users interact with familiar terms — students, courses, advisors — not tables, joins, or API endpoints
  • The ontology bridges technical and non-technical teams, eliminating weeks of data reconciliation
  • Domain experts can explore data directly without writing queries or waiting on engineering
3

Build once, reuse everywhere

  • A well-modeled entity type serves every downstream application — dashboards, agents, reports, and integrations
  • New use cases plug into the existing ontology instead of requiring fresh data pipelines
  • The cost of launching the tenth agent is a fraction of launching the first
4

Capture decisions as data

  • Every action taken through the ontology — an approval, a classification, an override — is recorded and available
  • One user's insight becomes another user's input, compounding the value of the knowledge graph over time
  • Audit trails and decision history are built in, not bolted on
5

Ground AI in organizational reality

  • Models and agents operate on the same structured knowledge that humans use — no translation layer needed
  • Predictions, classifications, and recommendations tie directly to the entities and relationships users already understand
  • As agents act and users respond, operational data flows back — creating a feedback loop for continuous improvement
Philosophy established — now define the building blocks
Building Blocks

Core Ontology Types

The fundamental primitives that model your organization

Entity Types

Schema definitions of real-world objects or events. Each entity type has instances — an "Employee" type contains individual employees, a "Course" type contains individual courses.

e.g. Student, Course, Department, Device, Transaction

Attributes

Characteristics that describe an entity. An attribute type defines the shape (text, number, date, location); an attribute value is the data on a specific instance.

e.g. Name, enrollment date, capacity, GPA, location

Relationships

Typed connections between entities that carry meaning. Relationships can be one-to-one, one-to-many, or many-to-many, and can link entities of the same type.

e.g. Student enrolls in Course, Manager supervises Employee

Actions

Controlled operations that create, modify, or remove entities and relationships in a single transaction. Actions enforce validation rules and trigger side effects like notifications.

e.g. Enroll student, approve request, update record

Core types defined — add advanced modeling capabilities
Advanced Modeling

Extending the Ontology

Powerful abstractions for complex organizational models

Interfaces

Abstract shapes that multiple entity types can implement. A "Facility" interface with name and location attributes can be shared by airports, warehouses, and offices — letting agents work with all of them uniformly without knowing the specific type.

Functions

Code-based logic that reads entity attributes, traverses relationships, and returns computed results. Functions power derived metrics, complex validations, model inference, and any server-side computation agents need at decision time.

Derived Attributes

Values calculated at runtime by traversing relationships and aggregating data. A department's average satisfaction score, a student's total credits, or a device's most recent inspection — all computed live from the graph without storing redundant data.

Structured Attributes

Composite attributes that group related fields into a single property. An address with street, city, and postal code, or a name with first and last components — keeping related data together while preserving field-level access.

Semantic Search

AI-powered search that converts text into vector embeddings and matches by meaning rather than keywords. Agents can find relevant entities even when queries don't match exact field values — essential for natural language workflows.

Rich model in place — agents can now operate on structured knowledge
Governance

Permissions & Security

Granular control over who sees what and who can change what

Schema Permissions

Control access to type definitions

  • → Who can view or modify entity type definitions
  • → Who can create new relationship types
  • → Who can define or edit action types

Data Permissions

Control access to individual records

  • → Who can read specific entity instances
  • → Who can execute actions on which entities
  • → Row-level and field-level security for sensitive data
Agents inherit the same permissions as the users they serve — no special access, no backdoors
Governed and secure — ready to power applications
AI Agents

From Ontology to Operational Agents

How the ontology becomes the foundation for intelligent automation

Discovery

Agents navigate the graph to find the right information

Analysis

Agents compute insights across entities and relationships

Automation

Agents execute actions within governed boundaries

Learning

Agent decisions feed back into the ontology as new data

Agents understand context, not just data

Because the ontology captures meaning — not just tables — agents can reason about relationships, follow chains of context, and give answers grounded in organizational reality.

Every agent benefits from every improvement

When a new entity type or relationship is added to the ontology, every agent that touches that domain immediately gains access. The investment compounds.

Decisions create a feedback loop

Actions taken through agents are captured as structured data in the ontology. Over time, this operational record enables model retraining, pattern detection, and continuously improving recommendations.

Best Practices

Building an Effective Ontology

1

Start with what people already call things

Use the terms your teams use every day. The ontology should feel familiar to domain experts — not like learning a new system. If people say "student" and "course," those are your entity types.

2

Model for decisions, not just storage

Every entity type, relationship, and action should support a real decision someone needs to make. If no one will ever query it or act on it, it doesn't belong in the ontology yet.

3

Let the ontology grow with usage

Start with a focused set of entity types for your first use cases. As agents and users interact with the system, new modeling needs will emerge organically — extend the ontology then, not before.

4

Treat actions as first-class citizens

The operational layer — what agents and users can do — is as important as the data layer. Define actions with clear validation rules, permissions, and side effects from the beginning.

Getting Started

Build Your Ontology

Identify core entities

Map the real-world objects and events that drive your organization's key decisions

Define relationships

Draw the connections between entities that agents will need to traverse

Model actions and permissions

Specify what can change, who can change it, and what happens when they do

Deploy your first agent

Launch an agent that operates on the ontology — see structured knowledge in action

Agentic Ontology — The Knowledge Layer Every AI Agent Reasons Over

Agentic Ontology by ibl.ai is the map of a regulated firm that its AI agents reason over: accounts, transactions, alerts, loans, households and the relationships between them, with the actions an agent may take and the permissions it inherits.

It connects core banking, the policy system, the CRM and the warehouse in place over MCP, read-only and role-scoped through your identity provider, behind your own firewall, with every access logged.

Open source, self-hosted, and yours — including full code access.

What This Is

A unified knowledge layer that runs inside your network. It makes the systems you already run — SIS and ERP databases, data warehouses, SaaS apps — queryable by AI agents over MCP, with the data, the cache and the permissions staying on-premise.
MCP in, MCP outDatabases are exposed as MCP tools through Google's MCP Toolbox; REST systems get lightweight MCP servers. The layer is itself one MCP server behind your firewall and identity provider, so any authorized runtime — ibl.ai, Claude, Cursor, your own app — connects and gets results scoped to the caller's role.
Model once, every agent inherits itModel an entity once and every agent inherits it: the tenth agent costs a fraction of the first, because the knowledge, the definitions and the governance are already there.

The semantic layer: the nouns, what exists in your world

Entity typesModel real-world things in the terms financial services already uses: accounts, transactions, alerts, loans.
AttributesCapture characteristics — enrollment date, grade level, capacity — with a type that defines the shape and a value on each instance.
RelationshipsTyped connections that carry meaning — a student enrolls in a course, a course belongs to a department — one-to-one, one-to-many or many-to-many.

The operational layer: the verbs, what can happen in your world

ActionsPermissible changes with validation rules and side effects: triage an alert, score a loan, file a report.
FunctionsLogic that reads attributes, traverses relationships and returns computed results — calculate a GPA, assess a risk score, route an approval.
PermissionsWho can do what, at every level, inherited from the roles your identity provider already holds.
ResultTogether the two layers form a digital twin of your organization: a complete, navigable map that agents use to understand context, make decisions and take action.

Your ontology, in financial services's own terms

The primitives are the same everywhereEntity types, attributes, relationships and actions. What changes is the vocabulary, and the ontology is modeled in the terms your people already use.
NounsAccounts, transactions, alerts, loans.
VerbsTriage an alert, score a loan, file a report.
SystemsConnected in place over MCP: core banking, the policy system, the CRM and the warehouse.

Why do AI agents need an ontology?

Shared understanding at scaleEvery team, department and agent operates from the same definitions — no conflicting spreadsheets, no siloed dashboards. New sources are modeled into a common language rather than spawning another disconnected view.
Human-readable by designPeople interact with familiar terms, not tables, joins or API endpoints. Domain experts explore data directly without writing queries or waiting on engineering.
Build once, reuse everywhereA well-modeled entity type serves every downstream application — dashboards, agents, reports, integrations. The cost of launching the tenth agent is a fraction of launching the first.
Capture decisions as dataEvery action taken through the ontology — an approval, a classification, an override — is recorded. Audit trails and decision history are built in, not bolted on.
Ground AI in organizational realityAgents fail first because data is siloed across the SIS, LMS, CRM, ERP and warehouse. An agent grounded in a unified ontology reads the same reality your people do — no translation layer where hallucinations creep in.

What are the building blocks of an ontology?

Entity typesSchema definitions of real-world objects or events; each has instances. e.g. Student, Course, Department, Device, Transaction.
AttributesAn attribute type defines the shape (text, number, date, location); an attribute value is the data on a specific instance. e.g. name, enrollment date, capacity, GPA.
RelationshipsTyped connections between entities that carry meaning, including links between entities of the same type. e.g. Student enrolls in Course, Manager supervises Employee.
ActionsControlled operations that create, modify or remove entities and relationships in one transaction, enforcing validation rules and triggering side effects such as notifications.
Interfaces, functions and derived attributesAbstract shapes shared by several entity types; code-based logic agents call at decision time; values computed live from the graph — a department's average satisfaction, a student's total credits.
Semantic searchText converted to vector embeddings and matched by meaning, so agents find the right entities even when a query matches no exact field value.

How is the knowledge layer governed?

Schema permissionsWho can view or modify entity type definitions, create relationship types, or define and edit action types.
Data permissionsWho can read specific instances and execute actions on which entities, with row-level and field-level security for sensitive data.
Agents inherit, never bypassAgents inherit the same permissions as the people they serve — no special access, no backdoors. Every request forwards the user's own identity token; the layer never stores a credential of its own.
Read-only by constructionDiscovery runs a read-only safety suite first — seven write attempts that must all be denied — before a source is introspected and provisioned.

How does an ontology become operational agents?

DiscoveryAgents navigate the graph to find the right information.
AnalysisAgents compute insights across entities and relationships.
AutomationAgents execute actions within governed boundaries.
LearningAgent decisions feed back into the ontology as new data, so the operational record enables retraining, pattern detection and continuously improving recommendations.
Every agent benefits from every improvementWhen a new entity type or relationship is added, every agent that touches that domain gains it immediately. The investment compounds.

How do you build an ontology for your organization?

Start with the nounsModel entity types, attributes and relationships in the business terms your domain experts already use: accounts, transactions, alerts, loans.
Then add the verbsActions with validation rules, functions that encode logic, and permissions inherited from your existing roles. Connect source systems once over MCP, and govern everything read-only and role-scoped from day one.
Ship it from the CLIThe whole lifecycle ships from a CLI — service discovery, schema analysis, role validation, scheduled sync and deployment — with built-in defaults for 22 common enterprise and higher-education systems, including core banking, the policy system, the CRM and the warehouse.
Let it grow with usageStart with a focused set of entity types for your first use cases, model for the decisions people actually make, and treat actions as first-class citizens from the beginning.

Why Agentic Ontology instead of a managed vendor's knowledge layer?

Where the data goesAgentic Ontology: Stays in your network, queried in place over MCP | Managed vendor: Extracted through a VPN into the vendor's cloud
Who holds the mapAgentic Ontology: You do — open source, MIT, self-hosted | Managed vendor: You rent access to a map of your own organization
IdentityAgentic Ontology: Your identity provider, role-scoped per request | Managed vendor: The vendor's accounts and service keys
ModelsAgentic Ontology: Any LLM, any authorized runtime, switch anytime | Managed vendor: The vendor's models
PricingAgentic Ontology: Usage or flat license, no per-seat fee | Managed vendor: Per seat, per connector, per year
ExitAgentic Ontology: The layer keeps running after the contract | Managed vendor: The map leaves with the vendor

Part of the ibl.ai platform

Agentic Ontology is what an AI Transformation engagement delivers first: ibl.ai's forward-deployed engineers model your nouns and verbs, connect your systems over MCP and hand you the layer. Agentic OS runs the agents that reason over it; Agentic SIS, LMS, CRM and Wallet are the records it connects. One sign-in, one set of roles, one platform you own.

Experience Agentic Ontology Today

Run It YourselfClone github.com/iblai/ontology (MIT, Python 3.11+), run `ontology config init`, and add your first source
Scope a DeploymentContact ibl.ai to model your ontology with forward-deployed engineers inside your network
Schedule a DemoSee agents reason over a real ontology, in your sector's terms

What our partners say about us

Case Studies
Chris Gabriel

Chris Gabriel | Google

Case Studies
Lorena Barba

Lorena Barba | George Washington University

Case Studies
Dr. Juana Mendenhall

Dr. Juana Mendenhall | Morehouse College

Juile Diop

Juile Diop | MIT

Adam Tetelman

Adam Tetelman | Nvidia

Jason Dom

Jason Dom | American Public University System

Benjamin Breyer

Benjamin Breyer | Columbia University

Ken Fujiuchi

Ken Fujiuchi | SUNY

Erika Digirolamo

Erika Digirolamo | Monroe College

David Flaten

David Flaten | SUNY

David Vise

David Vise | Modern States Education Alliance

Linda Wood

Linda Wood | ARM Institute (U.S. Department of Defense)

Case Studies
Chris Gabriel

Chris Gabriel | Google

Case Studies
Lorena Barba

Lorena Barba | George Washington University

Case Studies
Dr. Juana Mendenhall

Dr. Juana Mendenhall | Morehouse College

Juile Diop

Juile Diop | MIT

Adam Tetelman

Adam Tetelman | Nvidia

Jason Dom

Jason Dom | American Public University System

Benjamin Breyer

Benjamin Breyer | Columbia University

Ken Fujiuchi

Ken Fujiuchi | SUNY

Erika Digirolamo

Erika Digirolamo | Monroe College

David Flaten

David Flaten | SUNY

David Vise

David Vise | Modern States Education Alliance

Linda Wood

Linda Wood | ARM Institute (U.S. Department of Defense)

Frequently Asked Questions

Bring us a hard problem. Keep the code.

Run Agentic Ontology on your own terms

Start free on our cloud today, or take the whole codebase into your own infrastructure. Either way our engineers work alongside your team, and you own all the code and the data.

Scope a deploymentBook a 30-minute demoSee what's inside

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. · SOC 2 Type II certified