# Platform Architecture > Source: https://ibl.ai/architecture The architecture page has three views: **Platform Stack** (high-level platform layers and data flow), **Infrastructure & Data Flow** (the deployed server topology combined with how a single request travels the stack — every layer expands to a what/why/how explanation), and **Agentic Development** (how organization-wide agents get built, from the data layer up to department apps). --- ## Platform Stack The logical view of the platform, top to bottom — from the agents people interact with down to the systems your data already lives in. Every layer is independently swappable; click any layer to see what it is, why it matters, and how it works. ### ibl.ai Platform #### Agents Autonomous task execution across the platform - **What:** Autonomous AI agents that perform multi-step tasks on behalf of users — research, content generation, grading, reporting, and more — without requiring constant human input. - **Why:** Manual workflows in large organizations don't scale. Agents let institutions automate repetitive, high-volume work while keeping humans in the loop for decisions that matter. - **How:** Each agent runs inside its own sandboxed environment with dedicated resources. The switchboard layer routes requests and enforces permissions so agents can only access data and tools they're explicitly allowed to use. #### ibl.ai Switchboard Layer - **What:** The central orchestration layer that sits between agents and the rest of the platform. It handles request routing, protocol translation (including MCP), and enforces security policies before any action reaches downstream services. - **Why:** Without a single control plane, every agent would need its own auth logic, rate limiting, and access rules — creating sprawl and security gaps. The switchboard centralizes these concerns in one auditable layer. - **How:** Incoming requests are matched against routing rules and MCP endpoints. Role-based access control checks run in parallel, and only requests that pass both routing and security gates are forwarded to the appropriate LLM or data service. ##### Routing Request orchestration & MCP - **What:** The routing engine that maps incoming requests to the correct downstream service — LLMs, tools, data sources, or external APIs — including full MCP (Model Context Protocol) support. - **Why:** Agents interact with dozens of services. A centralized router eliminates point-to-point wiring, makes it trivial to swap or add services, and provides a single place to observe traffic. - **How:** Declarative routing rules match on intent, agent type, and payload. MCP-compatible endpoints are auto-discovered. The router handles retries, fallback chains, and load distribution across provider pools. ##### Security & Guardrails Role-based access control - **What:** The policy enforcement layer that governs what each agent, user, and service is allowed to do — role-based access control, credential injection, endpoint allowlisting, and leak detection. - **Why:** AI agents with broad tool access are a high-value attack surface. Guardrails ensure that even a misconfigured or prompt-injected agent cannot exfiltrate data, exceed its permissions, or reach unauthorized endpoints. - **How:** Every request passes through RBAC checks before execution. Credentials are injected at the boundary — agents never see raw tokens. Outbound traffic is restricted to allowlisted hosts, and all payloads are scanned for credential leakage in real time. #### LLMs (Model Agnostic) GPT, Claude, Gemini, open-source — swappable - **What:** The model-agnostic LLM layer that provides access to GPT, Claude, Gemini, open-source models, and any future provider — all through a unified interface. - **Why:** No single model is best at everything, and vendor lock-in is a strategic risk. A swappable LLM layer lets institutions choose the right model for each task, negotiate pricing, and migrate without code changes. - **How:** A common abstraction normalizes prompts, tool schemas, and response formats across providers. Routing rules can direct different agent types or workloads to different models. Cost, latency, and quality metrics are tracked per provider to inform optimization. #### Ontological Layer Structured knowledge, semantic relationships - **What:** A structured knowledge layer that maps concepts, relationships, and taxonomies across institutional data — enabling agents to reason about domain-specific meaning, not just raw text. - **Why:** LLMs work with tokens, not institutional knowledge. The ontological layer bridges that gap so agents can understand that "MATH 201" is a prerequisite for "MATH 301," or that a CRM contact maps to an LMS learner. - **How:** Domain ontologies are defined as graph structures with typed relationships. Agents query the ontological layer to resolve entities, traverse relationships, and enrich prompts with structured context before sending them to the LLM. #### Data Lake Unified institutional data store - **What:** A unified data store that aggregates information from every connected system — LMS, SIS, CRM, and third-party tools — into a single, query-ready repository. - **Why:** Institutional data is typically siloed across dozens of systems with incompatible schemas. The data lake eliminates these silos so agents and analytics can operate on a complete, consistent picture. - **How:** Connectors ingest data from source systems via APIs and event streams. Data is normalized, deduplicated, and stored in a schema that supports both structured queries and vector similarity search for AI-driven retrieval. #### Apps & Data Silos SIS, LMS, CRM, third-party systems - **What:** The external applications and data systems that the platform connects to — SIS, LMS, CRM, ERP, and other third-party tools already in use at the institution. - **Why:** Institutions have years of investment in existing systems. Rather than replacing them, the platform integrates with them — pulling data into the data lake and pushing actions back through secure APIs. - **How:** Pre-built connectors handle authentication, pagination, and schema mapping for common platforms (Canvas, Blackboard, Moodle, Workday, Salesforce, and others). Custom connectors can be added for proprietary systems via a standard adapter interface. --- ## Infrastructure & Data Flow The deployed view, top to bottom — how a single request travels from the client through the cloud edge and reverse proxy to the backend and back. Click any layer to see what it is, why it matters, and how it works. ### Clients & Frontend Apps **Clients** — static React single-page apps served from a CDN; every request carries a Bearer token issued by the login app. All clients connect to a shared authentication service: - Web - iOS - Android - Mac - Surface - API - MCP - **What:** The devices and interfaces users connect from — web, native iOS/Android/desktop apps, and API/MCP clients. The web and desktop experiences are static React single-page apps served from a CDN. - **Why:** Meeting users on every surface from one codebase keeps the experience consistent and the attack surface small — clients hold no secrets beyond a short-lived token, and all logic runs behind the edge. - **How:** Each client authenticates once against the shared login app, then carries a Bearer token + RBAC scope on every request to api.iblai.app over HTTPS (port 443). ### Authentication Layer **Login Application** Centralized auth service — all clients redirect here Supported authentication methods: - SSO (SAML / OIDC) - Username / Password - Email OTP - Other Providers Returns **Access Tokens** + **RBAC Permissions** (Role-Based Access Control) Authenticated API Calls (Bearer Token + RBAC) - **What:** A centralized login application that every client redirects to. It supports SSO (SAML / OIDC), username/password, email OTP, and pluggable external providers. - **Why:** One auth service means a single place to enforce identity, MFA, and session policy — no per-app credential logic, and consistent RBAC across every surface. - **How:** On success it issues Access Tokens plus RBAC permissions and redirects the user back to the client; every downstream request is authorized against those scopes. ### Cloud Edge — Load Balancer & WAF **api.iblai.app — Load Balancer & Web Application Firewall.** First point of connection in the backend and the only surface exposed to the internet (port 443); everything behind it is firewalled to internal traffic. - **DNS + CDN** — resolves api.iblai.app, serves static SPA bundles, edge caching. - **Load Balancer** — single entry point (port 443), TLS termination, distributes across the app pool. - **Web Application Firewall (WAF)** — OWASP / ModSecurity rules, rate limiting + IP ban, bot & DDoS filtering. Blocked at the edge: malicious or abusive requests are stopped by the WAF and answered with a custom error page (403 / 429). Only the load balancer is exposed externally; all other servers are firewalled from external access. - **What:** The only surface exposed to the internet: DNS/CDN, the load balancer at api.iblai.app (port 443), and a Web Application Firewall. Everything behind it is firewalled to internal traffic. - **Why:** A single hardened entry point concentrates TLS termination, traffic distribution, and threat filtering in one auditable place, so no backend server is ever directly reachable from the internet. - **How:** The load balancer terminates TLS and spreads requests across the app pool; the WAF applies OWASP/ModSecurity rules, rate limiting, IP bans, and bot/DDoS filtering, answering malicious requests with a custom error page (403/429) before they reach any backend. ### Reverse Proxy — Unified API Gateway Reverse proxy — the unified API gateway. Provisioned and configured by the infrastructure CLI. It routes by hostname (virtual host) and URL path prefix to the right backend service: | Incoming request | Matched by | Routed to | |---|---|---| | os.ibl.ai, login, and other app hostnames | hostname (vhost) | Static SPA bundle | | /api/… (REST prefix) | path prefix | Backend — REST API | | /…/ws/ (streaming prefix) | path prefix | Backend — streaming (WebSocket) | The proxy also terminates internal TLS, injects security headers, and applies rewrite rules — so every frontend app reaches the backend through one consistent, auditable gateway. - **What:** A reverse proxy that acts as the unified API gateway, provisioned by the infrastructure CLI. It routes each request by hostname (virtual host) and URL path prefix to the correct backend service. - **Why:** Every frontend reaches the backend through one consistent, auditable gateway — no app needs to know which service serves each route, and cross-cutting concerns live in one place. - **How:** SPA hostnames resolve to static bundles; /api/… routes to the backend REST API; /…/ws/ routes to the streaming (WebSocket) service. The proxy also terminates internal TLS, injects security headers, and applies rewrite rules. ### Back-End Infrastructure #### App Scalable Servers 64 GB+ RAM each (min. recommended). Ubuntu (latest). Docker. Horizontally scalable. N instances. Each App Scalable Server contains the following containerized services: - Users - Agents - Content - Analytics - Notifications - Multitenancy - REST API - Streaming (WebSocket) - Billing Instances: App Scalable 1, App Scalable 2, App Scalable N Each App Scalable Server connects to: - All A/V Servers - All Agent Sandboxes (port 443) - App Single Server - Ontology (MCP over HTTPS) - **What:** The horizontally-scalable application tier (64 GB+ RAM each, Ubuntu, Docker, N instances) running the multi-tenant platform APIs — users, agents, content, analytics, notifications, billing, and multitenancy — over both REST and streaming (WebSocket). - **Why:** Stateless, horizontally-scalable app servers let capacity grow linearly with load without touching the data tier, and keep every tenant isolated behind the RBAC enforced upstream. - **How:** Each server authenticates the token, enforces tenant + RBAC scope, and connects to all A/V servers, all agent sandboxes (port 443), and the App Single persistence server; for an agent request it opens a streaming connection to the agent's sandbox and calls the chosen LLM. #### Audio / Video Servers Separate server pool. Ubuntu (latest). Docker. Horizontally scalable. N instances. Each A/V Server contains: - Real-Time Audio - Real-Time Video Instances: A/V Server 1, A/V Server 2, A/V Server N - **What:** A separate, horizontally-scalable server pool (Ubuntu, Docker, N instances) dedicated to real-time audio and video — calls and voice AI. - **Why:** Real-time media has very different latency and scaling characteristics than API traffic; isolating it keeps voice and video smooth without competing for the app tier's resources. - **How:** App Scalable servers connect to all A/V servers, and the pool scales independently to handle any number of concurrent real-time sessions. #### Agent Sandboxes 8 GB+ RAM each. Ubuntu (latest). 1 per agent. Unlimited sandboxes. Each Agent Sandbox enforces: - Isolated Execution - Resource Limits - Endpoint Allowlisting - Credential Injection - Leak Detection - Audit Logging Instances: Agent A, Agent B, Agent N Scales to any number of concurrent agent sandboxes on demand. - **What:** One isolated sandbox per agent (8 GB+ RAM, Ubuntu), scaling to any number of concurrent agents. Each enforces isolated execution, resource limits, endpoint allowlisting, credential injection, leak detection, and audit logging. - **Why:** Running every agent in its own sandbox means a compromised or prompt-injected agent cannot reach another agent's memory, exceed its budget, call unapproved endpoints, or exfiltrate secrets. - **How:** Sandboxes communicate with the App Scalable servers exclusively over port 443, and reach institutional data only through the Ontology's MCP endpoint — an internal address on the outbound allowlist, never the source systems directly. Credentials are injected at the boundary (never visible to agent code), outbound traffic is allowlisted and scanned for leaks, and every action is written to a tamper-resistant audit log. #### Ontology — Unified Knowledge Layer Runs inside your network. Connects the systems you already operate and exposes them to agents as **one role-scoped MCP server**. Queried in place, with no data extraction. **Internal-only by default.** The ontology's MCP endpoint is reachable from the Agent Sandboxes and the App Scalable Servers — and from nothing else. The load balancer never routes to it, it is not published to the internet, and no data leaves your network to answer a query. Any other agent runtime, in a sandbox or not, can connect to the same endpoint only if you explicitly authorize it. Connects: Systems of record · Data warehouses · Line-of-business SaaS · Document stores · Directory & identity · Internal APIs ##### Inbound — Databases & warehouses Exposed as MCP tools through Google MCP Toolbox for Databases — one declaration per source, no per-agent integration code. - Systems of record - Data warehouses - Operational databases - Reporting replicas ##### Inbound — SaaS & REST APIs One lightweight MCP server per system, seeded from that system's skill definition. 22 systems ship in the built-in catalog. - CRM - ERP - Service desk & ITSM - HCM - Collaboration & ticketing - Identity & directory - Document stores - Custom internal APIs ##### What an agent actually asks for | The agent needs to know | MCP tool it calls | System reached, in place | |---|---|---| | "What is this person's current status?" | `get-record-status` | System of record — SQL | | "What is still outstanding on this account?" | `list-open-items` | Line-of-business SaaS — REST | | "What changed here last quarter?" | `get-account-activity` | CRM — REST | | "Where did this request get to?" | `get-request` | Service desk — REST | | "How did this metric move by department?" | `query-warehouse` | Data warehouse — SQL | Tools are per-deployment — you decide which ones exist, what each one may reach, and which roles may call it. Every tool is validated against the MCP Toolbox schema before it goes live. ##### Governance - **Verified at provisioning:** A source is connected only after the platform tests what its credentials can actually do against that system and confirms they match the access the deployment declares. If the grants are wider, provisioning refuses to continue. - **Identity-scoped:** Every MCP request carries the end user's identity token. The gateway validates it and resolves the caller's role, so an agent only ever sees the records that person is entitled to. - **Cached in place:** A scheduled sync builds a local cache, plain-text memories, and vector embeddings inside your network — so queries are fast without copying anything to a vendor cloud. - **Owned by you:** Source credentials never leave your network, secrets are encrypted at rest, and the whole knowledge layer is code you run on your own infrastructure. - **What:** The unified knowledge layer that makes the systems you already operate — databases, data warehouses, and line-of-business SaaS applications — queryable by agents over the Model Context Protocol. It runs inside your network, on infrastructure you control. - **Why:** Without it, every agent needs its own bespoke integration into every source system, and the usual alternative is extracting your data into a vendor cloud. The ontology inverts that: systems are connected once, queried in place, and exposed through one governed interface — so the tenth agent costs a fraction of the first and no institutional data ever leaves your network. - **How:** Inbound, databases are exposed as MCP tools through Google MCP Toolbox for Databases and REST systems through lightweight per-system MCP servers; a scheduled sync builds a local cache, text memories, and vector embeddings. Outbound, the whole thing is a single MCP server over HTTPS. Access is internal-only — the Agent Sandboxes and App Scalable Servers reach it, the load balancer never routes to it, and it is not published to the internet. Every request carries the end user's identity token, which the gateway validates and resolves to a role before returning anything. #### App Single Server — Persistence Layer 64 GB+ RAM (min. recommended). Ubuntu (latest). Docker. Single instance. Read replicas supported. Internal-only — reachable solely from the backend servers. ##### PostgreSQL Port 5432 - App data - User records - Permissions - Read replicas pgVector — Embeddings ##### MySQL Port 3306 - Course data - LMS records - Read replicas ##### MongoDB Port 27017 - Documents - Logs - Unstructured data - Read replicas ##### Redis Port 6379 - Sessions - Cache - Rate limiting ##### Object Storage Port 443 (e.g. AWS S3) - File storage - Media assets - User uploads - Backups ##### Shared Filesystem Port 2049 (NFS) - Configurations - Static files - **What:** The App Single Server (64 GB+ RAM, read replicas supported) hosting every data store: PostgreSQL + pgVector, MySQL, MongoDB, Redis, Object Storage, and a shared filesystem. - **Why:** Consolidating state on one vertically-scaled server (with read replicas) keeps data consistent and internal-only — reachable solely from the backend servers, never from the internet. - **How:** PostgreSQL (:5432) holds app data + pgVector embeddings, MySQL (:3306) course/LMS data, MongoDB (:27017) documents/logs, Redis (:6379) sessions/cache, Object Storage (:443) files/media/backups, and a shared filesystem (:2049 NFS) configs/static files. ### Complete Data Flow Sequence How a single request travels the stack, end to end: 1. User opens any ibl.ai client (Web, iOS, Android, Mac, Surface, API, MCP) — a static SPA holding a short-lived session. 2. Client redirects to the centralized Login Application — user authenticates via SSO (SAML / OIDC), password, or email OTP. 3. Login Application returns Access Tokens + RBAC permissions; user is redirected back to the client. 4. Client makes authenticated HTTPS calls to api.iblai.app on port 443 (Bearer token + RBAC) — the only surface open to the internet. 5. The cloud edge terminates TLS at the load balancer and screens the request through the Web Application Firewall (OWASP rules, rate limiting, bot/DDoS filtering); abusive traffic is blocked here with a custom error page. 6. The reverse proxy (unified API gateway) routes by hostname and path prefix — SPA bundle, backend REST API (/api/…), or streaming WebSocket (/…/ws/). 7. The Load Balancer distributes across the App Scalable servers (64 GB+ RAM each); they authenticate the token and enforce tenant + RBAC scope. 8. For an agent request, an App Scalable server opens a streaming connection to the appropriate Agent Sandbox (8 GB+ RAM, one per agent) — sandboxes talk to app servers exclusively over port 443 — and calls the chosen LLM. 9. When the agent needs institutional data, it queries the Ontology over MCP (HTTPS) — internal traffic only, from the sandbox or the App Scalable server. The ontology validates the end user's identity token, resolves their role, and reaches the source system in place; nothing is extracted and nothing leaves your network. 10. App Scalable servers read and write the App Single persistence layer — PostgreSQL/pgVector (:5432), MySQL (:3306), MongoDB (:27017), Redis (:6379), Object Storage (:443), shared filesystem (:2049) — and use the Audio/Video pool for real-time calls and voice. 11. The response streams back the same path — sandbox → App Scalable → reverse proxy → cloud edge → the client — and renders for the user. ### Scaling Model | Component | Scaling | Details | |-----------|---------|---------| | Clients | Static | CDN / app stores / API / MCP | | Login Application | Shared | Centralized auth for all clients | | Cloud Edge (LB + WAF) | Single | Only external entry point (:443) — TLS, WAF, firewall; all other servers internal-only | | Reverse Proxy | Gateway | Routes by hostname + path prefix to backend services | | App Scalable Servers | Horizontal | N instances, 64 GB+ RAM each (min. recommended), Ubuntu (latest), Docker | | Audio / Video Servers | Horizontal | N instances, separate from App Scalable, Ubuntu (latest), Docker | | Agent Sandboxes | Horizontal | Unlimited instances, 8 GB+ RAM (min. recommended), Ubuntu (latest), port 443 → App Scalable | | Ontology (Knowledge Layer) | Internal | Runs inside your network, exposed as one MCP server over HTTPS — reachable only from the Agent Sandboxes and App Scalable Servers, never from the internet | | App Single Server | Vertical | 1 instance, 64 GB+ RAM (min. recommended), Ubuntu (latest), Docker, read replicas | ### Agent Sandbox Security Model Defense-in-depth approach — multiple protective layers ensure no single point of compromise #### Isolated Execution Each agent runs in its own sandboxed environment with strict process isolation. Agents cannot access other agents' memory, filesystem, or network connections. Container-level separation ensures that a compromised agent cannot affect neighboring workloads. #### Resource Limits Memory, CPU, and execution time are capped per agent sandbox. This prevents any single agent from monopolizing shared infrastructure, mitigates denial-of-service from runaway processes, and ensures predictable performance across all concurrent agents. #### Endpoint Allowlisting Outbound HTTP requests from agent sandboxes are restricted to pre-approved hosts and paths only. Agents cannot reach arbitrary external services — every network call must match an explicit allowlist, blocking data exfiltration and unauthorized API access. #### Credential Injection Secrets and API keys are injected at the boundary — never exposed directly to agent code. The sandbox runtime attaches credentials to approved outbound requests at the last mile, so agents can use authenticated services without ever seeing or storing the raw tokens. #### Leak Detection All inbound and outbound traffic is scanned for secret exfiltration attempts. If an agent tries to embed credentials, tokens, or sensitive data in requests, responses, or tool outputs, the system blocks the transmission and flags it for review. #### Audit Logging Every tool execution, network request, and resource access is recorded in a tamper-resistant audit log. Administrators can trace the full history of any agent's actions, enabling forensic analysis, compliance reporting, and real-time anomaly detection. #### Prompt Injection Defense External content ingested by agents passes through pattern-based injection detection, content sanitization, and policy-driven severity rules (Block / Warn / Review / Sanitize). Tool outputs are wrapped before re-entering the LLM context, preventing untrusted data from hijacking the agent's instructions. --- ## Agentic Development Building organization-wide agents is a sequence — from the data layer up to department apps. Click any step to see what it is, why it matters, and how it works. ### 1. Data Layer — Your Root Systems Start here: where do your users, content, and records already live? Examples: PeopleSoft, Ellucian Banner, Canvas, Salesforce, Workday, ServiceNow, Snowflake, Slate, Oracle, SharePoint. - **What:** Every organization-wide agent starts with one question: "What is my data layer going to be?" These are the root systems of record where your users, your content, and your operational data already live. - **Why:** In higher education that might be PeopleSoft for student records; elsewhere it is Salesforce, Workday, ServiceNow, Snowflake, and many others. You do not move this data — you build on top of where it already is. - **How:** 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 Learn more: [AI Data Unification](/service/ai-data-unification) Put a thin layer on top over MCP — not a complex integration project. - **What:** Each root system gets a connector that makes its data available without copying it. Together these connectors form the ontology layer — a unified, machine-readable view of your organization. - **Why:** This replaces multi-month, complex data-integration projects. Instead of ETL pipelines and a new warehouse, you put a thin layer on top that exposes existing data in place, scoped to each caller's role. - **How:** 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. Learn more: [Ontology](/ontology) · [AI Data Unification](/service/ai-data-unification) ### 3. MCP Broker Learn more: [AI Data Unification](/service/ai-data-unification) Many MCP servers → one unified interface to the outside world. - **What:** As you add connectors, you accumulate many MCP servers. The MCP broker sits in front of all of them and makes that information available to the outside world through a single interface. - **Why:** Agents and applications should not need to know which backend serves each tool. The broker centralizes routing, role-based access control, caching, and audit logging — one auditable control plane over every system. - **How:** 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 Learn more: [Agentic OS](/product/agentic-os) Markdown skill files written by domain experts, not engineers. Examples: advance_application_stage (higher ed), get_financial_aid_status (higher ed), onboard_new_employee (enterprise HR), advance_deal_stage (enterprise sales), create_support_ticket (enterprise IT), check_claim_status (healthcare), summarize_case_notes (government). - **What:** With the broker in place, you write specific skill files — Markdown documents — that describe how to interact with each system: a specific lookup, or transitioning a user from one state to another. - **Why:** Skills are written in plain English so they are accessible to domain experts. No more complicated back-and-forth between engineers and subject-matter experts — the people who know the process write the skill directly. - **How:** 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 Learn more: [Agentic OS](/product/agentic-os) Skills + prompts + instructions + memory. Examples: Admissions Agent (higher ed), Advising Agent (higher ed), HR Onboarding Agent (enterprise), Sales Ops Agent (enterprise), IT Support Agent (enterprise), Claims Agent (healthcare), Case Worker Agent (government). - **What:** Agents are built on top of the skills. An agent picks up the relevant skills, plus prompts and instructions for how to interact with the systems, plus memory so it remembers those instructions across turns. - **Why:** Because skills already encode the system knowledge in English, building an agent becomes composition — assemble skills, add a persona and guardrails — rather than another engineering project. - **How:** 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 Learn more: [Agentic OS](/product/agentic-os) Your servers, sandboxed — data privacy, code security, no vendor lock-in. - **What:** Agents need a harness — the runtime environment they execute in. For data privacy, code security, and no vendor lock-in, that harness runs inside your own infrastructure. - **Why:** This is the system that actually interacts with the agents. Keeping it on your servers means your data and code never leave your perimeter, and you stay free to run any LLM you choose. - **How:** 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 Learn more: [Agentic OS](/product/agentic-os) Edit and ship without waiting on an engineer or a deployment. - **What:** The web layer is how people interact with all of this without it being a pain — no waiting on an engineer, no deployment cycle to change a prompt or a skill. - **Why:** Removing those silos and barriers is the accelerator. When a domain expert can edit a skill or an agent and see it live immediately, iteration goes from weeks to minutes. - **How:** 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 Learn more: [Agentic Vibe](/product/agentic-vibe) A dedicated app per team, embeddable anywhere (LTI & more). Examples: Admissions app (higher ed), Advising app (higher ed), HR service desk (enterprise), Sales ops app (enterprise), IT help app (enterprise), Embedded via LTI. - **What:** The web layer is composed into specific applications people actually run — a dedicated app per department: admissions or advising at a university, an HR service desk or IT help app at a company, and one for everybody else. - **Why:** Departments have different workflows and different data. Department-specific apps put exactly the right agents and skills in front of each team — and they can be embedded into platforms you already use (LTI and others). - **How:** 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. **This stack scales horizontally.** Bring in as many data sources, as many skills, as many agents, and as many web applications as you want — a dedicated app per department, each composed from the same owned, self-hosted foundation. --- ## How the ibl.ai platform is built ibl.ai is an Agentic AI Operating System organizations deploy on their own infrastructure. The stack spans a data and integration layer, a per-user memory layer, an agent orchestration layer, and model-agnostic LLM routing — so you can swap providers without rebuilding. The connection point is the ontology — a knowledge layer that runs inside your network and exposes the systems you already operate, from databases and data warehouses to line-of-business SaaS, as one role-scoped MCP server queried in place, with no data extraction. It is reachable from the agent sandboxes and the application servers, and from nowhere else on the internet. Agents connect to your existing systems — LMS, SIS, CRM, and ERP — through MCP-based interoperability. Each agent has defined roles, access controls, and review cycles, and every interaction runs through the platform's safety and moderation layer. Deploy in the cloud, on-premise, or fully air-gapped. You keep full source code, full data control, and the freedom to run any LLM — OpenAI, Anthropic, Google, Meta, or self-hosted open-weight models. ### Explore the platform - [MCP architecture & interoperability](/architecture-mcp) - [How ibl.ai works](/how-it-works) - [Agentic OS platform](/product/agentic-os) - [On-premise & air-gapped deployment](/on-premise-deployment) - [AI safety & moderation](/safety) - [Data ontology](/ontology) --- *[View on ibl.ai](https://ibl.ai/architecture)*