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

​

How Nova works

Learn how Nova turns a request into evidence-based work while keeping tool access controlled.

​

The agent loop

Nova combines a language model with a controlled tool runtime. The model does not directly manipulate the operating system. It decides which registered tool to call, supplies structured arguments, receives the result, and continues reasoning from that evidence. A typical turn follows this sequence:

1. Nova receives the user’s request plus system, organisation, project, and session context.
2. It decides whether the request needs explanation, repository inspection, direct action, planning, or delegation.
3. It calls focused tools such as filename search, code search, file reading, editing, Git inspection, or shell execution.
4. The runtime validates the request and applies approval policy before sensitive work.
5. The tool result returns to the model.
6. Nova repeats the loop until it has met the observable success criteria or reaches a genuine blocker.

This loop explains why a useful engineering session may contain several small searches and reads before any edit occurs.

​

Context construction

The model’s effective context is assembled from multiple layers:

• Nova’s built-in behavioural and safety instructions.
• Organisation rules and data-disclosure policies when configured.
• Agent-specific instructions.
• Hierarchical NOVA.md files and .compass/rules/*.md modules.
• Relevant saved memory and session continuity.
• The current conversation.
• Tool definitions and recent tool results.
• Explicit file, image, or document content supplied by the user.

Context is finite. Nova therefore uses targeted retrieval rather than loading an entire repository into every request.

​

Tool boundaries

Tools expose narrowly defined operations. Important categories include:

• Repository reading — find files, search code, inspect dependencies, and read targeted sections.
• Repository writing — create, edit, move, or delete files.
• Execution — run short-lived commands, tests, and builds; start long-running processes only through background execution.
• Git — inspect state and history, stage files, commit, and push.
• Workflow — create plans, ask structured questions, and delegate to specialised agents.
• External integrations — call MCP-backed systems such as knowledge, email, calendar, or document services when available.

Each tool has an input contract. The runtime can reject malformed, disallowed, or insufficiently approved calls before they affect the workspace.

​

Approval and autonomy

Nova separates reasoning from permission. An operation can be technically appropriate yet still require human approval. The approval manager classifies operations such as file creation, modification, deletion, shell execution, Git commit, Git push, database execution, and worktree actions. The manual and auto options determine when eligible operations are approved automatically, while high-impact actions remain guarded by policy. Interactive sessions expose /approve to set manual or auto approval. Approval policy is separate from task execution strategy: Nova can execute clear work directly or enter its approval-gated plan workflow for complex implementation.

​

Planning runtime

For complex implementation work, Nova can create a structured plan before editing. Plan mode is not just a prose checklist: the runtime records plan state, asks for approval, tracks task completion, and supports resuming the first incomplete task. For clear, low-risk work, direct execution is faster. The distinction is based on uncertainty, architectural coupling, migration risk, and reversibility rather than the apparent length of the request.

​

Specialised agents

Nova can spawn isolated agents for bounded work. Each agent has a declared capability profile, such as repository exploration, web research, verification, planning, or implementation. The parent session supplies the objective and expected deliverable, then accepts, rejects, or qualifies the returned findings before using them. Isolation prevents every exploratory detail from crowding the main conversation and allows independent workstreams to run in parallel when they genuinely do not overlap.

​

Providers and models

Nova is not tied to a single model endpoint. The Kore-CLI implementation supports Compass-managed models, Anthropic-compatible providers, OpenAI chat and responses flows, OpenAI OAuth where available, and registered custom endpoints. Provider selection changes model access, but Nova’s tool runtime and project workflow remain the surrounding execution layer.

​

Sessions and observability

Nova persists session information under Compass-managed storage. It can list or resume archived project sessions, compact long conversations, report context and token usage, emit structured system events, and expose a local dashboard. These facilities make long-running work inspectable rather than ephemeral.

​

What you learned

• Nova selects registered tools through a controlled runtime rather than directly manipulating the system.
• Context is assembled from scoped sources and is intentionally finite.
• Approval policy and implementation strategy are separate decisions.

​

Safe practice exercise

Ask Nova to explain which repository-reading tools it would use to inspect an unfamiliar feature, then ask it not to edit anything.