AI Transformation

AI built with your team, owned by you

Forward-Deployed Engineers build your MCP-powered campus memory layer for AI agents — with your data, in your environment. 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.

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

Don’t take our word for it?See what our partners say →

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

Forward-deployed engineers work inside your environment with your team. Every engagement ends with code, data and configuration that are yours.

A systems integrator bills hours and leaves a document. Vendor professional services configure a product you rent. Our engineers leave you owning the stack they built.

How to connect your campus systems (LMS, SIS, CRM, degree audit) to AI agents — step by step.

Models & Runtimes — any model, any agent runtimeServices

Build your campus "memory layer" for AI agents — powered by the Model Context Protocol (MCP) — with your data, in your environment.

ibl.ai's Forward-Deployed Engineers embed with your team to connect SIS, LMS, CRM, ERP, identity, storage, and content systems into a secure, policy-aware memory layer built on the Model Context Protocol (MCP). That memory becomes the backbone for AI agents — student tutors, instructor TAs, and administrative assistants — running privately in your infrastructure.

This is professional services, billed by the hour (ultra-competitive rates), with clear milestones and artifacts you own.

1. Data Layer — Your Root Systems

Start here: where do your users, content, and records already live?

List every system that holds something an agent will need to read. This inventory is the foundation — bring in as many root systems as you want, and each one gets its own connector in the next step.

2. Connectors — The Ontology Layer

Put a thin layer on top over MCP — not a complex integration project

Our open-source Ontology builds these connectors — databases (PeopleSoft, Oracle, Snowflake) and REST systems (Canvas, Salesforce, ServiceNow, Workday) alike — and handles the toolbox, schema mapping, and sync. Add as many as you have systems.

3. MCP Broker

Many MCP servers → one unified interface to the outside world

The broker authenticates each request, checks RBAC (deny-by-default), routes the tool call to the right MCP server, filters the response, and logs it. This is what AI Data Unification delivers end to end.

4. Skills — Plain-English Instructions per System

Markdown skill files written by domain experts, not engineers

Each system gets many skills: “advance an admissions application,” “onboard a new employee,” “advance a sales deal,” “open an IT ticket,” “check a claim status.” Bring in as many skills per system as the work requires.

5. Agents

Skills + prompts + instructions + memory

Add as many agents as you want. Each one bundles a set of skills, an instruction prompt, and persistent memory, and inherits the same role-scoped access enforced by the broker.

6. Harness — Runs in Your Infrastructure

Your servers, sandboxed — data privacy, code security, no vendor lock-in

Each agent runs in its own sandbox with isolated execution, resource limits, endpoint allowlisting, credential injection, and audit logging — the same security model as the rest of the platform.

7. Web Layer

Edit and ship without waiting on an engineer or a deployment

The web layer exposes editing and running of skills, agents, and data sources directly in the browser, governed by the same roles and permissions as every layer below it.

8. Applications — One per Department

A dedicated app per team, embeddable anywhere (LTI & more)

This is what we use Agentic Vibe for: describe the app and assemble it from your existing agents and skills. Bring in as many applications at this layer as you want.

Watch the walkthroughThe agentic-development video on ibl.ai/architecture#agentic-development shows these moves end to end, from your root systems to a department app, on infrastructure you own.

The five steps at a glance

Deployment, delivery, development, integration and partnership: five steps from the first conversation to production agents, each ending in a checkpoint your stakeholders can see. The diagram below walks them in order.

Step 1 — Deployment

Platform Delivery

Choose the deployment model that fits your organization

ibl.ai-Hosted

We manage the infrastructure

• → Fastest time to launch
• → No infrastructure overhead for your IT team
• → Fully managed updates and maintenance
• → Ideal for organizations that want speed

Customer-Hosted

Deployed in your environment

• → Full GitHub repository — the complete platform code
• → Pre-built Docker images — ready to deploy
• → Your security perimeter, your control
• → Ideal for regulated industries and data sovereignty

Both options deliver the same platform — a runtime for creating, managing, deploying, and using AI agents across web, mobile, API, and MCPPlatform is live — agents are accessible from day oneStep 2 — Delivery

How Delivery Works

A three-phase process from code handoff to production

1 We deliver the platform

• Full GitHub repository — the complete multitenant platform code
• Pre-built Docker images — ready to deploy, tested, and versioned

2 Joint development environment

• We work alongside your team in a dev/staging environment
• Agent configuration, system integration, testing, and training happen here together

3 Production — your way

• Your team can promote to production independently, on your schedule and through your processes
• Or we manage production for you — we run production environments for many leading organizations
• Access to your production data is never a prerequisite — the choice is yours
• ibl.ai-hosted deployments include full production management by our team

Platform deployed — begin building and connecting agentsStep 3 — Development

Agent Development

Self-serve, collaborative, or both — your team and ours build together

Self-Serve

Your teams build independently

• → Create agents through the platform UI or API
• → Connect to your data sources directly
• → Leverage institutional knowledge your team already has
• → Full API coverage — programmatic agent management

Collaborative

We work with you to build agents

• → Build agents connected to specific data sources
• → Develop MCP servers and custom data integrations
• → Configure SSO and enterprise deployment standards
• → Build software that makes agents more capable

Agents live and working — visible results from day oneStep 4 — Integration

Enterprise Integration

Connect to the tools and systems your organization already uses

Single Sign-On

SAML / OIDC

Data Sources

Your existing databases and APIs

MCP Servers

Custom data integrations

Existing Tools

LMS, CRM, SIS, and more

The platform adapts to your stack — your workflows don't need to change to support agentsIntegrated and operational — continuous improvement beginsStep 5 — Partnership

Ongoing Collaboration

A continuous partnership — not a one-time deployment

Building specific agents

We develop purpose-built agents for your use cases, connected to your data and tuned for your workflows.

Extending platform capabilities

We build new features and integrations that make your agents more powerful — additional data sources, richer tooling, new interfaces.

Ongoing communication

Dedicated channels for collaboration, support, and strategic alignment as your needs evolve.

Best Practices

What Makes This Successful

1 Lead with tangible results

Start with concrete agents that can be demonstrated from day one. Stakeholders see working agents immediately — not a black box for months.

2 Start with specific use cases

Define concrete agents early. If the project definition is too broad without specific agents to show, stakeholder buy-in stalls while time goes into invisible infrastructure work.

3 Adapt to the existing stack

The platform integrates with your current tools and data sources. Your teams don't need to change their workflows to accommodate agents.

4 Empower your engineers

Your team has the institutional knowledge. When your engineers can build agents programmatically and connect them to internal data sources, the value compounds.

Getting Started

Proposed Next Steps

Pilot program

Deploy the platform on your infrastructure with a focused use case

Architectural deep-dive

Walk through the platform architecture with your technical teams

Integration mapping

Assess your existing systems and architect the agent layer

Hands-on workshop

Your teams learn to build and deploy agents on the platform

Step 1, Deployment: choose how the platform is delivered

ibl.ai-hosted: we manage the infrastructure. Fastest time to launch, no infrastructure overhead for your IT team, fully managed updates and maintenance; ideal for organizations that want speed.

Customer-hosted: deployed in your environment. Full GitHub repository with the complete platform code, pre-built Docker images ready to deploy, your security perimeter and your control; ideal for regulated industries and data sovereignty.

Both options deliver the same platform: a runtime for creating, managing, deploying and using AI agents across web, mobile, API and MCP. Platform is live, and agents are accessible from day one.

Step 2, Delivery: three phases from code handoff to production

1. We deliver the platform: the full GitHub repository, the complete multitenant platform code, and pre-built Docker images, tested and versioned.

2. Joint development environment: we work alongside your team in a dev or staging environment, where agent configuration, system integration, testing and training happen together.

3. Production, your way: your team can promote to production independently, on your schedule and through your processes, or we manage production for you, as we run production environments for many leading organizations. Access to your production data is never a prerequisite; ibl.ai-hosted deployments include full production management by our team.

Step 3, Development: self-serve, collaborative, or both

Self-serve: your teams build independently. Create agents through the platform UI or API, connect to your data sources directly, leverage the institutional knowledge your team already has, with full API coverage for programmatic agent management.

Collaborative: we work with you to build agents connected to specific data sources, develop MCP servers and custom data integrations, configure SSO and enterprise deployment standards, and build software that makes agents more capable. Agents are live and working, with visible results from day one.

Step 4, Integration: connect the tools and systems your organization already uses

Single sign-on over SAML or OIDC. Data sources: your existing databases and APIs. MCP servers: custom data integrations. Existing tools: CRM, HRIS, ERP, ticketing, LMS, SIS and more.

The platform adapts to your stack; your workflows do not need to change to support agents. Integrated and operational, continuous improvement begins.

Step 5, Partnership: a continuous partnership, not a one-time deployment

Building specific agents: we develop purpose-built agents for your use cases, connected to your data and tuned for your workflows.

Extending platform capabilities: we build new features and integrations that make your agents more powerful, with additional data sources, richer tooling and new interfaces.

Ongoing communication: dedicated channels for collaboration, support and strategic alignment as your needs evolve.

What makes this successful

Lead with tangible results: start with concrete agents that can be demonstrated from day one, so stakeholders see working agents immediately, not a black box for months.

Start with specific use cases: define concrete agents early. If the project definition is too broad without specific agents to show, stakeholder buy-in stalls while time goes into invisible infrastructure work.

Adapt to the existing stack: the platform integrates with your current tools and data sources, so your teams do not need to change their workflows to accommodate agents.

Empower your engineers: your team has the institutional knowledge. When your engineers can build agents programmatically and connect them to internal data sources, the value compounds.

Proposed next stepsA pilot program that deploys the platform on your infrastructure with a focused use case. An architectural deep-dive that walks through the platform architecture with your technical teams. Integration mapping that assesses your existing systems and architects the agent layer. A hands-on workshop where your teams learn to build and deploy agents on the platform.

What is MCP?

The Model Context Protocol is an open standard — originally developed by Anthropic — that defines how AI models connect to external data sources, tools, and services. MCP provides a universal interface between AI agents and your institutional systems, replacing brittle custom integrations with standardized, secure connectors.

Think of MCP as USB-C for AI: one protocol, every system. Instead of building a custom integration for each SIS, LMS, or CRM, MCP gives agents a single, consistent way to read data, call tools, and respect permissions across your entire campus stack.

Why MCP Matters for Higher Education

Campus IT teams maintain dozens of systems — Banner, Canvas, Salesforce, Workday, SharePoint, and more. Traditional integration approaches require point-to-point connectors that break with every vendor update. MCP eliminates this fragility by providing a protocol-level contract between AI agents and data sources.

With MCP, your institution gets portable agents that work across any LLM provider (OpenAI, Anthropic, Google, Meta, or local models), interchangeable connectors that can be swapped without rewriting agent logic, and built-in security boundaries where every data access goes through policy-aware middleware with FERPA-grade controls.

MCP Architecture at ibl.ai

Every ibl.ai deployment uses MCP as the core integration protocol. Our Forward-Deployed Engineers build MCP servers for each campus system — SIS, LMS, CRM, ERP, identity providers, and document stores. These MCP servers expose structured tools and resources that agents can discover and invoke at runtime.

The result is a composable agent architecture: a student tutor agent can query enrollment data from Banner, fetch course materials from Canvas, check deadlines from the academic calendar, and retrieve advising notes from Salesforce — all through MCP — without any custom glue code between systems.

SIS MCP Server (Banner, PeopleSoft, Colleague)Exposes enrollment records, degree audits, registration holds, transfer credits, and academic standing as MCP resources. Agents can query real-time student data without direct database access. Field-level FERPA controls enforce who sees what based on role and consent.

LMS MCP Server (Canvas, Blackboard, Brightspace, Moodle)Provides course content, assignment metadata, grades, discussion threads, and rubrics as MCP tools. Agents can retrieve specific lecture materials, check submission deadlines, and access course-level analytics — all scoped to the requesting user's permissions.

CRM MCP Server (Salesforce, Slate, HubSpot)Connects enrollment pipelines, prospect records, donor relationships, and advancement data. Agents can look up application status, pull advising case histories, and surface engagement metrics for retention interventions.

Identity & Directory MCP Server (Entra ID, Okta, Google Workspace)Provides role resolution, group memberships, and authentication context. MCP-level RBAC ensures agents only access data appropriate for the authenticated user's institutional role — student, faculty, advisor, or admin.

Document & Storage MCP Server (SharePoint, OneDrive, S3, GCS)Indexes institutional documents — policies, handbooks, catalogs, syllabi — and makes them retrievable via semantic search through MCP. Agents can cite specific documents with page-level provenance rather than generating answers from training data alone.

Custom MCP ServersWe build MCP servers for any system with an API or database: ERP/HR (Workday, Oracle), scheduling (25Live, Ad Astra), housing, dining, parking, library systems, research databases, and more. If your institution has it, we can connect it.

Protocol-Level Access Control

Every MCP request carries authentication context — who is asking, what role they hold, and what consent has been granted. Our MCP middleware enforces field-level permissions before data ever reaches the agent.

A student asking about their own grades sees their records; an advisor querying the same system sees their advisee cohort; an admin sees aggregate analytics. Same MCP server, different views.

PII Masking and Data Minimization

MCP responses pass through a policy engine that redacts sensitive fields based on configurable rules. Social security numbers, financial aid details, and disability accommodations are masked or excluded from agent context unless explicitly authorized.

Every redaction decision is logged for audit.

Audit Trails and Compliance

Every MCP tool invocation is logged with timestamp, requesting agent, authenticated user, data accessed, and response summary.

These audit trails support FERPA compliance reviews, internal security audits, and incident response. Logs are stored in your infrastructure and retained per your institutional policy.

Sandboxed Execution

MCP servers run in isolated containers within your VPC or on-premises infrastructure. No campus data leaves your environment.

Agents interact with MCP servers over internal networks with mTLS encryption. External LLM providers receive only the agent's synthesized prompts — never raw institutional data.

IT & Enterprise Architecture

Institutional Research

Student Success / Advising

Teaching & Learning Centers

Program/Department Leads

Security, Privacy, Legal

Systems & Data Mapping

Inventory: SIS (e.g., Banner, PeopleSoft, Colleague), LMS (Canvas, Blackboard, Brightspace, Moodle), CRM (Salesforce, Slate), ERP/HR (Workday, Oracle), Identity (Entra/Okta/Google), Storage (SharePoint/OneDrive/S3/GCS).

Schemas & Contracts: enrollment, rosters, outcomes, accommodations, deadlines, advising notes, policies, course materials metadata. Policy & Governance: FERPA fields, role scopes, retention rules, redaction maps, consent flows.

MCP Server Development

We build production-grade MCP servers for every campus system in your stack. Each server exposes typed tools and resources following the MCP specification, with built-in schema validation, error handling, rate limiting, and observability.

Servers are containerized and deployed via Terraform or Kubernetes manifests you own.

Memory Layer Engineering

MCP-based Connectors: secure adapters that normalize read/write paths across systems. Per-User Memory Graph: knowledge graph + vector index for contextual retrieval (course content, outcomes, deadlines, interventions).

Guardrails Engine: RBAC, field-level permissions, PII masking, consent receipts, audit trails. Sync & Freshness: event bus/CDC, backfills, idempotent jobs, conflict resolution, replay.

Agent Enablement (Optional)

Student Tutor: citable Q&A grounded in course content, deadlines, and policies via MCP. Teaching Assistant: study guides, FAQ triage, formative feedback, discussion support.

Digital Assistant (Admin): policy lookups, enrollment snapshots, risk roll-ups, "what's changed?" digests. Model Hub: OpenAI, Gemini, Anthropic, Llama, or local/NPU — hot-swappable per policy/cost.

Workflow Automation (Partner Institutions)Proactive nudges (risk, deadlines), case routing, degree milestones. Content pipelines (ingest → chunk → cite), assessment item generation with human review. Approval gates for academic control (human-in-the-loop).

MCP server source code for every connected campus system

Connector code & IaC (Terraform/K8s manifests) to deploy in your VPC/on-prem

Data dictionaries, MCP tool schemas, and contract tests

Policy configs (RBAC matrices, redaction rules, retention/expiry)

ETL/ELT jobs, sync runbooks, and observability dashboards

Agent starter kits (prompts, MCP tool definitions, evaluation harnesses)

Security & Compliance packet (threat model, MCP data flows, audit checklist)

Discovery & Design (1–3 weeks):workshops, MCP architecture, system inventory, backlog, estimates

MCP Server Sprints (2–6 weeks):build and test MCP servers for each campus system, memory layer, policy engine

Pilot & Hardening (2–4 weeks):limited cohorts, telemetry, MCP performance tuning, handover

Handoff or Co-Manage:your team runs it; we stay on a light retainer if desired

Billing:hourly, ultra-competitive rates; weekly timesheets; milestone demos; you can pause/rescope anytime

All MCP servers run in your environment (AWS/Azure/GCP or on-prem), with your IAM/KMS

FERPA/GDPR support, SOC 2–aligned practices, least-privilege MCP access

MCP-level data minimization, field-level masking, consent receipts, audit logs

Red-team prompts, safety filters, and replay evaluation for agents

mTLS between agents and MCP servers; no raw data sent to external LLM providers

MCP Server Layer → Typed connectors to SIS/LMS/CRM/ERP/Identity/Storage

MCP Gateway → Authentication, rate limiting, request routing, and observability

Event Bus + CDC → Reliable syncs, backfills, and change capture

Student Memory Layer → Graph + vector store with MCP-aware policy retrieval

Policy/Guardrails Engine → RBAC, PII redaction, consent, rate limits

Agent Interfaces → Tutor (student), TA (instructor), Digital Assistant (admin)

Observability → MCP request traces, latency metrics, cost monitors, evaluation harnesses

"Single pane of glass" tutor with deadlines, materials, and accommodations context — powered by MCP connections to SIS, LMS, and advising systems

TA that drafts study guides and triages repetitive questions (cited answers from MCP-connected course materials)

Admin assistant that surfaces risk cohorts and policy answers with provenance via MCP queries across enrollment, grades, and intervention systems

Cross-system automations: enrollment triggers, nudges, degree-progress alerts — orchestrated through MCP tool chains

Content ingestion pipelines with citations and IP safeguards

Multi-agent workflows where specialized agents collaborate through shared MCP servers — one agent handles advising, another handles scheduling, a third handles financial aid — all sharing the same secure data layer

MCP-native architecture:every integration we build follows the open MCP standard — no proprietary lock-in

Higher-ed native:LTI 1.3, SIS/LMS nuances, academic governance baked in

Ownership by design:you get the MCP server code, configs, and deployment scripts

Model-agnostic and cost-aware:MCP works with any LLM provider; swap models and optimize for accuracy and spend

Speed + rigor:we ship working MCP integrations quickly, with tests and runbooks

Architecture Review (hours):map systems, goals, risks, and design your MCP server topology

Fixed-Scope Pilot (optional):cap hours for MCP servers covering a specific cohort or program

Ongoing Hours (as needed):new MCP servers, additional connectors, and workflow builds

Process Mapping

We embed with your teams to map how work actually flows—not how org charts say it should. Every handoff, approval step, data lookup, and decision point is documented.

This reveals automation opportunities that generic AI tools miss.

Bottleneck Identification

We identify where staff spend time on repetitive, rule-based tasks that agents can handle.

Common findings: answering the same 50 questions, manual data entry across systems, routing requests to the right department, and generating routine reports.

Agent Opportunity Scoring

Each potential automation is scored on impact (time saved, error reduction), feasibility (data availability, system access), and risk (sensitivity, compliance requirements).

High-impact, low-risk workflows deploy first.

Phased Rollout Planning

We plan deployment in phases—starting with internal-facing agents that assist staff, then expanding to student-facing and external-facing agents as confidence builds.

Each phase has defined success criteria before proceeding.

Read/Write Separation

Your knowledge base is architected with strict read/write separation. Agents that answer questions read from curated, validated knowledge stores. Agents that update knowledge write through approval workflows with human review.

This separation prevents hallucinated content from contaminating your institutional knowledge.

Structured Knowledge Ingestion

We work with your subject-matter experts to catalog and ingest institutional knowledge—policy documents, process guides, training materials, historical decisions, and domain expertise.

Each knowledge source is tagged with provenance, freshness dates, and authority levels.

Version-Controlled Knowledge

Knowledge bases are version-controlled like code. Every update is tracked, reversible, and auditable.

When policies change, knowledge updates flow through your existing governance process before agents surface them.

Multi-Source Retrieval

Agents retrieve from multiple knowledge stores simultaneously—your LMS content, HR policies, IT documentation, and departmental procedures—ranked by relevance and authority.

No single point of knowledge failure.

Role-Based Agent Design

Each agent is designed like a new hire with a specific job description. It has defined responsibilities, access to specific systems, knowledge boundaries, and escalation protocols.

An admissions agent knows admissions workflows. A financial aid agent knows financial aid. They do not bleed into each other's domains.

Skills as Capabilities

Agents are equipped with discrete skills—query the SIS, draft an email, generate a report, schedule a meeting, look up a policy.

Skills are composable: agents chain them to handle multi-step workflows that previously required multiple people and manual handoffs.

Escalation Protocols

Every agent knows its limits. When a question falls outside its defined competence, it escalates to the right human—not a generic support queue, but the specific person or team responsible.

Escalation paths are configured per role, per department.

Performance Reviews

Just like human hires, agents get reviewed. We build evaluation frameworks that measure accuracy, response quality, escalation appropriateness, and user satisfaction.

Underperforming agents get retrained or restructured.

AI Data Unification connects PeopleSoft, Ellucian Banner, Canvas, Slate, Workday, EAB Navigate, and Salesforce Education Cloud into a single ontology — a structured representation of your organization that agents can reason over.

It has two layers: a semantic layer (the nouns — entities, attributes, relationships) and an operational layer (the verbs — actions, functions, permissions). Together they become the single source of truth every agent reads from.

Unify once, reuse everywhere

Model an entity once and the tenth agent costs a fraction of the first, because it inherits the same definitions, the same data, and the same governance.

The implementation is open source at github.com/iblai/ontology — MIT-licensed, Python 3.11+, 163 passing tests. ibl.ai is family-owned and operated from New York, NY: a long-term partner, not a vendor that ships a license and disappears.

The Semantic Layer — the nouns

Entity types model the real-world objects in your organization — students, courses, departments, enrollments, and advisors. Attributes capture their characteristics, and relationships define how they connect. A student enrolls in a course; a course belongs to a department; advising is an action with rules.

This is the shared vocabulary your domain experts already use, made machine-readable so agents reason over the same reality your people do.

The Operational Layer — the verbs

Actions define the permissible changes an agent can make. Functions encode logic. Permissions govern who — human or agent — can do what.

Agents inherit the same permissions as the users they serve, so they can only act within your existing rules. Every action is captured as data, so audit trails are built in, not bolted on.

Shared understanding at scaleTeams operate from unified definitions instead of siloed, per-system data. Local decisions gain global context because every agent and every department reads from the same graph.

Human-readable by designThe ontology is expressed in familiar business terminology, not a technical schema. Domain experts can explore and validate it directly, bridging technical and non-technical teams.

Build once, reuse everywhereA properly modeled entity serves every application that needs it. The cost of launching the tenth agent is a fraction of launching the first, because the knowledge is already there.

Capture decisions as dataActions are recorded and become queryable knowledge. Audit trails and decision history are a property of the system, not an afterthought you instrument later.

Ground AI in organizational realityAgents operate on the same knowledge humans use. Grounding answers in your real entities and relationships removes the translation layer where hallucinations creep in.

Inbound connections

Databases connect through the Google MCP Toolbox; REST-based systems connect through custom MCP servers, defined in tools.yaml. For universities and colleges, that means PeopleSoft, Ellucian Banner, Canvas, Slate, Workday, EAB Navigate, and Salesforce Education Cloud.

Source credentials never leave your network. Each inbound connector has isolated credential scope, with secrets encrypted at rest.

Knowledge materialization

Data is synced into three layers: text memories in Markdown, a Postgres cache, and vector embeddings for semantic search.

The unified graph stays fresh on a schedule you control.

Outbound — one MCP server

The unified layer exposes itself as a single MCP server over HTTPS, behind your firewall and identity provider.

Any authorized runtime — ibl.ai, Claude, Cursor, or your own apps — connects to it, and results are scoped to the caller's identity.

Read-only enforcement

Version 1 is read-only by design. Before provisioning, a seven-test safety suite verifies that every write attempt is denied; if any write succeeds, provisioning halts and emits remediation SQL.

Agents can read your systems — they cannot mutate them.

Identity & accessEvery MCP request carries the user's Microsoft Entra ID JWT. The gateway validates it and resolves the caller's role from roles.yaml, so an agent sees exactly what that user is allowed to see — row-level scoping included, mapped to your FERPA obligations.

Permissions inherited from your peopleSchema and data permissions are governed centrally. Agents inherit the same permissions as the users they serve, so access control is consistent whether a human or an agent is asking.

Pre-configured connectors for Higher EducationThe catalog ships defaults for PeopleSoft, Ellucian Banner, Canvas, Slate CRM, Workday, EAB Navigate, Salesforce Education Cloud, ServiceNow, Civitas Learning, Handshake, and Blackbaud Raiser's Edge. Seed any of them with one command (ontology service add --from <key>), then test and provision from the CLI.

Provision from the CLIA single CLI covers the whole lifecycle — service discovery and testing, schema analysis, role validation, scheduled sync, and Docker Compose deployment. Stand the layer up, test it, and ship it from your terminal.

Your code & dataThe entire unified knowledge layer is open source. Records stay in the systems you already run — the layer queries them in place; it never copies them to ibl.ai or any third party. "You will have your data, and we may not even have access to it."

Your infrastructureThe MCP server, the Postgres cache, and the vector index all run inside your perimeter. Deploy it in the cloud you choose, in your VPC, on-premise, or fully air-gapped.

Built on Agentic OSAI Data Unification is the knowledge foundation the rest of the ibl.ai platform reasons over. Pair it with Agentic OS to deploy agents that act on the unified graph — all owned and self-hosted by you.

Collective Training (Department/Campus Cohorts)

Foundations: how AI agents work (retrieval, citations, guardrails), academic integrity, accessibility, and equitable use. Pedagogical Patterns: tutoring, advising triage, formative feedback, and scaffolded writing supports.

Toolkits: prompt frameworks, "do/don't" libraries, syllabus language, and student-facing norms. Hands-On Labs: build a course agent, set datasets, test citations, and configure guardrails.

Individual Coaching & Seminars

Course Makeovers: co-design activities, rubrics, and AI-supported workflows (e.g., feedback, study guides). Discipline-Specific Clinics: STEM problem-solving, clinical role-play, studio critiques, case teaching.

Prompt & Policy Reviews: refine prompts, set boundaries, add transparency language and accommodations.

Office Hours (Ongoing)Weekly drop-ins for troubleshooting, use-case vetting, and "show and tell". Micro-demos (10–15 min): agent setup, Google Docs/Slides creation, analytics reads, risk flags. Rapid Iteration: review chat transcripts, improve prompts, adjust datasets and guardrails.

Safety, Ethics, and Compliance

FERPA/GDPR-aware workflows; dataset scoping and role-based access. Academic honesty: detection-resistant assignment design, citation expectations, disclosure guidance.

Accessibility by Design: WCAG practices, captioning, alt text, and inclusive prompt patterns.

Faculty adoption & confidence ratings

Course coverage: agents deployed, datasets configured, guardrails enabled

Student outcomes signals: engagement, help-seeking patterns, common gaps surfaced

Time saved on repetitive tasks (estimates from faculty self-reports)

Accessibility & integrity compliance checks completed

On-Premises (Your Data Center)Full deployment on your institutional infrastructure. Kubernetes or Docker-based orchestration with Terraform IaC. Complete network isolation and data sovereignty.

Private Cloud (Your AWS/Azure/GCP Account)Deploy in your own cloud tenancy with VPC isolation, private endpoints, and your encryption keys. We configure; you own the accounts and the data.

Hybrid (Campus + Cloud)Sensitive workloads on-premises, compute-intensive tasks in your cloud. Secure tunnels between environments with consistent agent behavior across both.

Security Patching & CVE Monitoring

We actively monitor OpenClaw's security advisories and apply patches before they reach your production environment.

Our team tracks CVEs, validates fixes, and manages updates on a schedule aligned with your change management process.

Role-Based Access Controls

Deploy agents with granular permissions tied to your identity provider. Faculty agents access different data than student agents.

Administrative agents have different capabilities than research agents. All enforced at the infrastructure level.

Audit Logging & Compliance

Every agent action, tool invocation, and data access is logged to your SIEM or logging infrastructure.

FERPA-compliant by design, with configurable retention policies and export formats for institutional review.

Network Isolation & Data Boundaries

Agents run in isolated network segments with strict egress controls. Student data never leaves your perimeter.

Integration with campus systems uses mTLS and service mesh architectures.

Input Validation & Prompt SafetyHardened input pipelines prevent prompt injection, data exfiltration, and unauthorized tool execution. Multi-layer validation ensures agents only perform sanctioned operations.

Forward-Deployed Engineers (FDEs) work directly with your team to build and deploy the campus memory layer.

They map your data sources, design secure integrations, implement policy controls, and ensure AI agents have accurate, real-time context from your SIS, LMS, CRM, and HR systems.

The memory layer is a unified, secure data foundation that gives AI agents contextual knowledge about students, courses, and operations.

Without it, AI agents can only provide generic responses. With it, they can answer 'What courses has Maria taken?' or 'Is John on track to graduate?'

Initial memory layer deployment typically takes 4-8 weeks depending on the number of source systems and data complexity. FDEs continue supporting optimization, new integrations, and agent development on an ongoing basis.

Common integrations include SIS (Banner, PeopleSoft, Colleague), LMS (Canvas, Blackboard, Moodle), CRM (Salesforce, Slate), HR/ERP (Workday, Oracle), identity providers (Okta, Azure AD), and file storage (SharePoint, Google Drive, S3).

All integrations use encrypted connections and follow least-privilege access principles. Data stays in your infrastructure, FDEs work under NDA with security training, and all changes go through your change management process.

FERPA and institutional policies guide every decision.

Bring us a hard problem. Keep the code.

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.

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