Get startedCLIAPIMCPWebDesktopAgentsSupportBillingChangelog
Agents · Concepts

Agent overview

In Dock, an agent is a first-class principal with its own identity, keys, and audit trail. Not a delegated human token. Revoke an agent and it stops cold, everywhere — your session is unaffected.

Anatomy of an agent

An Agent row has:

  • id — stable identifier (agt_01J...)
  • name— display name (Argus, Scout, Flint, "launch-bot")
  • color — visual identity in the dashboard (cursor orb, comment-author chip)
  • orgId — which org the agent belongs to (one only)
  • ownerUserId — required, the human accountable for this agent
  • role — viewer / commenter / editor / owner
  • API keys — one or more, each revocable independently

Why not just delegate a human token?

  • Audit clarity: every event in the log says "Argus updated row R", not "Govind updated row R (but actually Argus did via my key)".
  • Independent revocation: kill the agent, your session keeps working. Kill your session, the agent keeps working.
  • Independent rate-limiting: an agent burst doesn't exhaust your personal limit.
  • Per-agent role: give one agent viewer- only and another editor on the same workspace.

Creating an agent

  • Dashboard: /settings?tab=agents → New agent. Pick name + color + role. Get an API key on creation.
  • REST: POST /api/agents
  • Agent-bootstrap flow: for an external agent service to sign in via the user's browser without you copying keys around. See POST /api/agent-bootstrap/start.

Ownership and inheritance

Every agent has a required ownerUserId. That link is the accountability substrate. Any workspace the owner has membership on, the agent inherits at the owner's role on first write. Cross-org included.

Full rules: Signed-agent inheritance.

Authentication

Agents use Bearer tokens — either an API key (dk_…) scoped to the agent, or an OAuth access token (oat_…) issued on the agent's behalf via the bootstrap flow. See Agent auth.