Wish-Driven Agents: Spend Attention on Outcomes, Not Every Step

Recommended mindset

Give an agent a destination, not just its next instruction. Say what you wish were different and why. Let the agent discover what would count as evidence that the change happened, investigate the environment, take several reversible steps, and verify the result. Keep your attention for choices that change the destination, consequential trade-offs, and actions you cannot safely undo.

This is not a request for a long specification, blind autonomy, or a ban on reading code. It is a change in who runs the working loop. The human owns the purpose and the authority to accept the outcome. The agent owns much of the route and should come back with observations, not just a claim of completion. The proposed measure of improvement is acceptable outcomes per unit of human attention, with risk and elapsed time still visible—not the number of autonomous steps for its own sake. This is my working recommendation, not a measured universal law.

Why this mindset has recognizable roots

Werner Vogels describes Amazon’s Working Backwards as starting with the customer and moving backward toward the minimum technology needed. That does not mean every agent task needs a press release; the transferable logic is desired experience before solution. Vogels, “Working Backwards”

Kief Morris calls the human’s work of turning ideas into outcomes the “why loop” and the production of intermediate artifacts the “how loop.” He argues for humans on the loop—shaping its controls—rather than either inspecting every line or leaving the agent entirely unsupervised. He also cautions that internal quality matters when it affects reliability, cost, or future delivery. Morris, “Humans and Agents in Software Engineering Loops”

Anthropic describes agents as selecting their own steps and tools while using feedback from the environment to assess progress; it recommends simpler workflows where autonomy does not improve the result. Its long-running-agent experiment illustrates the other half of the lesson: a high-level goal alone did not prevent an agent from doing too much at once or declaring success prematurely; incremental progress and end-to-end verification helped. These are vendor reports from particular settings, not proof that one prompting style works for every model or task. Anthropic, “Building effective agents”; Anthropic, “Effective harnesses for long-running agents”

My synthesis: wish → discover a provisional test of success → work in verified increments toward the whole outcome → revise the test if exploration changes what “done” means → ask the human when judgment or authority is genuinely needed. The test is provisional because some wishes cannot be evaluated sensibly until the agent learns more.

The three traps in my current way of working

1. I become the code-tuning loop

I review an agent’s code, see something I do not like, request another pass, and repeat. That can catch real problems, but it can also make my taste in intermediate artifacts the agent’s main feedback signal. The alternative is not “never review code.” It is to start with the objection’s consequence:

• If the behavior is wrong, describe the user-visible failure and ask the agent to reproduce, repair, and show a passing check.
• If the design threatens future changes, safety, performance, or operating cost, name the consequence and ask for evidence or a focused review of that risk.
• If it is a preference without a material consequence in this task, decide whether the extra round is worth my attention. Preserve the few preferences that repeatedly matter; do not turn every preference into a standing law.

A passing check is evidence for what it actually checked, not proof of everything that matters. In Anthropic’s long-running-agent experiment, the agent sometimes marked work complete without exercising the full user journey; adding end-to-end tools exposed failures missed by narrower checks. This makes the choice of observations—and the gaps they leave—more important than a confident “done.” Anthropic, “Effective harnesses for long-running agents”

2. I delegate one step, then accidentally become the project manager

When every prompt is “do step one,” I must remember, formulate, and authorize step two. The agent may finish its instruction perfectly while the actual wish remains unmet. I should delegate ownership of the destination across multiple steps, while asking the agent to execute one verifiable increment at a time. A long horizon is not a license for one enormous, irreversible batch. Anthropic’s long-running experiment reports both the danger of trying to one-shot a complex task and the value of incremental progress with a persistent record of what remains. Anthropic, “Effective harnesses for long-running agents”

A better handoff: “Work toward the end state, not merely the first plausible change. Investigate the likely sequence, carry out reversible steps, check each meaningful increment, and adapt when the evidence changes. Return only when the outcome is verified, a consequential choice needs me, or you cannot proceed.” That instruction delegates the loop without pretending the first plan will be right.

3. I invest in reusable context that rarely gets reused

I like close control and have practices that work for me. Encoding all of them before each task is expensive when the next task may be unrelated. My proposed rule is to keep a tiny durable core, let the agent retrieve local context for the present task, and only promote a correction to a standing instruction after a recurring, costly failure. If a task is unusual, put its special constraint in the task rather than in a permanent manual.

This is a question of return on attention, not hostility to context. A high-value detail may be worth supplying once; a seldom-used rule imposes reading and maintenance costs every time. Birgitta Böckeler frames an agent’s support as guides that steer before action and sensors that let it correct afterward; she explicitly says such controls cost effort and should direct human input where it matters, not aim mechanically to eliminate it. That is a useful rationale for selective, rather than maximal, context engineering. Böckeler, “Harness engineering for coding agent users”

A lighter way to delegate

I can start with a sentence or two, not a page of implementation instructions:

Wish: [What I want to be true, and for whom.] Why: [Why it matters.] Investigate how to tell whether it is true; tell me if that remains uncertain. Own the work through multiple reversible steps and check the real outcome, not just the existence of an artifact. Preserve [one or two important boundaries]. Decide routine details yourself. Ask me before an irreversible action or a choice that changes the intended outcome. Return the observation, the evidence, and what remains uncertain.

The agent should not invent certainty where the wish is ambiguous. It can propose a way to recognize success; I decide if that proposed interpretation changes what I meant. If it cannot observe the relevant environment, the answer is to obtain suitable access or report the limit—not substitute a plausible-looking implementation for a demonstrated result. Anthropic emphasizes environmental feedback in agent operation; OpenAI distinguishes automatic checks from human approvals for sensitive actions. Anthropic, “Building effective agents”; OpenAI, “Guardrails and human review”

What deserves my attention?

Anthropic’s study of its own agent use found that experienced Claude Code users approved individual actions more automatically and interrupted runs more often. Its authors interpret this as a shift from approving every move to monitoring and intervening when needed; they explicitly caution against prescribing one oversight pattern for all agents. That is directional evidence for selective intervention, not a guarantee that fewer interruptions always improve outcomes. Anthropic, “Measuring AI agent autonomy in practice”

The practical budget is: spend attention up front on the wish and a few true boundaries; spend it during work only at decision boundaries; spend it at the end on evidence and residual risk. Let the agent spend its own time on investigation, intermediate corrections, and routine checks. If extra instructions or tools do not reduce my subsequent review or improve the accepted result, stop adding them. This last rule is an editorial hypothesis to test against my own tasks, not an established benchmark.

The overall pattern is human at the level of purpose and acceptance; agent at the level of route and reversible iteration; observable feedback between them. More autonomy is useful when it buys a real outcome without consuming the very attention it was meant to save.

Sources

• Werner Vogels, “Working Backwards”, 2006.
• Kief Morris, “Humans and Agents in Software Engineering Loops”, 2026.
• Anthropic, “Building effective agents”, 2024; “Effective harnesses for long-running agents”; “Measuring AI agent autonomy in practice”.
• Birgitta Böckeler, “Harness engineering for coding agent users”, 2026.
• OpenAI, “Guardrails and human review”.