Kits
System/org/project kit scoping, entitlement, and repo auto-detect.
Kits bundle a toolchain, system prompt, and tool permissions into the versioned execution environment an agent runs in (see Host Kit for the kit concept itself, which is OSS-canonical). This page covers the platform governance layer on top of that: which kits an organization is entitled to, where they're mounted, and how a repo gets matched to one automatically.
Scopes
A kit can be mounted at three scopes, each visible in a different surface:
| Scope | Where it's managed | Who sees it |
|---|---|---|
| System | /admin/kits (platform operator) | Every organization, unless overridden |
| Org | Org Settings → Kits (self-serve) | Every project in that organization |
| Project | Project resources (kit-provider node's project-default) | That project only |
The vendored donmai-kits catalog snapshot (7 kits at GA) is the source of truth for what a kit is - version, toolchain, order (foundation / framework / project); mounts are what make a catalog kit available at a given scope.
Entitlement
Every kit in the catalog carries a kit.<id> feature flag, resolved the same way plugin.* node-delivery flags are resolved (resolveOrgFeatures / isFeatureEnabled off plan_definitions.featureFlags → organizations.features) - there is deliberately no separate kit-enablement mechanism. At GA, every kit is entitled on every plan (default-allow); no deny flags are in use.
Org Settings → Kits
The org-scoped page (self-serve, no operator involved) lists the full catalog with, per kit:
- Entitled - whether the org's plan allows this kit (badge; default-allow at GA, so this is normally green).
- Mounted - whether the org has actually attached the kit. Mounting is a separate step from entitlement, so an org can be entitled to a kit without every project picking it up as a default.
From here you can mount/unmount org-scope kits directly, or use Detect from repo - it calls the repo-detection endpoint, which scans a connected repository's files and returns kitId suggestions (a Go-parity port of the same matcher rensei CLI's local kit detect uses), flagging any foundationConflict (e.g. suggesting both a Node and a Python foundation kit) so you don't mount two conflicting foundations.
/admin/kits (platform operator)
The operator-only admin surface lists the full catalog plus every kit_mounts row across all scopes and organizations, with controls to mount a system-scope kit (available to every org unless a narrower mount overrides it) and unmount any row. Same list-plus-mutate shape as the agent-registries admin page.
Kit mounts API
| Endpoint | Description |
|---|---|
GET /api/org/kits | Catalog + this org's entitlement/mount state |
POST /api/org/kits · DELETE /api/org/kits/[id] | Mount / unmount a kit at org scope |
GET /api/admin/kits · POST · DELETE /api/admin/kits/[id] | Operator: catalog + all mounts; mount/unmount at system scope |
POST /api/projects/[projectId]/kits/detect | Scan a connected repo and suggest kit matches |
Using a kit in a workflow
Wire a kit-provider foundational node into the Agent Composer's kits port. If you leave a project's kit unset, it falls back to the project's primary kit default (project_resources(role='primary', kind='toolkit') → org default → none) - see Node Config Panels § Inherited defaults.
Monorepo multi-kit detection (attaching more than one kit to different paths within a single repo) is not yet built - detect returns suggestions for the repo as a whole, not per-subdirectory. Tracked as post-GA scope.
Related pages
- Host Kit - the OSS kit concept, manifest schema, and CLI lifecycle
- Node Config Panels - project-default resolution for kit/credential/capacity/capabilities
- Foundational Nodes - the
kit-providernode