Give an agent a task you can actually verify

Start with the check, not the prompt

“Look into this and tell me what you think” leaves too many decisions implicit. Which sources count? How much work is enough? May the agent edit files, browse or contact someone?

Before writing the request, imagine reviewing the answer. Name the output you want and the checks you will perform. If you cannot describe a check, reduce the scope until you can.

A brief in six parts

1. Outcome: the concrete deliverable, not a vague activity.
2. Inputs: the material that may be used and which source takes priority.
3. Scope: allowed actions and explicit exclusions.
4. Approval: where the agent must stop and ask.
5. Acceptance: observable checks for the result.
6. Uncertainty: how to report missing or conflicting evidence.

Keep these proportional to the task. A small comparison needs a short brief, not a policy manual.

A worked example: two conflicting notes

Suppose you supply these fictional notes:

Now give a bounded request:

Outcome: Write a decision brief of at most 200 words.
Inputs: Use only Note A and Note B. Treat B as the later note.
Scope: Read the notes; do not edit them, browse or contact anyone.
Approval: Ask before any action outside this scope.
Acceptance: List the handoff date, draft owner and budget status.
Attach the source note to each finding. Explain any inference.
Uncertainty: Do not turn missing information into a decision.
End with the questions that still need a human answer.

What a defensible result looks like

• Handoff: Friday. Note B explicitly updates the Thursday proposal in Note A.
• Draft owner: Maya. Note A names Maya; Note B says the owner has not changed. This conclusion combines both notes.
• Budget: approval was pending in Note A; current approval is not established. Note B contains no decision. Silence is not approval.
• Open question: has the budget been approved since those notes?

The distinction in the third item matters. “No update” does not prove that a real-world decision never happened. It only limits what these inputs support.

Review the deliverable in three passes

1. Coverage: are the requested date, owner, budget status and open question all present?
2. Support: can you point to the source for each statement? Are combined conclusions labelled rather than presented as direct quotations?
3. Scope: was the task completed without changing sources or taking an unapproved action? Inspect available execution details; do not rely only on the final answer's claim.

If a check fails, name the failure precisely. “The budget conclusion is unsupported; revise it using only the two notes” gives a clearer correction than “try again.”

Handle interruptions before retries

For a read-only brief, repeating a step is usually different from repeating a payment, publication or message. If work is interrupted around an external action, establish whether that action already happened before trying it again.

Use a status such as “completion unknown; confirmation needed” when the evidence is inconclusive. An honest unresolved state is safer than a guessed success or an accidental duplicate.

Increase scope one boundary at a time

Once a small task is reviewable, you can add another source or a new output format. Treat permission to publish or send as a separate change, not an automatic reward for a good draft.

The reusable habit is simple: define the outcome, name the evidence, limit the actions and inspect the result. For the corresponding product vocabulary, read AgReady's core concepts.