# Platform Architecture > Source: https://ibl.ai/architecture The architecture page has two views: **Platform Stack** (high-level platform layers and data flow) and **Cloud Infrastructure** (data flow and infrastructure diagram). --- ## Platform Stack High-Level Platform Layers & Data Flow ### 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. --- ## Cloud Infrastructure Data Flow & Infrastructure Diagram ### Client Layer **Clients** All clients connect to a shared authentication service - Web - iOS - Android - Mac - Surface - API - MCP ### 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) ### Back-End Infrastructure #### api.iblai.app — Load Balancer First point of connection in the backend. Distributes requests across App Scalable pool. Only external entry point via port 443. **Firewall:** Only the Load Balancer is exposed to external traffic (port 443). All other servers are closed off from external access. #### 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 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 #### 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 #### 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. #### App Single Server — Persistence Layer 64 GB+ RAM (min. recommended). Ubuntu (latest). Docker. Single instance. Read replicas supported. ##### 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 ### Data Flow **Complete Data Flow Sequence** 1. User opens any ibl.ai client (Web, iOS, Android, Mac, Surface, API, MCP) 2. Client redirects to centralized Login Application — user authenticates via SSO, password, or email OTP 3. Login Application returns Access Tokens + RBAC Permissions — user redirected back to client 4. Client makes authenticated API calls to api.iblai.app (Bearer token + RBAC) 5. api.iblai.app routes to Learn (ibl-edx-pro) or Data Manager (ibl-dm-pro) 6. Load Balancer distributes across App Scalable servers (64 GB+ RAM each) 7. Data Manager opens ASGI connection → routes to appropriate Agent Sandbox (8 GB+ RAM, 1 per agent) — Sandboxes communicate with App Scalable servers exclusively via port 443 8. App Scalable servers connect to App Single Server persistence layer — PostgreSQL (:5432), MySQL (:3306), MongoDB (:27017), Redis (:6379), Object Storage (:443), Shared Filesystem (:2049) 9. Internal tooling: LLM Analytics (prompt tracing, costs) + Audio/Video (calls, voice AI) 10. Agent Sandbox → Data Manager → api.iblai.app → User ### Scaling Model | Component | Scaling | Details | |-----------|---------|---------| | Clients | Static | CDN / app stores / API / MCP | | Login Application | Shared | Centralized auth for all clients | | api.iblai.app | Gateway | Routes to Learn + Data Manager | | 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 | | App Single Server | Vertical | 1 instance, 64 GB+ RAM (min. recommended), Ubuntu (latest), Docker, read replicas | | Load Balancer | Single | Only external entry point (:443) — all other servers firewalled from external access | ### 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. --- *[View on ibl.ai](https://ibl.ai/architecture)*