We do not start from scratch every time. We look at the weather, check whether anything new happened, then — only then — decide what to change, run the change past a set of checks, and finally apply it and tell you. That order is what decides when we do nothing.
1. First the facts, then what you said
The order cannot swap: facts first, judgement second. The reverse — decide first, find reasons later — is how systems invent changes.
Weather: three days ahead, three behind, how much rain fell, how wet the soil is, whether it has been overcast for days.
Your words: what you just said (“cannot get to the plot today”, “no sprays at home”) plus long-standing preferences in your profile.
Your current plan: the next ten days of tasks, and the three most recent completed ones (for rhythm only, no scoring of your history).
2. If nothing changed, we change nothing
This step is the least intuitive: doing nothing is a correct answer. If the weather has not changed materially since the last review and you have said nothing new, we keep the plan and change not one character.
Why: a “fresh look” with no new information is exactly when a model invents new ideas. That is not intelligence, it is churn.
It also protects you: asking “what is on today?” a second time cannot quietly shred your schedule.
3. A change must carry a reason
Every change carries one sentence of justification, and it may only come from three places: the weather, the reference material, or what you said. A change that cannot cite one of those never lands.
4. Then it has to pass inspection (not the model’s call)
Only not-yet-done tasks may move; completed, skipped and postponed ones are off limits.
At most three changes at a time; dates must fall within the next ten days.
Uncertainty must become a question: if we do not know whether your plot is open or covered, “it will rain” cannot justify changing watering.
Key milestones (such as “time to harvest”) can only be proposed, never rescheduled automatically.
If any check fails, the whole proposal is discarded — never “half applied”.
5. You always hear about it
One line in the conversation and another in that day’s digest. If you disagree, one sentence — “keep the original plan” — and we put it back.
6. Three levels of change, and this table matters most
What we want to do
Applied directly?
What you see
Shift a date (postpone watering before rain)
Yes
“Rain tomorrow, so watering moves to the day after”
Change the time of day (water in the evening during heat)
Yes, but explained
One explanation, plus a line in the digest
Add a task, remove a task, touch a milestone
Proposed only
A question — we move after you agree
7. If you also write code
Five stages: facts → gate (review only when something changed) → structured proposal → validate and route → apply.
Three dispositions (automatic, automatic-but-loud, propose-only), split by blast radius and reversibility.
Guardrails live in deterministic code, not the prompt: default to no change, discard the whole proposal on failure, only pending, ask about unknown facts, advise on milestones, idempotent with cooldown.
The gate also saves money: requests with nothing new never call the model.
