Date: 2026-09-11 Date: 2026-09-10

​
Specialised agents

Use this lesson to build a practical, evidence-based Nova workflow for this topic.

​
What an agent is

A specialised agent is a short-lived Nova runtime with its own context, focused system prompt, tool permissions, model choice, and optional skills or MCP access. It handles a bounded task and returns a result to the parent session. By default it still uses the parent’s workspace; filesystem isolation requires an explicitly requested managed Git worktree. Agents are useful when context separation improves accuracy or efficiency. They are not a reason to delegate every small search.

​
Built-in roles

Kore-CLI includes profiles for common engineering work:
  • Explore — fast, read-oriented repository discovery.
  • Research — read-only web and repository research with evidence.
  • Verification — code review, defensive security analysis, failure reproduction, and test validation.
  • Planner — implementation architecture and trade-off analysis.
  • Supernova — general multi-step implementation with read, write, shell, and delegation capabilities.
Additional product or organisation-specific agents may be available in a session. The authoritative list appears in /agents and in Nova’s active tool description.

​
When delegation helps

Use an agent when:
  • Architectural coupling or uncertainty makes isolated exploration valuable.
  • A read-only reviewer should independently assess an implementation.
  • External research needs several sources and should not flood the main context.
  • A large task has genuinely independent, non-overlapping workstreams.
  • A custom workflow requires a restricted tool or MCP surface.
Keep work in the parent session for focused searches, routine fixes, repetitive edits, and tasks whose context is already loaded.

​
Inspect and switch agents

Use:
/agents use changes the active agent prompt for subsequent interaction. It is distinct from spawning a short-lived child agent for one delegated task. The command also supports interactive creation, editing, and deletion of user-defined agents:

​
Agent definition locations

Markdown agent definitions are discovered with this priority:
  1. Project agents in .compass/agents/*.md.
  2. Agents passed through the --agents CLI option.
  3. User agents in ~/.compass/agents/*.md.
  4. Built-in agents.
A higher-priority definition can override another agent with the same name.

​
Agent file format

An agent is a Markdown file with YAML frontmatter and a prompt body:
The supported frontmatter includes name, description, tools, disallowedTools, model, permissionMode, questionRouting, skills, standalone, and mcpServers. Omitting tools causes a user-defined agent to inherit the main conversation’s tool set. Prefer an explicit restricted set when the role should be read-only.

​
Capability validation

When Nova spawns a child, the request declares every capability required by the task, such as repository reading, shell use, file writing, web access, user-question routing, or further delegation. The runtime rejects an agent whose allowed tools cannot satisfy the requested capabilities. A good delegated task includes:
  • A precise objective.
  • Relevant paths, snippets, logs, or other context.
  • Evidence targets.
  • Required capabilities.
  • A bounded return format.
  • Acceptance criteria for the parent session.

​
Background and parallel work

A child can run in the background while the parent continues. Nova then polls the process and collects the result before relying on it. Parallel spawning should be limited to independent workstreams. Two agents editing the same subsystem create coordination cost and conflicting assumptions. The parent must state which findings were accepted, rejected or uncertain, resolve conflicts, and synthesise one decision.

​
Worktree isolation

A root agent spawn can request a managed Git worktree. This is useful when implementation must remain isolated from an already dirty repository. Nested agents inherit the same workspace rather than creating further worktrees. Worktree creation and finalisation are approval-sensitive. Isolation does not remove the need to inspect or preserve user changes.

​
What you learned

You can now apply the core practices in this lesson during a Nova session.

​
Try it yourself

Use this lesson’s guidance in a small, non-destructive task in a local project, then review the result before continuing.

​
Continue the course