Why an AI agent must not act when you only ask a question
AkiDevRule 3.8.0 makes agents act only on an order, codes open items Q/T/N and requires whole-file rule reads. Each change comes with evidence from the CHANGELOG.

An AI agent should change files only when your words are an order; a question gets an answer and nothing else. AkiDevRule 3.8.0 (2026-10-20) turns that into rules that can be checked: agent.A3 rebuilt on one root, agent.A4 coding open items Q/T/N, and agent.B1 locking scope to the request. Each change below comes with an incident or a measurement recorded in the 3.8.0 CHANGELOG.

Why must an agent not act when you only ask a question?
Because recognizing a question was never what failed; what failed was that nothing forced a judgment before the write. On 2026-10-20 an agent running agent.A3 took a question that hid its only question mark behind a hedge ("maybe write it into notes ...?") and turned it into a notes edit, then answered the correction with a second unordered git restore. Asked afterwards to classify those same messages, it classified every one correctly. The CHANGELOG records the root cause: A3 asked for judgment at no moment, and 11 earlier changes had moved this boundary back and forth, 7 limiting action and 4 pushing it.
What separates an order from a question?
An order is an action verb aimed at the agent ("fix X", and also "can you fix X?"); a question, a hedge, "should we", "how" or a correction of something nobody ordered gets an answer only. The new rule attaches the check to the right moment: before the first state-changing call (anything beyond reading and checking) the agent must name the words of yours that ordered it; none, or words that read both ways, means no call. The reverse is a failure too: once ordered, the agent runs to the end, and over-asking on safe ordered work counts as much as acting unasked.
What do the Q, T and N codes in an agent report mean?
Q, T and N code each open item by what your silence does to it, so a glance at the letter tells you whether the item needs you.
- ◆
Q(question): silence blocks, you must answer before it moves. - ◆
T(taking it): silence proceeds, the agent made a call within the order and states what, why, and the alternative it rejected. - ◆
N(note): silence changes nothing, a reminder, a caution or an idea outside the order. - ◆Once no
Qis left you are done reading; doable work was done within the order and is never listed.
The CHANGELOG evidence: 1,260 coded items in 298 open-item blocks across 254 Claude Code and 500 agy CLI sessions, from 2026-08-28 to 2026-10-20, with one letter carrying up to four meanings (S was a gate step, a design option or a task). Three letters partition every item because your silence has exactly three consequences, so a new kind of work needs no fourth code.
What does "the request is the whole scope" mean?
A step you did not name, such as the PR after a commit, the push after a fix or the deploy after a build, is not taken because it is customary. On 2026-10-08 the owner asked an agent for one added comment line and the agent also opened a pull request (PR #1) nobody asked for; the old agent.B1 listed commits and pushes but not PRs or deploys. B1 now names PRs, deploys and tags and adds one principle: a workflow's usual next step is still an unrequested step.
The same principle covers clutter: across 516 Claude Code transcripts (2026-10-20), 528 rm commands in 131 transcripts mostly deleted the agent's own throwaway files. agent.C5 is now two rules: make no file the task can do without, and none outside the session scratchpad. And coding.B3 adds "one run per change state": 507 of 2,522 verification runs (20%) repeated the same check type with no edit in between, 78% of them after the output had been cut with grep or head.
Why must a rule file be read whole to count?
Because a partial read followed by a claim of having read is how a rule gets skipped while looking compliant. On 2026-10-19 a worker told to read two rule files called Read with limit: 40 and limit: 30, then opened its reply with a [RULES] receipt naming both. Measured on transcripts: subagents read partially in 34 of 440 rule reads (7.7%), main sessions in 44 of 1,164 (3.8%). The root cause is the Read tool description, which advises reading only the part you need.
Since 3.8.0 the aki-route-guard gate counts only whole-file reads, and on Claude Code a partial Read of a rule file is rewritten into a whole one inside the hook, with no extra round trip. The gate also reads Cursor transcripts correctly, where every gated edit used to be denied even after the rule was read.
What changed in the installer in 3.8.0?
- ◆No more
*.akidevrule-backup-*files beside every file it touches after each install; backups are removed when the run succeeds and kept only when it fails. - ◆The rtk config is opt-in: one terminal prompt, default no, flag
--rtkto say yes. Reason: rtk's default filters can cut output an agent is reading as evidence. - ◆One
route-map.jsonreplaces three hand-copied tables that had drifted apart, so the gate and the audit script read the same path-to-rule map.
Where should I start?
Run npx @akinet/akidevrule@latest (Node 18+, MIT) and open a new session; running the same command again is the update. See the AkiDevRule project page, the source on GitHub, the npm package and the Release Notes 3.8.0. Coming from 3.7, the article AkiDevRule 3.x tells the earlier part of the journey.