Transparency and approvals

What this accomplishes

The option matrix (decision cards), the agent’s options before a non-trivial change, the sub-agent dashboard, the cost and time ceilings that auto-cancel when tripped.

Before a non-trivial change, the agent shows its options and waits for your choice. While it runs — and while sub-agents run — you can see tool calls, progress, and cost.

This guide covers transparency and approvals. Plan-only work is in plan mode; sub-agents are in sub-agents; spend is in cost and budget.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build and an active project containing source code.
• A connected model. Trust the project before allowing file, terminal or Git actions.

The option matrix

When the agent encounters a task with two or more meaningfully different approaches, it shows an option matrix (decision cards) before acting. The option matrix is implemented by OptionMatrix.tsx.

Each option card shows:

The user selects one option; the agent proceeds with that approach. The user can also dismiss the matrix to let the agent pick the highest-confidence option. The matrix only appears when the agent’s confidence in any single option is below a threshold; for straightforward tasks, the agent proceeds without showing options.

The option matrix is per-session. A user who has two sessions has two independent option matrices; the selections are preserved per session.

The agent’s options

The agent’s options are the alternative approaches the agent considered before choosing the recommended approach. The options are shown in the plan mode surface, in the approach rationale section. The user can expand the rationale to see the full set of options.

The options include:

• The chosen approach — the approach the agent is recommending.
• The alternative approaches — the approaches the agent considered and rejected.
• The trade-offs — the trade-offs between the chosen approach and each alternative.
• The reasoning — the agent’s reasoning for why the chosen approach is the right one.

The user can pick a different approach by rejecting the chosen approach and asking the agent to use a different approach. The agent re-plans with the new approach; the user sees the new plan.

The sub-agent dashboard

The sub-agent dashboard is a CoW panel that shows all running and historical sub-agent runs. The panel lists each run with:

• Sub-agent name — the sub-agent’s name (Explorer, Verifier, Debugger, Test Runner, Orchestrator, or a user-defined name).
• Status — running, succeeded, failed, suspended.
• Started at — the timestamp the run started.
• Duration — the elapsed time the run has been running (or ran, for historical runs).
• Cost — the model cost for the run, in the user’s preferred currency.
• Sub-agent session — a link to the sub-agent’s session log.

The user can inspect a run’s current status, cost and time limits, and cancel work that should not continue.

The sub-agent dashboard is per-session. A user who has two sessions has two sub-agent dashboards; the dashboards are preserved per session.

The cost and time ceilings

The cost and time ceilings are the limits on the agent’s spend and time. The user can configure a per-session, per-day, or per-week ceiling. When the ceiling is reached, the agent pauses and asks the user to confirm the next turn’s spend.

The cost ceiling is in the user’s preferred currency. The time ceiling is in minutes. The ceilings are visible in the cost surface; the user can see the running total and the projected total.

When a ceiling is reached, the agent pauses and shows a confirmation prompt. The user can:

• Confirm — continue the agent’s run. The agent’s cost is added to the running total.
• Raise the ceiling — increase the ceiling for the session. The user enters a new ceiling value; the agent’s run continues.
• Lower the ceiling — decrease the ceiling for the session. The user enters a new ceiling value; the agent’s run continues with the lower ceiling.
• Remove the ceiling — disable the ceiling for the session. The agent’s run continues without a ceiling.
• Cancel the run — cancel the agent’s run. The agent’s work is discarded.

The ceilings are per-session. A user who has two sessions has two ceiling configurations; the ceilings are preserved per session.

The agent’s tool calls

The agent’s tool calls are visible in the chat metadata. The user sees every tool call the agent made, the tool’s input, the tool’s output, and the tool’s duration. The user can click a tool call to see the full input and output.

The tool calls are visible in real time. As the agent makes a tool call, the tool call appears in the chat metadata. The user can pause the agent mid-tool-call (the tool call completes, then the agent pauses); the user can also cancel the agent’s run mid-tool-call (the tool call is cancelled, the agent’s state is rolled back).

The tool calls are the audit trail for the agent’s actions. The user can use the tool calls to debug a failure (which tool call failed, what was the tool’s input, what was the tool’s output), to verify a compliance posture (which tools did the agent call, did the agent call any tools it should not have), to document the agent’s behaviour, or to share a session with a collaborator.

What transparency does not cover

Transparency does not cover:

• Model internals — the user sees the agent’s input to the model, the agent’s output from the model, and the agent’s estimated cost. The user does not see the model’s internal reasoning, the model’s hidden state, or the model’s training data.
• Sub-agent internals — the user sees the sub-agent’s session log. The user does not see the sub-agent’s prompt-engineering details, the sub-agent’s retry logic, or the sub-agent’s fallback behaviour.
• Tool internals — the user sees the tool’s input and output. The user does not see the tool’s internal state, the tool’s configuration, or the tool’s dependency graph.

The transparency is at the boundary of the agent’s decision-making. The user sees what the agent does, not how the agent does it. The “how” is in the architecture docs; the “what” is in transparency and approvals.

What success looks like

Transparency is the user-facing surface of the agent’s decision-making. The user sees the agent’s options, the agent’s tool calls, the agent’s sub-agents, and the agent’s cost.

The option matrix is the right shape for non-trivial changes. The agent presents decision cards with approaches, pros, cons, cost, and time estimates; the user picks one approach.

The cost and time ceilings are the user’s guardrails. The user sets the ceiling; the agent pauses when the ceiling is reached. The user can confirm, raise, lower, remove, or cancel at the pause.

The sub-agent dashboard is the audit trail for the sub-agents. The user can see every sub-agent’s session, every sub-agent’s tool calls, and every sub-agent’s cost. The user can pause, resume, or cancel a running sub-agent.

Common failures and recovery

• Confirm the correct project and branch are active.
• Check the model connection and the permission request shown in Chat.
• Keep the exact error before retrying; use Code troubleshooting when the failure persists.

Related next action

Open Code troubleshooting for recovery steps and diagnostic paths.