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.”
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.
| ibl.ai forward-deployed engineers | A systems integrator or vendor PS | |
|---|---|---|
| What you keep when it ends | ibl.ai forward-deployed engineersThe full codebase, the data, the MCP servers and the agents | A systems integrator or vendor PSA deliverable document and a subscription |
| Where the work runs | ibl.ai forward-deployed engineersYour cloud, on-premise or air-gapped | A systems integrator or vendor PSThe vendor's cloud, under the vendor's terms |
| Which models | ibl.ai forward-deployed engineersAny LLM, switched at will | A systems integrator or vendor PSThe one the product ships with |
| Pricing shape | ibl.ai forward-deployed engineersA pilot, then a flat engagement; no per-seat fees | A systems integrator or vendor PSHourly rates plus per-seat licenses |
| Who operates it after | ibl.ai forward-deployed engineersYour team, enabled by ours | A systems integrator or vendor PSThe vendor, on retainer |
How to connect your campus systems (LMS, SIS, CRM, degree audit) to AI agents — step by step.
Read the GuideBuild 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Platform Delivery
Choose the deployment model that fits your organization
We manage the infrastructure
Deployed in your environment
How Delivery Works
A three-phase process from code handoff to production
Agent Development
Self-serve, collaborative, or both — your team and ours build together
Your teams build independently
We work with you to build agents
Enterprise Integration
Connect to the tools and systems your organization already uses
SAML / OIDC
Your existing databases and APIs
Custom data integrations
LMS, CRM, SIS, and more
Ongoing Collaboration
A continuous partnership — not a one-time deployment
We develop purpose-built agents for your use cases, connected to your data and tuned for your workflows.
We build new features and integrations that make your agents more powerful — additional data sources, richer tooling, new interfaces.
Dedicated channels for collaboration, support, and strategic alignment as your needs evolve.
What Makes This Successful
Start with concrete agents that can be demonstrated from day one. Stakeholders see working agents immediately — not a black box for months.
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.
The platform integrates with your current tools and data sources. Your teams don't need to change their workflows to accommodate agents.
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 Steps
Deploy the platform on your infrastructure with a focused use case
Walk through the platform architecture with your technical teams
Assess your existing systems and architect the agent layer
Your teams learn to build and deploy agents on the platform
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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