Most disappointing agent results are not a reasoning problem. They are a handoff problem: the task described the action but not the outcome, the boundaries, or what evidence would make the change reviewable.
Context is part of the task
An engineer who picks up a ticket has more than the ticket: the surrounding code, the conventions, the last change, and the person who will review it. A handoff is only as good as the part of that context it carries with it.
What belongs in a handoff
The goal, in one sentence
What should be true when the work is finished? Write it so a reviewer can check it, not so an optimist can interpret it.
The constraints
Patterns to follow, interfaces that cannot change, and the scope that should not be touched.
The evidence
The files, commands and checks that show the change works. Link the result, not just the plan.
Make the stop condition explicit
Agents are good at continuing. They are much worse at knowing when to stop. A handoff that names the stop condition — the test that must pass, the behaviour that must not change — turns a long task into a checkable one.
{
"goal": "Render the profile card when the user lookup returns null",
"constraints": [
"Do not change the public API of the lookup",
"Match the existing component patterns"
],
"done": [
"A test covers the unknown-user case",
"Build and type checks pass"
]
}A brief that a reviewer can check is a brief an agent can finish.
Start with a clear task
Open a repository, describe the outcome, and keep the review with the engineer.
