Implementation must be bounded and verifiable

A useful unit of work is a change small enough to understand, control and prove—not an instruction that runs until an agent declares success.

The problem

An agent can make an incorrect assumption early and propagate it through many components before anyone notices. Long-running execution may look productive while consuming tokens, generating unnecessary files and building an increasingly complex workaround.

This cannot be fixed by asking the agent to be careful. Boundaries must be agreed before execution and, where possible, enforced independently.

Design the unit of work

A bounded work order specifies the outcome, permitted files or components, supporting contracts, acceptance checks, what is not in scope and conditions requiring a stop. A phase should produce something that can be independently evaluated. Small phases may be completed in an hour; the duration is not the rule. The rule is whether a reviewer can understand the outcome and the consequences.

Allow the agent to make routine implementation choices inside the boundary. Require escalation when evidence contradicts the design, a contract must change, external behaviour is unclear, or repeated attempts produce no new evidence.

Example

Instead of “build request management”, a first phase might be “introduce a request intake contract and prove repeated delivery of the same external event cannot create a second request”. That has an explicit observable result. Assignment, notifications and dashboards remain separate decisions.

A later implementation phase may reveal that the provider cannot meet the agreed contract. This is a reason to stop and revisit the design, not permission to invent a second data model.

Controls and evidence

• Scope or path limits, branch isolation and explicit allowed dependencies.
• Meaningful iteration, time and token budgets; stop after repeated failed attempts.
• Tests and contract checks performed outside the implementing model’s assertions.
• A diff or change manifest showing what actually changed.
• A short completion record: evidence, deviations and open risks.

Limits

Over-slicing can make the work incoherent and increase integration overhead. Some architectural changes legitimately span several components. Treat those as deliberate larger changes with explicit impact, not accidental consequences of a broad prompt.

See the worked example: delivery phases, agent work order, stop log.