This matters as soon as someone else depends on the result. While you are sitting beside the agent, you can notice an empty file and ask it to try again. A scheduled job has a deadline and a colleague waiting for its output.

Three events to keep separate

The agent finishes its response. A tool finishes its call. The result passes the checks needed for the next step.

They often happen together, but that has to be checked. A CSV written without errors can still be the first page of a larger export. A file with the familiar name can be left over from yesterday's run. A request can also time out after a remote service created the requested object. The connection error alone does not tell you whether the action happened.

Define completion before the run

Take a simple example: read a CSV, produce a normalized file, and write rejected rows with their reasons. A useful completion check could require that:

• The result identifies the input revision it processed.
• Required columns exist and the files can be parsed completely.
• Each input row is either accepted or rejected with a reason.
• Accepted and rejected row counts add up to the input row count.
• The output files and validation record belong to the same run.

These checks won't tell you that every transformation is correct. They tell you something narrower and still useful: this input produced readable outputs, and no row went missing. Business rules need their own checks.

The process owner defines those rules before execution. If the worker can remove a difficult check and then declare success, a JSON report adds little to its original claim.

Leave a short record for the next person

A result can carry a small record such as this:

{
  "run_id": "example-001",
  "input_revision": "demo-input-v1",
  "worker_revision": "demo-worker-v3",
  "state": "completed",
  "checks": {
    "input_rows": 12,
    "accepted_rows": 10,
    "rejected_rows": 2,
    "rows_accounted_for": true
  },
  "artifacts": ["normalized.csv", "rejected.csv"]
}

The numbers are made up. In a real setup, validation code reads the actual files, counts the rows, and checks the input and output identities. A filename or a true that the worker wrote about itself proves nothing.

The record should be useful without the conversation that produced it. A colleague needs the input, the worker revision, the check results, and the artifact locations. They should not have to decide which of five "fixed it now" messages describes the current output.

Give uncertainty its own state

An external action sometimes needs more than success and failure.

Suppose the worker asks a service to create a ticket and then loses the response. Retrying immediately can create a second ticket. Keep the original operation identity and mark the outcome as unknown until the first attempt can be reconciled.

If the service provides a suitable idempotency mechanism, use it according to that service's contract. Otherwise, determine how to locate and distinguish the original action before allowing a retry. A new request identifier does not resolve uncertainty about the first request.

Not every service makes that kind of reconciliation possible. When the evidence can't settle the outcome, leave it open for the person responsible.

Check for runs that never happened

A clean error log cannot tell you that a scheduled job actually ran. It may be clean because nothing started.

Use a separate deadline check that looks for the expected completed run and its validated artifacts. Define the expected interval, the grace period, and who receives the exception. This checker should distinguish a late run, a failed run, an unverified result, and an unknown external outcome.

Start with one job and one useful deadline. A dashboard is optional; an explicit condition for a missing result is the important part.

Make the handoff inspectable

For a small internal tool, begin with three things: a completion condition, a record of each run, and an independent check for a missed deadline. Add complexity when the failure cases require it.

The aim is to let the next person decide whether the result is usable without taking the agent's closing sentence on trust. The records won't guarantee future runs, permissions or fitness for important decisions, but when a handoff fails, they show where.

Whenever I get the chance to make my geeky thoughts more pleasant for a wider audience, I don't shy away from what modern AI can do.