Check whether the result was any good

Why a successful run needs a second question

An agent reports success when its code finished without an exception. That says nothing about whether the brief was met: the report might cover four competitors out of five, cite a source that does not support the claim, or answer a slightly different question. The only reliable check for work like this is a person who knows what good looks like, and that decision deserves its own record.

How an outcome reaches a reviewer

At the end of a run, the agent reports what it produced: a label, a status (succeeded, failed or unknown) and, optionally, a SHA-256 digest of the artifact so the reviewer can confirm they are looking at the same file.

client.outcome("weekly market brief", status="succeeded", artifact_digest=digest)

The outcome appears in the workspace as unreviewed. A reviewer opens the actual deliverable where it lives, compares it with the brief, and accepts or rejects it.

Two records that never overwrite each other

The agent’s report and the person’s decision are stored separately and neither can change the other.

• The reported status is immutable once received. A later report with different wording does not rewrite it.
• The review decision records who made it and when.
• The history keeps every change, so you can see that an outcome was accepted, then rejected after a second look.

Using rejections to improve the agent

A single rejection is a bad result. A pattern of them is a specification problem. Look at what rejected outcomes have in common (missing sources, the wrong format, unsupported conclusions) and change the workflow you own: the prompt, the retrieval step or the definition of done. Then watch the acceptance rate for the next few runs rather than assuming the fix worked.

What review does not do

Toolcaise records the review. It does not open your documents, judge their accuracy or confirm they reached a client. Those checks stay with the reviewer and the systems the deliverable lives in.