Session 2
Steer the Attention
Why an attention brief works: it steers tools, search, scope, and stopping rules, not just wording.
- Rewrite an implement prompt into an attention-steering brief
- Use the explicit rule: let the agent come up with the path
- Map each clause to a concrete agent mechanism
- See why search keywords and tool choice follow attention
A situation you may recognize
Same ticket. Same soft delete. This time you try to be thorough. You paste schema notes, auth quirks, and three related files. You still end with: “Implement soft delete for user accounts.”
The agent has more to chew on. It still charges into code. The steering survived the context dump.
What changes the run is not packing more. It is steering attention at different jobs: let the agent come up with the path, check blast radius, suggest one next step, and do not implement yet.
Explicit rule: let the agent come up with the path
Write this on a sticky note if you need to:
You own the destination. Let the agent come up with the path.
That is the prompt habit behind Session 2. Do not pre-write every fork in English (“first add this column, then wrap this service, then change this page”). State what you need. Ask the agent to propose high-level steps. Then you steer, challenge, and accept.
| You bring | Agent proposes |
|---|---|
| Destination (soft delete for users) | Candidate roads |
| Rails (no billing changes, smallest safe change) | Order of work |
| Blast-radius worries | Where the change touches |
| Judgment on the proposal | The next step to take |
Prescribing the path too early steers attention at your guessed forks. Letting the agent propose the path steers attention at exploration first: search the repo, name options, defend a recommendation. You still decide. You just stop pretending the GPS script was the job.
When the path itself is already settled (ADR, migration playbook), Session 5 covers prescribing on purpose. Until then, the default advice is: let the agent come up with the path.
A brief that steers attention
Compare these two:
Implement soft delete for user accountsI need to implement soft delete for user accounts.
Tell me what we should do to do that.
Give me high-level steps.
Make sure you check blast radius for this change.
Suggest the next step.
Do not implement yet.The second is not “better” because it is longer. It is better because each clause steers a different part of the agent’s behavior:
| Clause | Attention it steers | What changes in practice |
|---|---|---|
| ”Tell me what we should do” | Let the agent propose the path | Prefer explore and explain over edit |
| ”High-level steps” | Plan shape, not file lock-in | Avoid premature architecture commitment |
| ”Check blast radius” | Sideways relevance | Widen what counts as “in scope” to find |
| ”Suggest the next step” | Short horizon | One move, then a human gate |
| ”Do not implement yet” | Stop coding job | Block write-heavy tool use for now |
Line count is not the skill. Steering is. The first clause is the explicit ask: do not invent the road for the agent; make it come up with the path.
Why this is best practice: the mechanisms
These are not vibes. They are levers inside how coding agents actually run.
1. Search keywords follow attention
When an agent explores a repo, it searches: grep, file search, semantic search. The keywords come from what it thinks the job is.
“Implement soft delete” steers queries toward generic delete/archive patterns from training data. “Check blast radius” and “find existing soft-delete / auth / sessions” steer queries toward your login paths, list filters, billing FKs, and an organizations pattern if one exists. Miss the keywords, miss the targets, then invent a path in the dark.
2. Tool selection follows attention
“Implement” biases the loop toward edit and apply tools. “Tell me what we should do” / “do not implement yet” biases toward read, search, and summarize. Same repo. Different tool policy. Steering attention is partly steering which tools get called.
3. Premature action is a known agent failure
Agents optimized to finish tasks often act before they have grounded knowledge. Your brief forces explore-then-decide: look before leaping into a soft-delete diff. That is especially important when edits are cheap to produce and expensive to unwind.
4. High-level caps premature commitment
“High-level steps” keeps the first pass from locking an archive table, purge job, or new service before the codebase has been seen. Granularity is a steering dial: too fine too early, and the agent defends the wrong forks with confidence.
5. Blast radius widens retrieval
Blast radius is not only a safety slogan. It expands the set of surfaces that should enter context: auth, sessions, default lists, billing, admin permissions. Wider attention → wider reads → risks become visible before code.
6. Next step sets a horizon and a checkpoint
“Suggest the next step” bounds how far the loop should run before yielding. That cuts thrash, runaway edits, and tool addiction. It also creates a natural human gate: align on one move, then continue. Irreversible or wide changes stay cheap to redirect.
7. Context stays cleaner longer
Jumping to implement fills the window with diffs, dead ends, and repair chatter. Plan-and-explore first keeps capacity for discovery. Later, Session 5’s short summary compresses decisions so the next coding session does not reconstruct them from scrollback.
8. The optimization target changes
Without those clauses, the silent score is often “produce a soft-delete-looking diff.” With them, the score includes “surface a path,” “name blast radius,” and “propose one safe next step.” Agents chase what the brief makes salient.
A adds detail and still steers at implement. Search and edits stay coding-first.
B steers tools, keywords, scope, and horizon toward plan and advise. Detail can come later, after attention is pointed at the right work.
Soft delete: what steered attention finds
When blast radius and “what should we do” are in focus, the agent is more likely to surface:
- Do default user lists hide soft-deleted rows?
- Can soft-deleted users still authenticate?
- What happens to open sessions?
- Does billing assume hard delete?
- Is there already a soft-delete pattern in
organizations?
Those are not manners. They are the difference between a small safe change and a polite wreck. Session 1’s one-liner rarely puts them in frame, because it never steered search there.
Same skill with humans, clearer with agents
You already do this with people when you ask them to propose a plan instead of handing them your private GPS. With agents the emotional story falls away, so the mechanism is easier to see: wrong steering → wrong exploration → wrong diff. Use that clarity. Do not treat “let them come up with the path” as an AI-only trick.
What you still own
Letting the agent come up with the path is not handing the destination away. You still own:
- what “done” means
- what must not break
- what good enough looks like
You do not have to pre-write every fork. You do need the agent to propose the path so you can steer, challenge, and accept before code. That pairs with Learning Loops, Not Prompts: name the kind of work before the run gets long.
A prompt shape you can reuse
I need to: [destination]
Let the agent come up with the path:
Tell me what we should do.
Give high-level steps.
Check blast radius for: [areas you worry about]
Suggest the next step.
Do not implement yet.Or say it in one breath: destination, then you propose the path, then blast radius, then next step, then stop before code.
Fill the brackets. Keep it short. Hard rails (“do not touch billing”) belong here as constraints, not as a full GPS script.
Before Session 3
Session 3 looks at plan mode: a product feature that tries to force this redirect automatically, and why a formal plan dump can still make you lose focus even when the agent’s attention was steered correctly.