💬 Communication & Autonomy
The bottleneck became interaction
Models already perform coding tasks very well. What still fails is the interaction:
asking too much, doing too little, narrating thought, burying the result. This module traces the evolution of the sections of
how to communicate e how to act without asking in real Claude Code prompts
(4.6 → 4.8 → Fable 5).
Detailed content
The bottleneck shifted from capability to interaction
In early prompts for coding agents, the effort went into teach the model to execute: how to call tools, how to edit files, how to run tests. Today, models do these well. What remains difficult is not capability — it's interaction. That’s why more recent prompts devote entire sections to how to talk to the user e when to act without asking.
🎯 The new frontier: the two ways to fail
When capability stops being the limit, the experience is defined by two opposing errors—and the prompt exists precisely to calibrate the point between them:
Asked too much
Asks for confirmation to edit a local file. Narrates every step. Returns options instead of a recommendation. The user becomes the manager of a timid agent.
Did too little / did too much
Stops at the first question instead of following the obvious path—or does a git push without warning. Both cost trust.
Why this is emerging NOW in coding agents
A chatbot only produces text — there’s no action in the world to confirm. A coding agent writes to disk, runs commands, pushes, and sends messages. Each action has blast radius (blast radius) and reversibility different. It’s this ability to act in the world that creates the need for a communication and autonomy policy.
How to communicate — tone, concision, and output budget
The agent runs in the terminal: the user doesn't see the reasoning or the raw tool results — only the output text.
This calls for different tone rules than a chat. Claude Code dedicates entire sections to this. See how the tone rule is stated in
claude-code-2.1.172-opus-4.6.md:
# Tone and style (lines 49–53)- Only use emojis if the user explicitly requests it.
- Your responses should be short and concise.
- When referencing specific functions or pieces of code include
the pattern file_path:line_number to allow the user to easily
navigate to the source code location.
- Do not use a colon before tool calls. ... text like "Let me read
the file:" followed by a read tool call should just be "Let me
read the file." with a period.
Right after that, the block # Text output deals with output budget —
how much text to produce and where to put it. This is where Pattern 7 (Concision Budget) comes into play:
The terminal rule (4.6, lines 55–64)
- •"Before the 1st tool call, say in one sentence what you're going to do."
- •Short updates at key moments: when you find something, change direction, or get stuck.
- •"Brief is good — silent is not." One sentence is almost always enough.
- •End-of-turn summary: 1–2 sentences. What changed and what comes next.
Don't narrate deliberation
"Don't narrate your internal deliberation. User-facing text should be relevant communication to the user, not a running commentary on your thought process."
Concision here isn't just "answer briefly"—it's choose what deserves to go in the text. Thinking stays in thinking; the text conveys results and decisions.
When to explain more
4.6 already provides the calibration criterion: "Match responses to the task: a simple question gets a direct answer, not headers and sections." Concision is relevant to the task, not a fixed limit. Exploratory question → 2–3 sentences with a recommendation and trade-off (line 19). Simple task → direct answer.
How to act without asking — calibrated autonomy
The counterpart to communication is autonomy: acting without asking permission when the action is safe. The master rule of Claude Code is simple and powerful — calibrate based on reversibility and by the blast radius by the action, not by its importance.
✓ Act alone (local and reversible)
- ✓Read files, grep, explore the repository
- ✓Edit local files and run tests
- ✓Create a local branch, make a local commit
- ✓Follow the obvious path without returning a menu of options
✗ Confirm beforehand (irreversible or external)
- ✗Delete files/branches,
rm -rf, table drop - ✗Force-push,
git reset --hard, published commit amend - ✗Push, open/comment on a PR, send Slack/email
- ✗Upload content to an external service (it becomes public and indexable)
# Executing actions with care (line 34)Generally you can freely take local, reversible actions like
editing files or running tests. But for actions that are hard to
reverse, affect shared systems ..., check with the user before
proceeding. The cost of pausing to confirm is low, while the cost
of an unwanted action ... can be very high.The asymmetry that justifies the rule
The policy isn’t "always be cautious" — that would mean asking too many questions again. It’s a asymmetric cost analysis: pausing to confirm costs little; an unwanted action (lost work, a sent message, a deleted branch) costs a lot. So, full autonomy on the low-cost/reversible side, confirmation on the high-cost/irreversible side.
When to confirm — the 3-question test
"Confirm first" isn't a feeling—it's a test. An action crosses the confirmation threshold if the answer to any of three questions is "yes." And there’s a crucial nuance about authorization that the prompt makes explicit.
Is it hard to reverse?
Force-push, reset --hard, remove the dependency, overwrite uncommitted changes. If "ctrl-Z" isn't available, confirm.
Does it affect shared state / is it visible to others?
Push, PR, Slack/email message, shared infrastructure. The blast radius extends beyond the local environment. Confirm.
Going to an external service (publishing)?
Diagram renderers, pastebins, gists. "It may be cached or indexed even if later deleted." Could be sensitive. Confirm.
The most subtle rule: authorization does not extend
In 4.6 (line 34): "A user approving an action (like a git push) once does NOT mean that they approve it in all contexts ... Authorization stands for the scope specified, not beyond."
In other words: the user approved that push, not "pushes in general." The exception is durable authorization — instructions in
CLAUDE.md or an explicit "operate autonomously." Then the agent proceeds, while still mindful of risk.
✓ Facing an obstacle: investigate
- ✓Find the root cause and fix the underlying problem
- ✓Resolve merge conflicts instead of discarding changes
- ✓Investigate an unfamiliar file/branch—it may be work in progress
✗ Destructive shortcut: never
- ✗Use
--no-verifyto get past the hook that complains - ✗Delete the lock file instead of checking which process is holding it
- ✗Overwrite unexpected state without understanding what it is
Connection to Patterns 7 and 11
Communication and autonomy aren't isolated new patterns—they apply two patterns from the Track 1 catalog to an agent context. Recognizing this connection is what turns reading a prompt into understanding a principle.
Concision Budget
The block # Text output is Pattern 7 in its pure form: defines how much text fits
("1–2 sentences per update", "end-of-turn summary in 1–2 sentences").
In the terminal, the budget is deliberately tight — every extra line clutters the history. Concision is managing a scarce resource, not a style choice.
Priority Hierarchy
"Confirm first" is overridden by durable authorization (CLAUDE.md). This is precedence: the instruction from user takes precedence over the prompt default.
And one skill when loaded, it doesn't override the user: it changes behavior within the space the user allowed. User > skill > default.
This default can be changed by user instructions - if explicitly
asked to operate more autonomously, then you may proceed without
confirmation ... unless actions are authorized in advance in
durable instructions like CLAUDE.md files, always confirm first.User × Skill: who’s in charge?
When a skill says "be terse like a caveman" and the user asks for a detailed explanation, the user wins. The skill defines the how within the authorized scope; the user defines the limits of that scope. It’s the same logic as "authorization doesn’t extend": precedence always belongs to the instruction closest to the user’s actual intent.
The evolution of the sections: 4.6 → 4.8 → Fable 5
Here is what sets this collection apart: you can see the same policy being reorganized three times in a few months. The content is stable; what changes is how it is packaged — and each repackaging tells a story about what was failing.
Spread across 4+ named sections
2088 lines
The policy lives in separate blocks: # Doing tasks,
# Executing actions with care,
# Tone and style,
# Text output. Lots of bullets, generous prose, numbered examples of risky actions.
Signal: the rule is new enough to need a lot of space and many explicit examples.
Consolidated in # Harness
1798 lines (−290)
The 4 sections collapse into one dense block: 5 short bullets + a single paragraph that condenses "Executing actions with care". "Tone and style" and "Text output" nearly disappear as headings — they become internalized rules. All risk confirmation fits in a sentence (line 16).
Signal: behavior has already stabilized in training → less prompt needed. This is consolidation through internalization (the central lesson of Track 2).
Re-expanded into # Communicating with the user
1821 lines (+23)
Communication becomes a section again named and in prose — but with new ideas, not the old ones: "Lead with the outcome", the rule that everything the user needs should be in the final message of the turn, and the explicit thesis "being readable and being concise are different things, and readable matters more".
Signal: the failure changed. It's no longer "the agent talks too much" — it's "the agent compresses so much that it becomes illegible (arrows, jargon, fragments)." The prompt corrects the new error.
# Communicating with the user (line 22)Being readable and being concise are different things, and readable
matters more. ... The way to keep output short is to be selective
about what you include ..., not to compress the writing into
fragments, abbreviations, arrow chains like `A -> B -> fails`,
or jargon.The lesson from the 4.6 → 4.8 → Fable 5 arc
Reorganizing a section isn’t cosmetic: each movement fixes the side effect of the previous movement. 4.8 trimmed communication too much; Fable 5 reopens the section to keep “concise” from becoming “illegible.” Promoting something back to a named heading is just as strong a signal as removing it.
📝 Module Summary
Module activity
Open Anthropic/Claude Code/claude-code-2.1.172-opus-4.6.md in the section
# Executing actions with care (lines 32–42) and list 3 “when to confirm” rules.
Deliverable: a summary of an agent’s autonomy policy — in prose, not arrows.
Next module
2.5 — OpenAI Case: Personalities and the GPT-5.x → 5.5 Family