Give an agent freedom within an outcome contract

A task can be so prescriptive that the agent has little useful work left to choose. It follows a sequence of edits, produces exactly the requested implementation and preserves a slow or awkward behavior that the person hoped to improve. The instructions have been followed while the underlying problem remains.

My January proposal for an improvement loop asked the agent to choose methods I might not know to request. The proposed task would establish a baseline, seek an improvement and repeat the same measurement alongside ordinary quality checks. It was a proposal for how to delegate discovery, not evidence that the stated performance target had been achieved.

That kind of delegation needs a precise division between the decisions the worker may make and the conditions it may not revise. The implementation can remain open while the result, permissions and acceptance procedure remain fixed.

What the worker can decide

Consider an illustrative document search feature that returns relevant results too slowly for its intended use. A method-prescriptive task might order the worker to add a particular cache. An outcome-based task could instead permit changes to indexing or retrieval while requiring the same result quality on a saved collection.

The worker first inspects the existing behavior and identifies the likely cause of delay. It might discover repeated parsing rather than a slow search operation. An instruction to add a cache in the wrong place would have constrained the work before that observation was available.

The outcome contract should still be specific. Name the collection, the query set, the acceptable results, the timing procedure and the parts of the application that must remain unchanged. Define a permissible resource budget and the conditions under which the worker should stop and report a blocker.

The example does not supply a universal search threshold. A small personal collection and a large shared service have different requirements. The threshold needs to come from the task’s actual purpose rather than from a number chosen because it looks demanding.

Before accepting a proposed search improvement, have the worker describe which stored document should satisfy each example query and why, then preserve those expectations separately from the implementation so a later change cannot quietly revise them. When a query has several reasonable results, record that ambiguity rather than forcing one answer merely to simplify the check, and have the reviewer inspect any changed ordering that could affect the person’s ability to finish the task.

What the worker must demonstrate

A worker proposing a change should identify what observation led to it. If repeated parsing appears responsible, record enough timing evidence to distinguish that operation from the rest of the request. The explanation can be uncertain, but the next experiment should be capable of changing it.

After implementation, rerun the preserved queries and inspect the results. Faster retrieval is not acceptable if the worker achieves it by searching fewer documents without approval. A change that improves one query while degrading several important cases requires a more qualified decision than a single average can provide.

This approach also makes rejected attempts useful. A record of the tested change, its result and the reason for reverting it prevents another worker from repeating the same experiment under a new description.

What needs a new decision

Freedom to improve search does not automatically authorize uploading the collection to another service, buying a subscription or changing who can access the documents. Those choices alter the task’s permissions or commitments and require the relevant approval.

The agent should identify the proposed change and explain why it matters, then continue any independent work that remains within scope. A blocked external route need not prevent measuring the existing local system or preparing a test fixture.

An outcome-based task is ready to close when its fixed acceptance conditions have been checked against the resulting artifact. If the target remains unmet, the record should show what improved, what failed and what would require a new decision. Retain the query set and result checks so the next attempt begins from the verified state of the application rather than from the confidence of the previous completion message.

Source notes

Drew Wiberg, outcome-based improvement-loop proposal, 26 January 2026. Establishes the proposed freedom to choose methods under repeated acceptance measurements.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.