Key Concepts
The mental model for how Corral is organized.
Workspaces
A workspace is the top-level container for everything in Corral. When you first deploy, a workspace is created for your organization. Workspaces are associated with verified email domains — users from your domain are routed to your workspace on login.
A workspace contains projects and apps.
Projects
Projects are containers for organizing apps. Projects can be nested inside other projects. Think of them as folders — they provide structure and grouping, and permissions can be scoped to them.
Apps
An app is a configured AI agent instance. It has:
- An intelligence type — how it reasons (the model, system prompt, and agent behavior)
- Tools — what it can do (built-in tools, MCP connections, OpenAPI integrations)
- Channels — where it’s accessible (Hub, Teams, embedded widget, API)
- Permissions — who can access and configure it
- Versions — published snapshots of its configuration
The two apps created on first deploy — Core Assistant and Sub-Assistant — are both apps.
Assistants & Sub-Assistants
Assistants and sub-assistants are how users experience apps in the Hub.
An assistant is the top-level AI entity a user interacts with. It has a personality (system prompt), its own persistent file system, conversation history, and access to tools. The Core Assistant is the default.
A sub-assistant is a purpose-built workspace created within the user’s AI environment. Each sub-assistant has its own assistant, file system, and conversation state. Sub-assistants are designed for domain-specific work — a “Marketing” sub-assistant might have different tools, context, and system prompt than a “Research” sub-assistant.
Think of it this way: your assistant is your general-purpose AI. Sub-assistants are specialized projects within it.
Environments: Test & Published
Each app has two environments:
- Test — the working configuration. Changes take effect immediately in the Build & Test debug chat.
- Published — a frozen snapshot. This is what users see in the Hub and other channels.
When you publish a version, the current test configuration is snapshotted and becomes the published configuration. Version history tracks every publish.
Channels
Channels are how an app reaches users:
| Channel | What It Is |
|---|---|
| DirectLine | WebSocket-based real-time messaging — powers the Hub and Copilot interfaces |
| Teams | Microsoft Teams integration with app manifest |
| Embedded Widget | Drop-in script tag for customer-facing websites |
| API | Programmatic access via client credentials |
An app can have multiple channels active simultaneously. All channels share the same intelligence configuration and governance model.
Permissions
Permissions are scoped to nodes (projects and apps) in the workspace hierarchy:
| Permission | What It Allows |
|---|---|
| Read | View the app and its configuration |
| ReadAndWrite | Read + modify configuration |
| ReadAndPublish | ReadAndWrite + publish versions |
| ReadAndAssignPermissions | Read + manage who has access |
| All | Full control |
Two global roles exist at the workspace level:
- Management — access to administrative APIs and the admin console
- Workspace.Creator — ability to create new workspaces
Permissions are assigned per-node, not inherited from parent projects.
The Managed Resource Group
When Corral deploys into your Azure tenant, all resources are placed in a managed resource group. This is a standard Azure Managed Application pattern:
- You can see everything inside it in your Azure portal
- Corral can maintain it (push updates, manage configuration)
- The boundary is configurable (full access, just-in-time access, or no access)
- It’s scoped to that resource group — Corral cannot access your broader Azure subscription
See How On-Tenant Works → for the full technical explanation.