Modes

The Kodik agent operates in one of six modes. The mode determines what the agent is allowed to do and which tools it can call. The legacy value "act" is normalized to "code" for backwards compatibility.

Mode restrictions apply to Kodik’s built-in tools. Enabled user-installed MCP tools are available in Code, Plan, Ask, Debug, and Educator and may have side effects defined by their server; per-mode Harness switches and approval settings still apply. Orchestrator has a deliberately smaller coordination-only contract and does not receive MCP tools directly.

Configured sub-agents are available to every parent mode through sub_agent. A sub-agent does not inherit the parent’s mode: its profile owns its instructions, model policy, reasoning effort, and tools. The model policy can name an exact model or use Inherit from parent to follow the parent chat’s effective provider/model. Use Settings → Harness → Sub-agents in this mode to choose which profiles each parent mode may see.

Code (default)

Code is the task execution mode. It is the default for all new tasks.

Behavior: the agent uses all available tools to understand the codebase, make changes, run commands, and verify results. It operates in a visible task worktree. For browser-rendered work, it can verify the result through the Integrated Browser with browser. If the request is materially ambiguous, it may call ask_questions once before proceeding.

Available tools: shell, get_terminal_output, kill_terminal, read_file, codebase_search, edit_file, create_file, delete_file, edit_notebook, rg, glob, ask_questions, read_lints, web_fetch, web_search, todo_write, sub_agent, agent_status, memory, browser

Tip

Use Code when you need something implemented, refactored, or run.

Orchestrator

Orchestrator is a team-lead mode for goals that benefit from specialized sub-agents. Its system prompt is intentionally shallow: it defines the destination, clears user decisions in one grouped question round, delegates substantive work, monitors reports, and verifies the result. The parent does not inspect files, edit, run commands, browse, or call MCP tools itself.

Behavior: Orchestrator sees a compact catalog of usable sub-agent profiles and chooses a profile—not a model—for each bounded task. Profile settings supply an exact sub-agent model or the Inherit from parent policy, plus optional reasoning effort, instructions, and tools. Independent tasks can run in parallel. Planning is delegated to Planner, which publishes a structured Team Workspace draft. The Orchestrator can accept routine plans itself, ask Planner for a revision, or use request_plan_approval when the route needs user authority. You can then approve it, request changes with grouped feedback, or cancel it without switching modes.

State-changing work must later be verified by a separate built-in Reviewer, Test Engineer, or QA Engineer. Plans and sub-agent reports are persisted in the session’s Team Workspace so they survive compaction and reload.

Available tools: sub_agent, agent_status, ask_questions, request_plan_approval, todo_write, and team_workspace, plus goal tools when the chat has an attached persistent goal. create_plan is sub-agent-only and normally belongs to Planner.

Note

You can switch modes while an orchestrated task is active. Kodik shows the existing mode-change warning, but the decision and its effect on the workflow remain yours.

Plan

Plan keeps Kodik’s built-in workspace tools read-only. The agent explores the code, asks clarifying questions if needed, and saves a final plan via the generate_plan tool.

Plan uses todo_write for the live session checklist and generate_plan for the final reviewable plan. You can disable either tool independently for Plan in Harness.

Behavior: the agent does not edit files, create files, or run state-modifying commands. It builds a step-by-step implementation plan, notes risks and open questions, and optionally includes a Mermaid diagram in generate_plan. Questions are only asked through ask_questions — never as plain chat text.

Available tools: read_file, glob, rg, codebase_search, read_lints, web_fetch, web_search, ask_questions, todo_write, generate_plan, sub_agent, agent_status, memory, browser

Note

After the plan is saved, switch to Code mode to start implementing. See Planning.

Ask

Ask keeps Kodik’s built-in workspace tools read-only for questions about the codebase: architecture, behavior, tradeoffs.

Behavior: the agent answers questions by reading the relevant code first. It does not run commands or edit files. If the user asks for an implementation, the agent explains that Ask mode is for analysis only and that they should switch to Code.

Available tools: read_file, glob, rg, codebase_search, read_lints, web_fetch, web_search, todo_write, ask_questions, sub_agent, agent_status, memory, browser

Debug

Debug is a hypothesis-driven debugging mode that separates diagnosis from the fix.

Behavior: the agent follows a strict workflow:

1. Generates 3–5 precise hypotheses about why the issue occurs.
2. Adds targeted instrumentation to distinguish those hypotheses.
3. When necessary, asks the user to reproduce the issue with numbered steps.
4. Collects runtime evidence from logs, command output, and tests.
5. Classifies each hypothesis as CONFIRMED, REJECTED, or INCONCLUSIVE.
6. Implements only the smallest fix supported by confirmed evidence.
7. Verifies the fix with fresh evidence and removes temporary instrumentation.

The agent never declares a fix without actual runtime evidence.

Available tools: shell, get_terminal_output, kill_terminal, read_file, codebase_search, edit_file, create_file, delete_file, edit_notebook, rg, glob, ask_questions, read_lints, web_fetch, web_search, todo_write, sub_agent, agent_status, memory, browser

Caution

Debug and Code have the same tool set, but Debug requires hypotheses and evidence before any change. Do not use Debug for ordinary implementation tasks.

Educator

Educator is a teaching mode built on top of Ask, adding check_understanding for quick checks and create_lesson for richer interactive lessons.

Behavior: the agent explains concepts progressively, grounds explanations in actual code, and uses worked examples and simple mental models. It may call check_understanding with 1–3 concise questions to tailor the next step of the explanation. When hands-on practice would help, it can create a self-contained HTML lesson, save it under .kodik/teach/<topic>/, and open it automatically in the Integrated Browser beside chat. Kodik brings the lesson’s window.__kodikLesson activity back into the next educator turn, including quiz answers, code edits, and task completion, so you do not have to copy answers into chat. Incorrect answers are treated as diagnostic signals, not failures.

Available tools: all Ask tools plus check_understanding and create_lesson. The browser tool has the same complete action set as every other mode when enabled in Harness.

Note

Educator’s built-in workspace tools do not modify project files. Their only project write surface is the hidden .kodik/teach/<topic>/ teaching workspace, which stores generated lessons and learning notes. Browser interactions can affect the page or external service being controlled and follow the normal approval policy. Enabled MCP tools remain available separately and may have server-defined side effects. When you return later, educator mode reads those saved records to resume from the learner mission and prior lessons. Switch to Code for implementation work with Kodik’s built-in workspace tools.