When you ask HQ to change something — create a candidate, move an application, add a note, close a job — it does not just do it. It writes a plan: a short rationale and the exact steps it intends to take. The plan pauses and waits. Nothing changes until you approve it. You can also reject it.
Why a plan instead of just doing it
HQ splits every tool it has into two kinds. A read looks something up and changes nothing — those run immediately, covered in asking HQ questions. A mutation creates, updates, deletes, or sends. Mutations are gated.
The reason is trust. An AI that searches your candidates is convenient. An AI that can silently reassign stages, delete records, or send email needs a check on it. Plan-gating is that check: HQ can propose any change, but a person approves it before it happens. You get the speed of "just ask" without handing over write access to your data.
What's in a plan
A plan has two parts:
- The rationale. Why HQ wants to do this — in plain language. Read it. If the reasoning is off, the steps will be too.
- The steps. An ordered list of the concrete actions, each naming the tool it will use and what it will do — "move Priya Nair to the interview stage on the Backend Engineer role." If a request needs five changes, you see five steps before any of them run.
Read both. The plan is the entire change, written out, before it touches anything. This is the moment to catch a wrong candidate, a wrong stage, or a step you didn't intend.
Approving or rejecting
Once you've read the plan:
- Approve it if the steps are right. HQ executes them in order and tells you what it did — with links to anything it changed.
- Reject it if they're not. Nothing happens. HQ acknowledges the rejection, and you can rephrase your request or explain what you actually wanted.
Rejecting costs nothing — a rejected plan changes zero data. If a plan looks even slightly wrong, reject it and clarify. That's cheaper than approving and fixing.
One plan at a time
A chat handles a single plan at once. While a plan is waiting, HQ pauses there — approve or reject it before the conversation moves on. This keeps things unambiguous: there's never a stack of pending changes to untangle, just the one in front of you.
When it gets it wrong
The failure to watch for is a plan that looks reasonable but isn't — the right action aimed at the wrong record, or one step too many. That's why the plan is shown in full: skimming it defeats the safeguard.
If HQ proposes something you didn't ask for, your prompt was probably broader than you meant. Reject the plan and narrow the request — writing good prompts helps. And if a step fails mid-execution (a record was deleted out from under it, say), HQ stops and reports the error rather than plowing ahead.