Skip to main content
Lesson 10 of 14 · Mistral Vibe Advanced: Agents, Skills, and Local Mode

Multi-choice clarification system

Lesson 10 of 14 Updated November 2, 2026 Advanced
On this page
  1. When Vibe asks before acting
  2. The three situations that trigger a question
  3. Tuning the cursor agent by agent
  4. The special case of subagents
  5. Key takeaways

Lesson updated November 2, 2026. Example agent files now use keys documented by Vibe: instructions (not system_prompt), active_model (not model), [tools.<tool>] blocks for approvals (the auto_approve key does not exist in an agent file), and real tool names (edit, not edit_file; no list_dir tool). Reminder from Lesson 3: safety is a visual indicator, not a permission. Source: Configuration reference.

When Vibe asks before acting

Mistral Vibe isn’t a tool that blindly executes your instructions. When a request is ambiguous or multiple approaches are defensible, the model may present options before proceeding: this is the multi-choice clarification system. The mechanism relies on a built-in tool, ask_user_question, available to agents but not subagents, and it works in two ways.

In programmatic mode (vibe --prompt …), Vibe disables interactive tools like ask_user_question: no one is there to answer. An agent designed to run unattended must, like a subagent, find default choices in its instructions.

The first is multiple choice: Vibe lists numbered options and you respond with a number or the option text. It’s fast and unambiguous, making it the default format whenever a finite number of reasonable answers exist.

Vibe: Which test framework do you use?
  1. Vitest
  2. Jest
  3. Mocha
  4. Pytest
  5. Other (specify)

The second is free-text input, reserved for questions where the answer can’t be guessed: a table name, an identifier, a path. Vibe then expects a text response.

Vibe: What is the name of the database table to migrate?
> users_profiles

The three situations that trigger a question

The first trigger is pure ambiguity. You ask to refactor “the login component” when the repo contains two; rather than bet on one and hand you work to throw away, Vibe lets you decide. Notice the third option, which avoids back-and-forth when the answer is “both.”

You: Refactor the login component

Vibe: I identified two login-related components:
  1. src/components/LoginForm.tsx (form)
  2. src/components/LoginModal.tsx (modal)
Which one do you want to refactor?
  3. Both

The second trigger is a plurality of technical approaches. Adding validation to a form introduces a dependency that will stay in the project for years; this kind of decision belongs to you, not the model.

You: Add validation to the form

Vibe: Which validation approach do you prefer?
  1. Zod (schema validation, TypeScript typing)
  2. Yup (declarative validation, Formik ecosystem)
  3. Manual validation (no library)
  4. Valibot (lightweight, tree-shakable)

The third is a high-impact decision. A seemingly mundane request—“update dependencies”—can hide a major version change. Vibe then ranks options from safest to riskiest, explicitly stating the risk level of each.

You: Update dependencies

Vibe: Updating React 18 → 19 is a major change.
  1. Update patches only (safe)
  2. Update minors (low risk)
  3. Update everything, including majors (verification required)

Tuning the cursor agent by agent

This behavior isn’t automatic: it depends on what you authorize. For an agent to question you, ask_user_question must appear in its allowed tools.

display_name = "Careful Developer"
safety = "neutral"

enabled_tools = [
  "read_file",
  "write_file",
  "edit",
  "grep",
  "ask_user_question"  # Enables clarifications
]

[tools.write_file]
permission = "ask"

[tools.edit]
permission = "ask"

Conversely, an agent designed to run without supervision—in a pipeline, overnight, or simply for repetitive work you don’t want to arbitrate—must be deprived of this tool. Removing ask_user_question isn’t enough, though: without fallback instructions, the agent would stall or choose at random. The system prompt must therefore tell it what to do instead.

display_name = "Silent Worker"
safety = "neutral"

instructions = """
Never ask questions. In case of ambiguity:
- Choose the most conservative option
- Document your choice in a comment
"""

enabled_tools = [
  "read_file",
  "write_file",
  "edit",
  "grep"
  # No ask_user_question
]

[tools.read_file]
permission = "always"

[tools.write_file]
permission = "always"

[tools.edit]
permission = "always"

[tools.grep]
permission = "always"

Between all and nothing, the prompt allows fine-tuning. An agent that interrupts you every two minutes to pick a variable name is as annoying as a silent agent is risky; so formulate an explicit threshold so it only solicits you on what truly matters.

instructions = """
Clarification rules:
- Ask a question ONLY if the choice affects architecture
- For cosmetic decisions, follow project conventions
- Always propose a maximum of 3 options
- Always include a "Both" or "All" option when relevant
"""

The special case of subagents

Important reminder: subagents cannot ask questions. This is a design constraint, not an oversight—a subagent must be fully autonomous. When it encounters ambiguity, it has three recourses: apply the default option documented in its prompt, document that choice in the result it returns, and signal the ambiguity to the main agent, which can then question you. Writing these default values isn’t a luxury; it’s the condition for a subagent to produce a usable result.

# Subagent with clear fallback
agent_type = "subagent"
instructions = """
In case of ambiguity, apply these default rules:
- Test framework: Vitest
- Code style: project conventions (detected via config)
- Output format: Markdown
Document every default choice in your report.
"""

In practice, reserve clarifications for decisions that commit the architecture or security, and let the agent decide formatting or temporary variable names on its own. Stick to three to five options to avoid turning every question into a form, and always place the choice that would serve as a reasonable default first. The trade-off is simple to state: fewer questions yield more fluidity, but increase the risk of a silent bad choice.

Key takeaways

  • Vibe uses ask_user_question to request clarifications with multiple choices or free-text input
  • The system activates when the request is ambiguous or multiple approaches are possible
  • Include ask_user_question in enabled_tools to enable clarifications
  • Subagents cannot ask questions—they must be autonomous
  • Guide clarification behavior via the system prompt
  • Fewer questions = more fluidity, but higher risk of silent bad choices