Skip to main content
Version: latest

agents and roles

An agent in kasmos is a running AI assistant process (claude, opencode, codex, or any CLI tool) that executes a task or lifecycle phase. A role defines what an agent does and which lifecycle phase it is responsible for.

default roles

wizard.DefaultAgentRoles() in internal/initcmd/wizard/wizard.go returns the seven built-in roles in order:

func DefaultAgentRoles() []string {
return []string{"coder", "architect", "reviewer", "planner", "chat", "fixer", "master"}
}
rolephasedescription
coderimplementingimplements tasks; writes and edits code, runs tests
architectelaboratingdecomposes plans into coder-ready task bodies with metadata
reviewerspec_review, quality_reviewchecks correctness, style, and architecture
plannerplanningbreaks features into structured implementation plans
chat(ad-hoc)general-purpose assistant; available in all phases
fixerfixerdebugger and investigator; fixes stuck states and failures
masterverifyingholistic readiness reviewer; spawned when the task enters the verifying status after reviewer approval (enabled by default; disable with auto_readiness_review = false). The master agent applies a materiality triage — trivial findings (typos, format fixes, missing doc comments, total ≤ readiness_self_fix_max_lines net lines) are self-fixed directly in the worktree and approved; only material issues escalate via verify_failed. Every self-fix attempt passes a reviewer-parity static-check gate (gofmt, go vet, go test, typos) before approval. Config alias master_review is accepted for backward compatibility.

agent profile

Each role is configured as an AgentProfile (defined in config/profile.go):

type AgentProfile struct {
Program string // CLI program: "claude", "opencode", "codex", etc.
Flags []string // extra CLI flags
Model string // model identifier, e.g. "anthropic/claude-opus-4-6"
Temperature *float64 // optional temperature (0.0–1.0)
Effort string // "low", "medium", "high" (passed as --effort)
ExecutionMode string // "tmux" or "sdk" ("headless" accepted as legacy alias for "sdk")
Enabled bool // whether this role is active
}

BuildCommand() returns the full command string:

func (p AgentProfile) BuildCommand() string {
return strings.Join(append([]string{p.Program}, p.Flags...), " ")
}

execution modes

modebehavior
tmuxagent runs in a tmux pane; you can attach with /o
sdkagent is driven via its app-server JSON-RPC protocol; output rendered in the preview tab and logs

sdk mode is only effective for claude and codex. for any other program, session.ResolveExecutionMode silently falls back to tmux. sdk mode is preferred for automated wave work (many concurrent tasks) when the agent supports it. tmux mode is better when you want to observe or interact with a single agent.

config.NormalizeExecutionMode() normalizes any unknown value to tmux. the legacy value "headless" is accepted as an alias for "sdk".

phase-to-role mapping

kasmos maps lifecycle phases to role names in .kasmos/config.toml under [phases]. When you run kas setup, the wizard writes defaults based on which harnesses you select:

[phases]
planning = "planner"
elaborating = "architect"
implementing = "coder"
spec_review = "reviewer"
quality_review = "reviewer"
fixer = "fixer"
readiness_review = "master" # drives the verifying status; master_review is accepted as a backward-compat alias

[agents.coder]
program = "claude"
model = "anthropic/claude-sonnet-4-6"
effort = "low"
execution_mode = "sdk"
enabled = true

[agents.planner]
program = "claude"
model = "anthropic/claude-opus-4-6"
effort = "high"
execution_mode = "tmux"
enabled = true

config.ResolveProfile(phase, defaultProgram) looks up the role for a phase and returns the corresponding profile, falling back to defaultProgram if any link in the chain is missing or disabled.

harnesses

A harness is a specific AI CLI tool. The setup wizard supports three built-in harnesses:

harnessdescription
claudeAnthropic Claude Code — effort levels, MCP plugins
opencodeMulti-provider agent — temperature, effort, 50+ models
codexOpenAI Codex CLI — temperature, effort, reasoning config

One harness is configured per role profile. Multiple roles can use the same harness with different models or effort settings.

spawning agents

kasmos spawns agents in two ways:

  • daemon-managed: the daemon starts the agent via the sdk backend or inside a tmux window
  • TUI-launched: the TUI sends a StartPlan request to the daemon socket, which then spawns the agent

The spawned process inherits KASMOS_TASK, KASMOS_WAVE, and KASMOS_PEERS environment variables that inject orchestration context into the agent session.