---
summary: "Every ScaiGrid module \u2014 what they are, how to enable and configure\
  \ them, and the full catalogue with links to each module's documentation."
title: Modules
path: modules
status: published
---

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](/docs/scaigrid/scaibot) |
| **ScaiBunker** | Sandboxed compute environments for AI agents — provision short-lived containers, run code, capture artifacts. | [/docs/scaigrid/scaibunker](/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](/docs/scaicore) peer product. | [/docs/scaigrid/modules/scaicore](/docs/scaigrid/modules/scaicore) |
| **ScaiEcho** | Speech-to-text with diarization — batch transcription, WebSocket streaming, optional WebRTC signalling. | [/docs/scaigrid/scaiecho](/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](/docs/scaigrid/scailink) |
| **ScaiMatrix** | Vector + graph knowledge engine — collections, hybrid search, ingestion pipeline, ACLs. | [/docs/scaigrid/scaimatrix](/docs/scaigrid/scaimatrix) |
| **ScaiMCP** | MCP server interface to ScaiGrid — exposes ScaiGrid tools (and ScaiLink-registered remote tools) to MCP-capable clients. | [/docs/scaigrid/scaimcp](/docs/scaigrid/scaimcp) |
| **ScaiMind** | Model training orchestration — REST/gRPC bridge to MindCoordinator for fine-tuning jobs, evaluations, and checkpoint management. | [/docs/scaigrid/scaimind](/docs/scaigrid/scaimind) |
| **ScaiPersona** | Publishable AI personas — bundle a system prompt, knowledge sources, and a slug; invoke through standard inference. | [/docs/scaigrid/scaipersona](/docs/scaigrid/scaipersona) |
| **ScaiQueue** | Typed message channels — durable queues with consumers, dead-letter handling, and routing rules. | [/docs/scaigrid/scaiqueue](/docs/scaigrid/scaiqueue) |
| **ScaiSkills** | Skill catalog and progressive-disclosure bindings — publish reusable skills, bind them to agents, resolve at runtime. | [/docs/scaigrid/scaiskills](/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](/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
curl https://scaigrid.scailabs.ai/v1/modules \
  -H "Authorization: Bearer $TOKEN"
```

```json
{
  "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
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
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 roles** — `tenant_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](/docs/scaigrid/core-concepts/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](/docs/scaigrid/core-concepts/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](/docs/scaicore) — 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](/docs/scaigrid/reference/modules-admin).