Define the result before delegating the work
An agent needs a result that somebody can inspect, including the conditions under which the work remains unfinished.
A document can open without being usable. Its paragraphs may appear in the preview while the exported PDF drops a diagram, moves a heading or cuts off the last line. If the task says only “build document export,” an agent can produce something that satisfies those words while leaving the person with the same problem.
In January 2026, I specified Kelpie, an application for turning Markdown text and Mermaid diagram descriptions into an editable preview and a PDF. I asked for accurate, elegant conversion, with an exported document that matched what the person had edited in the preview. That was a product requirement, and the surviving specification does not establish that the application was completed.
The useful starting point for agentic engineering is this relationship between an action and an inspectable result. An agentic system lets a model choose and carry out steps through tools. Someone still has to define which result counts, what the system may change and how the result will be checked.
Write the acceptance example first
Consider an illustrative document application. Give it a sample containing a title, two paragraphs, one diagram and a page break. The person changes a sentence in the preview, exports the document and opens the resulting PDF. Acceptance requires the revised sentence, the complete diagram and the intended page division to remain visible.
This example tells the worker what to build and tells the reviewer where to look. A requirement such as “high-quality export” supplies neither. It leaves the worker to infer which properties matter, and different workers may infer different properties while reporting the same successful status.
Now add a failure case. Supply a document whose diagram cannot be rendered. Decide whether export should stop with an explanation or continue with an explicit warning. Either behavior might suit a particular product, but silently dropping the diagram should not become acceptable merely because nobody described the failure path.
The resulting task has a small, observable sequence. Import a known input, make a specific edit, export, inspect the file and exercise the failure case. A reviewer can repeat the sequence without relying on the agent’s account of what happened.
Keep an untouched copy of the sample document beside the edited version so the reviewer can compare the original wording, the deliberate revision and the exported text without relying on memory or on an agent-generated summary. If a diagram is missing from the PDF, that comparison helps distinguish a failed export from an earlier editing mistake, which matters because the next attempt needs to change the operation that actually lost the content.
Separate the requested result from the chosen method
The agent may choose a rendering library or reorganize an export function within the approved scope. Those choices are methods. The preserved content and page behavior are requirements, and they should not change when the implementation becomes inconvenient.
This distinction leaves room for useful autonomy. A worker can compare implementations, discover an incompatibility and propose a different route while retaining the original acceptance example. If the alternative requires a new account, external upload or broader file access, that consequence needs its own authorization before the route is used.
A task also needs a defined boundary around unrelated work. In the example, changing export behavior does not authorize replacing the editor, deleting source documents or revising the application’s visual identity. Write those restrictions beside the permitted changes so the worker encounters both before it begins.
Record enough for somebody else to decide
Completion should include the input used, the exported artifact and the checks performed against that artifact. If the worker could inspect the file structure but could not render the PDF, record the missing visual check. Structural inspection can support a claim about content presence without supporting a claim about readable layout.
The distinction matters even on small projects because a confident completion message is easy to produce. Opening the actual PDF requires another operation, and comparing its pages against the intended result requires attention that a successful build cannot supply.
For a first task, keep the acceptance example narrow enough to repeat manually. Save the original input, state the expected change and identify the file that the reviewer must open. When those details are available before delegation, a failed result can be rejected for a specific reason, and the next attempt can address that reason without redefining success.
Source notes
Drew Wiberg, Kelpie product requirements, 20 January 2026. Contemporary author record; establishes the requested application and export behavior, not a verified implementation.
Worked examples and review procedures in this article are instructional applications, not additional historical project results.
