When the agent turns a small fix into a redesign
Imagine asking an agent to fix a CSV export that drops accounts with the same customer name. It finds the bad lookup, then notices that the export module is messy. A shared data layer would make it cleaner. A configurable export pipeline would support other formats later. While it’s there, it could replace the old validation library.
You come back to a much bigger patch. The original bug may be fixed, but now you also have a new architecture to review and maintain.
This is a hypothetical continuation of the export example from the previous post. That post asked what evidence supports “done.” This one asks whether the agent is still doing the job you gave it.
The useful boundary is the agreed outcome. The agent should investigate enough to solve it properly, make the necessary changes, and bring you decisions that genuinely exceed its authority. Finding another possible improvement doesn’t automatically add it to the task.
Recover the task before expanding it
“Keep the change small” leaves too much room for interpretation. Small by line count? Number of files? Time spent?
For this hypothetical continuation, suppose the task record says:
- Produce one row per customer account, including the historical import sample
- Preserve the existing CSV columns
- Changes to export code and tests are allowed
- No database migration or production deployment
The agent should recover that information from the conversation, repository instructions, and relevant project notes. It should inspect the implementation and data it can access before asking you for missing context. You shouldn’t have to predict every file it will need or every wrong turn it might take.
Discovery can be wider than the eventual patch. Tracing the export may require reading the importer, account lookup, and tests. Those reads help the agent understand what must remain true. They don’t create permission to rewrite every module it visits.
If the recovered instructions conflict, or a consequential requirement really is missing, the agent should make that specific uncertainty visible before acting on it.
Ask what breaks if the extra work waits
Suppose the agent proposes a shared export framework. The practical question is: what part of the current requirement would fail if that framework waited?
If the answer is only “we might need JSON export later,” the CSV repair can proceed without it. Record the idea briefly if it’s worth keeping. Don’t build the unused extension points now.
If the account lookup is shared by two export paths and both can drop accounts, a repair at their common owner may be necessary. That could touch more files than a workaround in one caller. The agent should explain the dependency and verify the affected behavior rather than optimize for a tiny diff.
The public proportionality-review skill uses this kind of present-need test: connect added complexity to a current requirement or realistic risk, consider an existing capability, and account for the cost of keeping the solution running. Its guidance explicitly preserves complexity needed for correctness and other necessary safeguards.
Term2’s guard-design instructions give a concrete example of that discipline. Before changing a runtime limit, an agent is told to trace the component responsible for enforcement and recovery, then repair that owner instead of adding another guard in a convenient caller. The instructions also call for checking legitimate work that resembles the failure signal.
That’s a useful model for scope control: understand enough of the system to fix the real problem without layering a second mechanism over it. These source documents describe intended procedures; they don’t prove that every agent follows them or quantify an improvement.
A real dependency needs a real decision
Now suppose the historical sample contains records without account IDs.
The agent should investigate first. Can the existing importer recover the IDs? Is there another stable key already in use? Is the sample incomplete? Those are questions it may be able to answer from the project.
If the available data still can’t distinguish two accounts, generating IDs from names or silently dropping records would change what the export means. A database migration might help, but the task explicitly excludes one.
At that point, a useful question is concrete:
The historical sample has records without a recoverable account ID. Combining them by name could merge separate accounts, and skipping them would violate the one-row-per-account requirement. The current scope excludes a database migration. Which policy should apply to these records?
That question should include the relevant evidence and a recommendation when the evidence supports one. The agent can continue independent authorized work while the decision is pending. It should keep the export task open if that unresolved policy prevents the required result.
The coordinator’s decision policy draws this boundary explicitly. Routine authorized choices can proceed. A missing decision that materially changes the goal, cost, scope, or consequences needs focused input.
The same policy keeps optional proposals from becoming artificial blockers. A new JSON exporter can wait without requiring you to approve or reject it before the CSV fix is finished.
Keep the boundary through the handoff
A task can expand again when it is delegated. “Fix the export” becomes “clean up the export module,” and a worker returns a redesign that satisfies its own brief.
The coordinating agent should pass along the required behavior, existing limits, and evidence expected at completion. It should review the returned changes against the original request before accepting them. A worker’s suggestion cannot authorize more work on its own.
At handoff, the useful summary is short: what changed, why each substantial change was needed, what checks support it, and which required decisions remain open. Optional improvements can go in a separate note. They shouldn’t be mixed into the patch or presented as unfinished requirements.
There is a limit to this approach. A written scope can guide an agent and make its actions easier to review, but it cannot enforce access restrictions. The coordinator’s outcome-contract reference is explicit that its checks govern cooperating agents; actual tool permissions and filesystem isolation belong to the host. A production system that is outside the task should also be outside the agent’s available authority wherever practical.
You don’t need to approve every function name or test case. You need the agent to keep connecting its work to the result you asked for, investigate genuine dependencies, and stop before making a consequential decision you haven’t delegated.
Then the extra idea can remain an idea, and the fix can actually finish.
Next: You change a prompt or add a skill, and the next result looks better. How can you tell whether the change helped when the agent gives different answers each time?