Core concepts
The vocabulary that runs through the whole product — workspace, agents, the COO, channels, approvals, and the governance layer.
A short glossary. Each concept has its own deep page; this is the map.
Workspace#
The top-level container. Every agent, channel, secret, rule, and audit event belongs to exactly one workspace, and everything is scoped by workspaceId at the query layer. The audit chain is per-workspace. You can create and switch between workspaces; they're isolated from each other.
People: members & operators#
There are two kinds of people in a workspace:
- Members (daily users) chat with agents, run missions, review deliverables, and approve the actions in front of them.
- Operators (owner / admin) do all of that, plus the run-the-workspace work: create agents, set policy, manage skills, secrets, and the governance surface.
The boundary is enforced on the server, not just hidden in the UI. Operators work in two modes, switched from the bottom of the sidebar: Workspace (the everyday app — channels, agents, deliverables) and Console (the governance shell — the Registry, Trace, policy, and a command-center Overview). An operator in Workspace mode sees exactly what a member sees, so there's no separate "preview." Members only ever have Workspace — the Console is invisible to them. The first person to sign up is the operator.
Note — The two-role model covers most teams. Richer, custom role models (fine-grained RBAC) are available as an enterprise capability.
Agent#
An AI worker with its own identity and memory. Each agent is a set of authored files — SOUL.md (who it is), IDENTITY.md, MEMORY.md, KNOWLEDGE.md, and more — plus a chosen model and runtime gateway.
Every agent has an accountable human owner and an optional department. Owner and department are how the Registry answers "who is responsible for this worker."
Note — Edits to an agent's
SOUL.mdor identity are afile_editaction and are never auto-approved — changing an agent's prompt is changing a security boundary, so a human always approves it.
The COO#
A first-class orchestration agent that every workspace has. The COO plans and dispatches multi-agent work (missions, delegations), can propose org-structure and trust changes, and assembles the Daily Briefing. Its channel is open to all members.
Channels#
Where conversation happens — 1:1 DMs with an agent or a person, multi-party group channels, and topic channels.
Ceiling — Member channel access is public OR participant only. Operators get no ambient read of private channels — oversight of conversations is through Trace or by being added as a participant (which is itself audited). "All members" does not mean "all channels."
Approvals#
The pipeline that gates consequential actions before they happen: shell_exec, delegation, skill_tool_call, git_pr, git_merge, skill_install, file_edit, trust_config, and more. An approval shows up as an inline card (approve / deny) with a plain-English summary.
A core set — file_edit, skill_install, trust_config, git_merge, delegation_rule — are BLOCKED_TYPES: never auto-approvable, by design. They each mutate the agent's future behavior or are destructive, so they always stay human-in-the-loop.
Trust (the spine)#
The single idea the whole governance model turns on:
An edge is a standing trust grant. The absence of an edge is not a wall — it's a checkpoint.
If agent A has a standing trust grant to delegate to agent B, that delegation auto-proceeds. If it doesn't, the delegation is still possible — it just gets human-gated every time. You see this on the Team canvas as edges between agents, and you create the standing version of approvals as rules.
The governance layer#
The CISO-facing surface, consolidated under Oversight:
- Registry — an inventory of every AI worker (including ones run outside damn.dev), with owner, access, and a computed gap list.
- Trace — the tamper-evident, hash-chained audit log.
- Policy & enforcement — one governance object per workspace (approval tiers, capabilities, limits) seeded from Regulated / Standard / Open templates, plus
allow/ask/denyrules applied by one kernel everywhere.
Ceiling — Capability enforcement is seeded-gated: it's off until an operator explicitly saves a policy, so a fresh install never breaks itself by enforcing an implicit default.
Next#
- See it work end-to-end in the Quickstart walkthrough.
- Understand the honest security boundary in Enforced vs Trusted.