Your agent says the task is done. Then it gives you a page of caveats, several possible next steps, and more status updates. You still have to reconstruct what happened, decide what matters, and determine whether anything is running in the background.

A delegated task can be technically complete while creating more management work for the person who delegated it. The fix is not simply a more capable model. You need an explicit completion contract, a compact handoff format, and a stop rule the agent can actually execute.

A finished task can still leave an open loop

Agentic work has three separate finish lines:

• Execution is finished: the agent has stopped performing the assigned steps.
• The outcome is verified: the agent has evidence that the requested result exists or that the acceptance criteria were met.
• The loop is closed: you know the final state, any remaining decision is explicit, and unwanted monitoring, retries, schedules, or notifications have ended.

Many workflows implement only the first finish line. The agent completes its actions, writes a plausible summary, and leaves you to verify the result and clean up the workflow. That is not delegation. It is execution followed by supervisory work.

A useful terminal status must describe the state of the task, not the confidence or mood of the agent. Use a small, unambiguous status set:

Status	What it means	What the handoff must contain
Completed	Every acceptance criterion has been met.	The result, its location, verification evidence, and confirmation that no unintended work remains active.
Blocked	The agent cannot continue without an external action or decision.	The exact blocker, relevant evidence, attempts already made, and the smallest decision or action needed from you.
Waiting	A known external dependency has not resolved.	The dependency owner, the event that will resume work, and whether any watch or scheduled check is active.
Monitoring	The task is intentionally still active because a defined change has not occurred.	The condition being watched, the alert rule, the stop condition, and the health-failure path.
Partial or failed	The requested outcome was not fully achieved.	What was completed, what was not, the state of any artifacts, and the safest recovery or restart point.

Do not let an agent mark a task completed and hide unmet acceptance criteria in a caveat near the bottom. If a required criterion is unmet, the status is blocked, waiting, partial, or failed. That distinction prevents a polished response from being mistaken for a finished outcome.

Define closure before the agent starts

If the agent has to infer what done means at the end, it will usually optimize for a plausible stopping point. That may be the end of its tool calls, the creation of an artifact, or the moment it runs out of obvious actions. None of those necessarily represents your intended outcome.

Write a completion contract into the assignment. It does not need to be long, but it should answer seven questions:

1. Objective: What observable outcome should exist when the work is complete?
2. Scope: What may the agent change, and what must it leave alone?
3. Acceptance criteria: What must be true before the agent can use the status completed?
4. Evidence: What proof should accompany the result?
5. Authority: Which actions may the agent take autonomously, and which require approval?
6. Exception policy: Which conditions justify interrupting you before completion?
7. Exit rule: What should stop, remain active, or be handed to an owner after the final response?

For a one-time task, the exit rule may be as simple as: return the verified result, report any material exception, propose no additional work, and stop. For a watch, scheduler, or recurring workflow, the exit rule needs to identify both the event that ends the work and the automation that must be disabled.

Here is a reusable base instruction:

• Work only within the stated scope.
• Use completed only when every acceptance criterion is satisfied.
• Verify the final state with evidence appropriate to the action.
• If blocked, ask for one clearly framed decision rather than listing broad possibilities.
• Do not create follow-on tasks or recommend adjacent projects unless I requested them or an unresolved material risk requires attention.
• At termination, state whether any monitor, schedule, retry, notification, or downstream action remains active.
• After delivering the handoff, stop.

The same pattern works for a monitor. For example: watch a release status until it changes from pending to approved; remain silent while it is unchanged; when it changes, report the old state, new state, timestamp, and evidence; then stop the watch and confirm that its schedule was disabled. If the agreed deadline arrives without a change, send one exception notice, disable the watch, and stop.

That instruction defines the outcome, notification policy, deadline behavior, and cleanup. Without those elements, the agent has to invent a communication strategy while it is already running.

Make the handoff answer the next decision

A handoff is an interface between the agent’s work and your next action. It should not be a diary of everything the agent attempted. Put the result first, preserve the evidence, and expose only the unresolved issue that can change what happens next.

Use this terminal handoff structure:

1. Status: Completed, blocked, waiting, partial, or failed.
2. Outcome: One direct sentence stating what happened.
3. Deliverable: The artifact, record, or changed state and where to find it.
4. Verification: Evidence that supports the claimed outcome.
5. Exceptions: Material deviations from the requested scope or acceptance criteria. Write none if there are none.
6. Decision required: The specific decision you need to make. Write none if the work is closed.
7. Open loops: Any active dependency, owner, schedule, monitor, retry, or notification. Write none if everything is closed.

This format forces a useful distinction between a result and a proposal. A prepared email is not a sent email. A deployment plan is not a deployment. A created schedule is not evidence that the scheduled operation ran. A cancellation request is not confirmation that a recurring job stopped.

Match verification to the claim

The evidence should prove the specific outcome being claimed:

• Created artifact: provide its location and confirm that it can be opened or read.
• Changed system state: provide the resulting state, transaction or operation identifier when available, and relevant before-and-after values.
• Sent communication: distinguish draft, queued, sent, delivered, and failed states rather than calling all of them complete.
• Analysis: identify the inputs, decision criteria, output, and important unresolved uncertainty.
• Scheduled work: identify the schedule state and whether retries, queued work, or downstream alerts remain.
• Stopped automation: confirm the automation itself is disabled, not merely that its user-facing messages have been muted.

For destructive, externally visible, financial, or difficult-to-reverse actions, verification cannot replace authorization. The agent should confirm that the action is permitted before execution, then report evidence of the resulting state. If approval is missing, blocked is the honest status.

Return a decision packet, not a menu

When your input is genuinely required, the handoff should reduce the decision rather than transfer the analysis back to you. Ask the agent to provide:

• one recommended action;
• the evidence that most strongly supports it;
• the material tradeoff or uncertainty;
• the consequence of delaying the decision, if there is one; and
• one exact question you can answer.

Alternatives belong in the handoff only when they represent a real tradeoff. A list of every conceivable next step makes you reconstruct the recommendation yourself. If no decision is needed, the handoff should say so and end.

Adapt the stop rule to the type of agent work

A single terminal template helps, but different task types create different open loops. The stop condition must match the operating pattern.

Monitors should report change, not continued sameness

A monitor needs two separate policies: a user-notification policy and a health policy. The notification policy determines when you hear from it. The health policy determines how the system detects that the monitor itself has failed.

• Store the last relevant state so the next run can compare against it.
• Define which field or event counts as a material change.
• Notify the user only on that change, an exception, or an agreed deadline.
• Record routine health checks somewhere that does not demand the user’s attention.
• Send heartbeats to the user only when they were explicitly requested.
• Define the event, deadline, or instruction that stops the monitor.

Silence should mean that no relevant change occurred. It should not leave you wondering whether the monitor is working. Keeping user notifications and system health separate makes both meanings clear.

Recurring work needs an explicit shutdown handoff

Stopping alerts and stopping the underlying schedule are different actions. A workflow can appear quiet while scheduled runs, retries, or downstream processing continue.

When recurring work ends, require the agent to check each layer that applies: the execution schedule, the next planned run, pending retries, downstream notifications, and any separate monitor watching the workflow. The final response should identify what was disabled, what intentionally remains active, and what could not be verified.

Exploration needs a boundary before it needs a conclusion

Research, discovery, and open-ended analysis can always produce another branch. Give exploratory agents a stopping boundary such as a deadline, evidence threshold, source boundary, decision to support, or explicitly limited set of questions.

At the boundary, the agent should return the strongest conclusion supported by the available material, identify uncertainty that could change the decision, and stop. Adjacent discoveries can go into a parking lot only if you asked for one. They should not silently become new assignments.

Treat closure quality as a product requirement

If clean handoff matters to the product, do not leave it entirely to prompt phrasing. Encode the protocol in the agent interface and orchestration layer where possible.

• Use an output schema with a controlled status value and required handoff fields.
• Reject a completed response when acceptance evidence or automation state is missing.
• Store prior state for monitors so the system, rather than the model’s memory, determines whether something changed.
• Represent scheduler shutdown as an explicit operation with a verifiable result.
• Separate required follow-up from optional ideas in the user interface.
• Preserve artifacts and safe restart information when a task fails partway through.

Then test closure behavior directly. A task-quality evaluation should examine more than whether the agent produced the right content. It should also check:

• Completion truthfulness: Did the terminal status match the acceptance criteria?
• Handoff sufficiency: Could a person understand and use the result without reconstructing the run?
• Scope control: Did the agent avoid unauthorized changes and unsolicited side projects?
• Notification precision: Did it communicate on meaningful changes instead of repeating unchanged status?
• Termination integrity: Did schedules, monitors, retries, and alerts end when they were supposed to?
• Failure recoverability: Did a blocked or failed run preserve enough state for a safe next attempt?

A few operational metrics make recurring weaknesses visible:

• First-pass acceptance rate: terminal handoffs accepted without clarification divided by all terminal handoffs.
• Reopen rate: tasks marked completed but reopened because a required condition was missing divided by completed tasks.
• Empty-update rate: monitoring messages containing no material state change divided by all user-facing monitoring messages.
• Unsolicited-work rate: terminal handoffs that introduce unrequested projects or tasks divided by all terminal handoffs.
• Orphan-automation rate: ended workflows that leave an unintended schedule, retry, monitor, or alert active divided by ended recurring workflows.

There is no useful universal target for these measures. Establish a baseline for your task mix, inspect the failures, and improve the protocol where the failures cluster. A model change may help, but recurring closure errors often indicate a missing state, tool action, schema field, or acceptance check.

Key takeaways

• Define completed through observable acceptance criteria, not the end of the agent’s activity.
• Require every terminal handoff to contain the outcome, deliverable, verification, exceptions, decision state, and open-loop state.
• Make agents return one framed decision when blocked, not a menu of speculative next steps.
• For monitors and recurring tasks, define notification and shutdown behavior before execution starts.
• Evaluate stop behavior, notification precision, and cleanup alongside result quality.

Start with the agent thread that currently consumes the most supervisory attention. Rewrite its assignment with an observable definition of done, the seven-field handoff, and an explicit stop rule. Run one real task, inspect where you still had to reconstruct state, and turn that missing information into the next acceptance check. That is how agent delegation becomes closed work rather than a new inbox.

References

• Nate Jones’s Substack – Your agent finished the job and came back with six more things you could do. The prompt that makes it hand over the result and stop.

---