Skip to content

The agent model

An agent is an AI worker with an identity, skill set, role, persona, and capabilities. Agents are the primary actors in the system — they write code, review PRs, run pipelines, and respond to messages.

Each agent belongs to exactly one workspace. This is a hard invariant: agent.workspaceId is non-null.

Every agent has:

AttributeDescription
nameShort identifier (e.g. “alice”, “reviewer-bot”)
titleHuman-readable role title (e.g. “Senior coder”)
roleEnumerated role: CEO, coder, reviewer, QA, designer, security, devops, PM, general
personaFree-text personality and behavioral instructions
skillsCase-insensitive set of skill identifiers (e.g. “flutter”, “rest-api”)
adapterIdWhich CLI backend to use (e.g. Claude Code, Codex, Pi)
modelIdWhich model within the adapter (e.g. Claude Sonnet, GPT-4o)
effortReasoning effort: low, medium, or high
capabilitiesPer-conversation capability flags (push to repo, GitHub API, ticketing, network egress)
reportsToOptional parent agent ID for reporting hierarchy

Roles serve three purposes:

  1. Behavior — the role influences the system prompt and default persona
  2. Memory access — roles gate which memory domains an agent can read or write
  3. Hierarchy — the reportsTo field builds a reporting chain (e.g. a coder reports to the CEO)

Available roles: CEO (coordination, hiring), coder (implementation), reviewer (PR review), QA (testing), designer (UI/UX), security (security review), devops (infrastructure), PM (product management), general (flexible).

Skills are case-insensitive identifiers that determine which prompts and tool configurations are injected at runtime. For example, an agent with the “flutter” skill receives Flutter-specific context and conventions in its prompt.

Skills are stored as an immutable set on the agent entity and matched during prompt assembly.

Capabilities are per-conversation flags that the credential broker checks at sandbox launch:

  • Push to repo — can the agent push commits to the remote?
  • GitHub API — can the agent call GitHub APIs?
  • Ticketing — can the agent create/update tickets?
  • Network egress — can the agent make outbound network requests?

These are separate from the sandbox’s filesystem isolation — capabilities control API and network access, not file access.

Agents can be:

  1. Seeded automatically — the CEO agent is created when a workspace is created
  2. Hired via the UI — navigate to Agents and click “Hire agent”
  3. Hired via chat — ask the CEO agent to hire a new agent
  4. Imported from disk — Control Center scans for AGENTS.md files that define agent configurations

Discovered agents (found on disk but not yet registered) are surfaced for import in the agent registry.

An agent’s live state is derived from its most recent run logs:

StateMeaning
neverRunThe agent has never been dispatched
idleThe agent has completed its last run
runningThe agent is currently executing
blockedThe agent is waiting for user input or a resource
failedThe agent’s last run ended with an error

This state is computed from AgentRunLog records, not stored directly.