Capabilities overview
A capability is anything a turn can reach that an administrator chooses per scope. Cengrid’s core is generic; everything specific to your company is added as capabilities, and most of them come from GitHub repositories you connect.
The eight kinds
Section titled “The eight kinds”| Kind | What it gives the agent | Defined by | Page |
|---|---|---|---|
| Instruction | Standing guidance applied on every turn in a scope, such as company voice or release rules | instructions/<name>/INSTRUCTIONS.md |
Instructions |
| Skill | A playbook the agent reads when a task calls for it, with optional supporting files | skills/<name>/SKILL.md |
Skills |
| Agent | A named specialist with its own prompt and model settings, run as a workflow step | agents/<name>/AGENT.md |
Agents |
| MCP server | Tools discovered from a remote Model Context Protocol server | mcp.json |
MCP servers |
| Connection | A credentialed route to a REST API or a Git host, brokered by core | connections.json |
Connections |
| Environment | The CLIs and runtimes installed on a conversation’s computer | environments/<key>/environment.json |
Environments |
| App | A small web app Cengrid builds or publishes for your people | apps/<name>/app.json |
Apps |
| Playbook | A recipe the planner follows for a kind of request, such as shipping a software change | playbooks/<name>/PLAYBOOK.md |
Playbooks |
A plugin can ship any mix of these. A plugin that ships none is still valid.
Scopes decide who gets what
Section titled “Scopes decide who gets what”Capabilities are defined in three kinds of scope:
| Scope | Id | Who it covers |
|---|---|---|
| Organisation | org:<id> |
Everyone in the deployment |
| Team | team:<id> |
The rooms and members of one team |
| Person | personal:<id> |
One person’s direct messages |
A room (room:<platform>:<ref>) in a team has no capabilities of its own: a turn in it reads the organisation and the room’s team. A room that has not been put in a team reads the organisation and the room itself. A direct message reads the organisation, the person’s primary team and the person. See teams and rooms.
Cengrid resolves a capability by walking that chain from the nearest scope outward, twice:
- Definition. The nearest scope that holds an entry supplies it.
- Decision. The nearest scope that holds an on/off override decides whether it is in use. With no override anywhere, it is on.
Because the two walks are separate, a team can switch off something the organisation added, without owning or deleting it, and the switch survives the next sync.
Added and Available
Section titled “Added and Available”Every capability page in the admin console has two views for the selected scope:
- Added lists what the agent can use in that scope. Teams also see inherited organisation items, labelled as coming from the organisation.
- Available lists what connected plugins offer that nobody has added yet. Connecting a plugin never enables anything on its own.
The usual flow is:
- Connect a GitHub repository as a plugin, or link a marketplace.
- Open the capability page and choose Available.
- Add the item to the organisation or to a team.
Manage capabilities covers switches, removal, locks and re-sync.
Where else capabilities come from
Section titled “Where else capabilities come from”- Custom items. Administrators create skills, agents, MCP servers, connections, environments and playbooks directly in the console. Instructions come only from plugins. The agent can also create skills in the bucket of the scope it is working in, and save a person’s own environments from their direct message.
- Deployment layer. A deployment directory can ship skills and agents, which are seeded at the organisation scope. See the deployment directory.
- Starter skills. With
SEED_SKILLS=true(the default), core installs a starter catalog at startup, including Google Workspace, Drive and Sheets, Linear, GitHub and GitLab, memory, publishing and morning digest skills.