Platform
ScaiWave ScaiGrid ScaiCore ScaiBot ScaiDrive ScaiKey Models Tools & Services
Solutions
Organisations Developers Internet Service Providers Managed Service Providers AI-in-a-Box
Resources
Support Documentation Blog Downloads
Company
About Research Careers Investment Opportunities Contact
Log in

Modules

ScaiGrid is a platform, not a product. The core gateway handles routing, auth, accounting, and webhooks. Everything domain-specific — chatbots, knowledge bases, agents, queues, sandboxes, training — ships as a module.

Modules let ScaiGrid grow without the core growing. You enable the modules you need, you pay for what you use, and new capabilities arrive as new modules rather than as breaking changes to existing ones.

All modules#

Module What it does Docs
ScaiBot Embeddable chatbot platform — configure a bot, drop a script tag, manage conversations and escalations. /docs/scaigrid/scaibot
ScaiBunker Sandboxed compute environments for AI agents — provision short-lived containers, run code, capture artifacts. /docs/scaigrid/scaibunker
ScaiCore Runtime Hosts and manages ScaiCore programs — provisioning, lifecycle, human-in-the-loop checkpoints, plugin install, publish-as-model. Separate from the ScaiCore language peer product. /docs/scaigrid/modules/scaicore
ScaiEcho Speech-to-text with diarization — batch transcription, WebSocket streaming, optional WebRTC signalling. /docs/scaigrid/scaiecho
ScaiLink Desktop MCP gateway and cloud MCP registry — bridge local MCP clients to ScaiGrid, register hosted MCP servers, aggregate tools into one catalogue. /docs/scaigrid/scailink
ScaiMatrix Vector + graph knowledge engine — collections, hybrid search, ingestion pipeline, ACLs. /docs/scaigrid/scaimatrix
ScaiMCP MCP server interface to ScaiGrid — exposes ScaiGrid tools (and ScaiLink-registered remote tools) to MCP-capable clients. /docs/scaigrid/scaimcp
ScaiMind Model training orchestration — REST/gRPC bridge to MindCoordinator for fine-tuning jobs, evaluations, and checkpoint management. /docs/scaigrid/scaimind
ScaiPersona Publishable AI personas — bundle a system prompt, knowledge sources, and a slug; invoke through standard inference. /docs/scaigrid/scaipersona
ScaiQueue Typed message channels — durable queues with consumers, dead-letter handling, and routing rules. /docs/scaigrid/scaiqueue
ScaiSkills Skill catalog and progressive-disclosure bindings — publish reusable skills, bind them to agents, resolve at runtime. /docs/scaigrid/scaiskills
ScaiSpeak Text-to-speech with voice cloning — synchronous and async synthesis, voice library, WebSocket and WebRTC streaming, optional save-to-ScaiDrive. /docs/scaigrid/scaispeak

What a module is#

A module is a self-contained unit that declares:

  • A module ID and version — scaibot, scaimatrix, scaibunker, etc.
  • An API — endpoints mounted under /v1/modules/{module_id}/.
  • Permissions — keys like scaibot:bots:create that can be granted to users.
  • Database tables — migrations run on startup; tables are prefixed to avoid collision.
  • Admin UI pages — pages that show up in the admin navigation under a permission gate.
  • Background tasks — optional cron-style workers for cleanup, monitoring, periodic emissions.
  • MCP tools — optionally, a set of tools exposed to MCP clients.
  • Event handlers — optionally, handlers for ScaiGrid events.

Each of these is optional. A module that only adds a few REST endpoints is valid. A module that only contributes MCP tools is valid.

Listing installed modules#

bash
1
2
curl https://scaigrid.scailabs.ai/v1/modules \
  -H "Authorization: Bearer $TOKEN"
json
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
{
  "data": [
    {
      "module_id": "scaibot",
      "display_name": "ScaiBot",
      "version": "1.0.0",
      "status": "active",
      "admin_pages": [...],
      "permissions": [...]
    },
    ...
  ]
}

Each module returned has a status: active (running and serving requests), error (failed to initialize), or available (installed but not yet enabled for your tenant).

Enabling and disabling#

Modules available at the platform level are usable by all tenants by default. Partners or tenant admins can explicitly disable a module for their scope:

bash
1
2
3
4
5
curl -X POST https://scaigrid.scailabs.ai/v1/modules/scaibot/disable \
  -H "Authorization: Bearer $ADMIN_TOKEN"

curl -X POST https://scaigrid.scailabs.ai/v1/modules/scaibot/enable \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Module enablement is scope-aware — a partner-level disable overrides a tenant-level enable. Most-restrictive wins.

Configuration#

Modules can take tenant-specific configuration:

bash
1
2
3
4
5
6
7
curl https://scaigrid.scailabs.ai/v1/modules/scaibot/config \
  -H "Authorization: Bearer $TOKEN"

curl -X PUT https://scaigrid.scailabs.ai/v1/modules/scaibot/config \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"default_knowledge_top_k": 5, "escalation_email": "support@acme.example"}'

The config shape is module-specific — see each module's reference page.

Permissions#

Module permissions follow {module_id}:{action} naming. Grant them through:

  1. Built-in rolestenant_user includes baseline read-only access for enabled modules.
  2. Direct user grants — grant a permission key to a specific user via the IAM API.
  3. Custom roles — compose a custom role that bundles exactly the module permissions you want.

See Roles and Permissions.

Events between modules#

Modules can emit and handle events on the ScaiGrid event bus. For example:

  • ScaiCore Runtime emits scaicore.activated when a new agent instance starts.
  • ScaiBunker listens for that event and provisions a sandbox if the agent declares a bunker capability.

You don't need to know about these cross-module flows to use the API — they happen server-side. If you're building your own integration, you can subscribe to the event stream. See Events and Webhooks.

Versioning#

Each module is independently versioned. ScaiBot v2 can ship without disrupting ScaiMatrix. Modules have internal APIs (the ScaiGrid framework, other modules' public APIs) but never depend on each other's internal implementation.

When a module is retired, it's marked deprecated with a sunset date — typically months of warning before anything stops working.

Why ScaiCore Runtime sits inside#

ScaiCore Runtime is the one exception to the sub-product pattern. The slug scaicore is held by a peer platform — the ScaiCore language and standalone runtime docs — which is documented by a separate team. ScaiGrid's runtime wrapper (provisioning, lifecycle, checkpoint resolution) is a different surface, so its docs live inside the ScaiGrid namespace at /docs/scaigrid/modules/scaicore.

Enabling and configuring at scale#

For programmatic enable/disable, configuration push, and bulk operations across tenants, see Module administration.

Updated 2026-05-18 15:01:27 View source (.md) rev 11