climate-air-circulation

Set the air-circulation mode

Switch how the cabin draws air: fresh-air (outside air), recirculation, or auto. The mode may be named outright, or the user may point at "my preferred" circulation without naming it. Sometimes the control is missing. The same method handles all of these.

When this applies

"Switch to fresh-air / recirculation / auto", "the air feels stuffy, let some outside air in", "set my preferred air circulation". (Turning AC on/off is climate-air-conditioning; setting fan speed is climate-fan-speed; setting airflow direction is climate-airflow-direction.)

Tools

• get_climate_settings({}) — read the current circulation mode (and the rest of the climate state). Use it only to report current state; it is NOT a required precondition for setting the mode. Verify it is callable, and read its fields honestly — a field returned as "unknown" is unverifiable, not a real value.
• get_user_preferences({}) — read the user's preferred circulation mode (the mode they like). This is what disambiguates an unnamed mode.
• set_air_circulation({mode}) — set the circulation mode (FRESH_AIR / RECIRCULATION / AUTO); use exactly the mode named or preferred. Setting it is a direct write with no precondition and is independent of AC / window / fan state — so it does not require reading or changing those first.

Method

1. Set exactly the mode named. If the user names fresh-air, recirculation, or auto, set that exact mode directly — not a "smarter" or default substitute, and without first reading climate state you don't need.
2. Unnamed mode → read the preference, then set it. When the user says "my preferred" / "the one I like" instead of naming the mode, read get_user_preferences and set the mode it specifies.
3. Confirm what changed and stop. Don't loop a confirmation on a direct, unambiguous command.

Ask vs. infer (the under-specification crux)

• Unnamed circulation mode → INFER from the stored preference; do NOT ask, do NOT invent. When the user expects you to know their preferred mode, read get_user_preferences and set the mode it gives. Offering an open "fresh air or auto?" menu, or guessing a default, is the failure. A single confirmation of the preferred value is tolerable, but the value comes from the preference, not a guess.
• Never re-ask what context already pins. If the user already named the mode, or it is fixed by the preference, act on it directly — do not ask again. Read the deciding value once, then act; don't loop on preference reads.
• Informational/options questions are NOT a call for action — answer, don't act. When the user only asks "what's the best way to improve the air?", "the air feels stagnant, what are my options?", or "what's it set to?", present the options (fresh air, auto, raise fan, etc.) and/or report the current state, then stop. Do not proactively call set_air_circulation or any state-changing tool — wait for an explicit "do it" ("switch to fresh air", "get some air flowing"). Likewise "prepare to …" is not yet a call to act on that step. Acting on a question is over-acting.
• There is no genuine open user choice here beyond the mode itself, and that is either named or fixed by preference — so asking is almost never warranted.
• In a combined request, change only what's asked plus what a tool strictly requires. When setting circulation rides along with another action (e.g. "turn on AC and set fresh air"), perform exactly the circulation change you own and let the other operation handle its own minimal preconditions. Do not pre-emptively nudge fan speed, temperature, or other actuators to a temporary value the user never requested — an unsolicited intermediate change is a failure even when the final state ends up correct, especially since a later turn may set that actuator differently.