No deferral — finish every requested item in the same session
No deferral — finish in the same session
The rule
Every requested item ships in the same conversation it was requested. No "queued for next session," "we'll pick this up later," or "deferred to a follow-up."
If N items were requested, N are shipped. If a dependency blocks item K, unblock it in-session or route around it — do not skip it.
Why
- Session boundaries are cache boundaries per
claude-code-latency-techniques. Every deferred item is a full re-pay of context on next session start (up to ~30K prefix tokens depending on what's auto-loaded). Doing N items now costs less than N items across N sessions. - Deferrals rot. "I'll finish this next session" becomes "next week" becomes "in the backlog somewhere" becomes lost. The three deferred items on 2026-07-03 that triggered this rule were about to enter that rot pipeline.
- The user has to remember state that the agent should own. Every deferral shifts cognitive load to the human.
- If the work is too big for one session, the answer is subagent fanout (per
delegate-to-subagents-by-default), not deferral.
How to comply
- Enumerate every requested item at the top of the response.
TaskCreatefor each. - Rank by dependency. Independent items go in parallel (subagent fanout or workflow orchestration).
- Start executing immediately. Do not draft the response first — the response IS the last step.
- If an item genuinely cannot ship in-session (paid API, repo transfer, requires human external action), state it explicitly and route around it: post the SOFA Question, file the GitHub issue, draft the PR, whatever gets the work to the state where it CAN complete. The item's progress-visible artifact ships this session even if the terminal action doesn't.
- Complete every task in the list before ending the turn. Partial completion is not completion.
The narrow exception list
Only these three shapes are allowed to defer:
| Shape | Why |
|---|---|
| Paid API calls | Per no-card-on-file — never authorize a paid call in-session without explicit ratification |
| Repo/domain deletions or transfers | Per standing-auth — the user must confirm, and confirmation is one turn away |
| Mass deletions ≥50 LOC | Per grill-on-loc-removal — a grill-me must run first, and the grill's answers may reshape the deletion |
For those, deferral means "the work is stopped pending explicit approval," not "we forgot." State the block clearly. Do not defer other classes of work by masquerading as one of these.
Anti-patterns
- ❌ "I'll queue this for the next session" — no, do it now
- ❌ "Deferred pending grill round X" — run the grill now
- ❌ "Blocked on SOFA response" — post the Question now, capture what you know now, don't wait for network replies to start on the local part
- ❌ Ending a turn with a "next session TODO" list — that list IS the current turn's work, unfinished
- ❌ Doing 3 of 5 items and saying "the other 2 are queued" — no, do 5
When this rule fires
- User submits ≥ 2 requests in one message
- Prior turn ended with a "deferred to next session" summary and this turn opens without addressing it
- A subagent returns partial results and the parent tries to close the turn on the partial
Cross-refs
self-update-rule— decisions land same-turn, this rule extends the discipline to executiondelegate-to-subagents-by-default— the escape hatch for "too big for one session" — fanout, not deferminimum-everything— smallest unit per task keeps the N items shippable in one turnsofa-workflow— "verify after apply" also lands same-session, not later