Define done first: acceptance criteria an agent can be held to

When an agent hands back something disappointing, the usual reflex is to give it more: more time, more tool calls, a bigger budget, a longer prompt. Sometimes that helps. When the goal was vague, it does not. The agent spends the extra runtime producing a longer, more confident version of the same miss. The fix sits upstream, in a few sentences written before the work starts that say what done looks like.

Why more runtime does not rescue a vague goal

An agent always works toward something. If you have not said what, it settles on a stand-in: an answer that looks complete, a list that seems long enough, a report with the right headings. Given more room, it does more of that. A request like “research our competitors” has no stopping point, so an agent with a generous budget will keep finding companies, keep summarizing and keep spending, and you still will not know whether the result covers the companies you care about.

Vague goals also make review impossible. If nobody wrote down what the result should contain, the reviewer is left judging it on feel, and two reviewers will disagree. Clear criteria turn the review into a check against a list, which is faster and much harder to argue with.

What makes a criterion checkable

A good acceptance criterion passes a simple test: someone who did not write it can look at the result and say yes or no without asking the author what they meant. In practice, each criterion:

• Describes the deliverable, not the effort. “Thorough” and “high quality” describe how the work felt; “a table with these columns” describes what arrived.
• Is observable in the output. You can point to the place in the result where it is met.
• Names the evidence required. Which claims need a source, and what counts as one.
• Says what happens when something is missing. Otherwise the agent decides, and it may decide to fill the gap.
• States what is out of scope, including actions the agent must not take.

Weak and strong, side by side

Notice what the strong versions have in common. Each one tells you what the result contains, where its claims must come from and what to do with gaps. The duplicates example also limits the agent's authority: it produces a list, and any merging or deletion is a separate decision.

Write criteria for the gaps, not only the hits

The most often forgotten criterion is the one about missing information. Without it, an agent that cannot find a value has a quiet incentive to estimate it, and an estimate in a table looks exactly like a fact. A line such as “if a value cannot be found in the allowed sources, write ‘not found’ and list the sources checked” turns a likely fabrication into a useful open question. Missing evidence is an open question explains why that matters more than it seems.

The same goes for sources. If the answer should come only from certain documents or publishers, say so in the criteria and in the plan's source list; deciding which sources may answer covers that half.

Criteria define done; bounds define when to stop trying

Criteria and limits do different jobs, and you need both. The criteria say what a finished result must contain. Limits on wall time, tool calls and spend say how much effort the attempt may use before it stops and reports back. A run that hits its limit without meeting the criteria has told you something valuable: the goal, the sources or the scope need rethinking, and another run with a bigger budget probably will not change that. Put a ceiling on agent spend goes into setting those limits.

Where this lives in GoCux

In GoCux, every work order carries a goal, the scope it may touch and its acceptance criteria, and GoCux picks the skills the work needs. Orders also take bounds on wall time and tool calls; a bound of zero tool calls means the work may not call any tool. When the result reaches the decision state, the reviewer checks it against criteria that were written before the work began. And because an accepted order is not proof that the work was done, the criteria are read alongside the order's state, progress and attachments. The guide to specifying a task shows the fields, and durable task or conversation helps you decide when work needs an order at all.

A template and a pre-flight check

A short template covers most research and document work:

Goal: one or two sentences, phrased as the question to answer.
Scope: project, documents or sources allowed, and what is out.
Done when:
  - the deliverable contains ... (columns, sections, format)
  - every claim of type ... cites a passage from an allowed source
  - missing values are marked 'not found' with the sources checked
Not allowed: actions the work must not take (send, delete, export ...)
Bounds: time and tool-call limits for this attempt

Before you start the run, check:

• Could a colleague mark each criterion pass or fail without asking you?
• Does every criterion describe the output rather than the effort?
• Is there a rule for missing information?
• Are the allowed sources and the forbidden actions written down?
• If the run hits its limits, will you know which criterion it failed?