Skip to content

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.

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.

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:

  1. Definition. The nearest scope that holds an entry supplies it.
  2. 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.

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:

  1. Connect a GitHub repository as a plugin, or link a marketplace.
  2. Open the capability page and choose Available.
  3. Add the item to the organisation or to a team.

Manage capabilities covers switches, removal, locks and re-sync.

  • 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.