Skip to content

Orgabot is in private alpha. Request access, or join our Discord.

← All documentation
The organization

Capability packs

A capability pack is the job training you install into a role: knowledge, procedures, and declared tool needs. It is knowledge-only: a pack never grants access by itself.

The one-sentence definition

A capability pack is the job training you install into a role: the knowledge, procedures, and declared tool needs of that job, packaged so it can be added, removed, and audited.

The load-bearing half of that sentence is what a pack is not: a pack is knowledge-only. Installing one never grants a credential, a connector, a tool, or any authority. It tells a role how its job is done and what kind of tool that job needs, and then a separate, explicit, approved grant decides whether the role actually gets such a tool.

Why the separation exists

If installing a pack also granted its tools, then "train this role" and "give this role production access" would be the same action, and a template that adds ten roles would silently widen your blast radius ten ways. Orgabot splits them so that:

  • training is cheap and reversible: add and remove packs freely;
  • access is deliberate: every grant is explicit, scoped, revocable, and audited;
  • an agent can never widen its own authority by reading, writing, or installing a document.

This is the same principle as the broker: natural language confers no authority.

What is inside a pack

PartWhat it doesGrants anything?
KnowledgeDomain facts and reference material the role should work fromNo
ProceduresHow this job gets done: the steps a competent hire would followNo
Expected artifactsWhat the role is supposed to produce (a deployment plan, a reliability review, a runbook)No
Escalation handlingWhat to do when blocked, and who to route toNo
Declared tool needsRequisite capability categories such as "source control", "code scanning", or "social publishing"No. A declaration, not a grant.
ProvenanceWhere the pack came from: builtin, user, or importedNo

Capability categories and tool slots

A pack asks for a kind of tool, not a product. That is the capability category. You then fill that slot with whichever provider you actually use:

orgabot role pack add <org> <role> <pack-ref> [--provenance builtin|user|imported]
orgabot role slot fill <org> <role> <category> <connector-id>
orgabot role pack rm <org> <role> <pack-ref>

Slot filling is descriptive: it records that this adopted connector is the one meant to satisfy that declared need. It still grants nothing on its own: the grant is orgabot role connector grant / orgabot role tool grant, and a sensitive one routes through the approval queue for independent least-privilege review. See Connectors and tools.

orgabot doctor reports slot fill, so an unfurnished role (one declaring needs that nothing satisfies) is visible rather than surprising you mid-mission.

Where a pack shows up at run time

When a role owns a mission, its pack contents are injected into the mission brief as labeled, trust-classified context: role mandate, procedures, expected artifacts, the organization's handling procedure for missing capabilities, and the current brokered connector list. The worker reads that as guidance. It reads repository text and issue text as data. Neither can hand it authority.

  • Compliance pack: a knowledge and policy pack applied to specific roles: orgabot compliance add <org> <name> --applies-to <role,role>.
  • Capability plugin: a structured, dashboard-editable capability surface, preserving the same knowledge-only invariant. The Channel Playbook (per-channel voice and guidance for social channels) is the first one. A general plugin registry is still pending.
  • Template: a bundle of roles, not of knowledge. Additive and idempotent; requests connections by category and grants nothing.

Guided repair

Packs can declare references that do not resolve: a role furnished with a pack or policy reference that never existed. That class of bug has its own inline diagnosis and one-click repair path, so an unfurnished role can be fixed from the dashboard rather than debugged from a mission log.

Mental model to keep

capability pack   →  "here is how your job is done, and what kind of tool it needs"
capability slot   →  "this specific connector is the tool we mean"
grant             →  "you may actually use it, at this scope, until this expiry"
broker + gate     →  "and here is the only path through which you may use it"

Four separate steps, four separate records, four separate places to say no.