← All articles

Write the done check before the prompt: narrowing an AI agent's job

The Guildwise HQ team · 10 October 2026 · 5 min read

• How-to
• AI agents

Most agent failures start with an unwritten finish line

When an AI agent returns weak work, the first instinct is to blame the model or rewrite the prompt. Often the real gap is simpler. Nobody wrote down what finished looks like, so the agent picks its own version of done.

Requirements engineering has dealt with this problem for decades. Acceptance criteria spell out the conditions a story must meet before it counts as complete, and they make an otherwise vague request less ambiguous. The same logic applies when the worker is an agent. A short instruction such as 'clean up the release notes' leaves almost everything open.

A recent preprint on task construction makes a related point about LLM agents. Most optimization methods assume that output schemas and evaluation criteria are already fixed. For many real tasks, a short goal does not determine them, and writing them by hand is costly. The practical lesson is that the finish line has to be designed as deliberately as the prompt.

Narrow does not mean trivial

A narrow job has a clear trigger, a fixed kind of output and a known set of tools. It is not the same as a small or easy task. A narrow job can still touch several systems, as long as its boundaries are explicit.

Anthropic's engineering team reports that the most successful implementations it saw used simple, composable patterns rather than complex frameworks. The same post notes that much of its tooling advice dates from December 2024 and has since changed. Treat any specific pattern as dated. The principle of keeping the design simple still holds.

OpenAI's practical guide for product and engineering teams takes a similar position. It distills lessons from many customer deployments into guidance on choosing use cases and designing agent logic.

In practice, a narrow job usually has four properties:

• one trigger, such as a new pull request or a new support ticket
• one kind of artifact out, such as a diff, a single file or a filled-in form
• a short list of tools, with write access only where the job needs it
• an explicit rule for when the agent must stop and hand over

If you cannot describe the job with those four properties, the job is not ready for an agent yet.

Write the done check before the instructions

A done check is a short document that answers one question: how will we know this run succeeded? Write it before you write the agent's instructions. It should have four parts.

1. Required outputs

List every artifact the run must produce, and the form each one must take. Be concrete. 'A summary' is vague. 'A markdown file of no more than 300 words with three headings, saved to the docs folder' can be checked.

2. Automatic checks

Write the checks a script or test suite can run without judgement. Examples include a build that must pass, a test suite that must stay green, a linter with zero new warnings, or a diff that touches only allowed paths.

3. Human sign-off

Decide which parts need a person to approve. Anything that is hard to reverse, touches customers or money, or changes security settings should have a named reviewer. Automatic checks cannot judge tone, fit or business risk.

4. Stop and escalate rules

Define when the agent must stop instead of trying again. Examples include two failed attempts at the same check, a need for a credential it was not given, or a change outside the allowed paths.

A worked example

Suppose the job is to update one pinned dependency in one repository. The done check might read as follows.

• Output: a branch with a changed manifest and lock file, and a pull request description that lists the old and new versions.
• Automatic checks: the build passes, the test suite passes, and the diff touches only the manifest and lock file.
• Human sign-off: a maintainer reviews the pull request before merge.
• Stop rule: if tests fail twice, or the update requires a major version change, the agent stops and writes up what it found.

Every item can be checked by someone who did not watch the agent work. That is the test of a good done check.

Why the check should not be the agent's own opinion

It is tempting to let the agent judge its own output. Research suggests that is the weakest option. A 2026 preprint on recoverable execution for long-horizon agents describes an admission pipeline for acceptance criteria. Criteria written by an LLM were kept only after passing deterministic checks. A reference solution had to satisfy every criterion, and the starting workspace had to fail, so that no task was already solved when the agent received it.

A separate 2026 benchmark for deployment agents uses four layers of binary checks covering build, readiness, behavior and conformance to the specification. It relies on programmatic checks rather than an LLM judge. It also re-deploys the agent's artifacts into a clean environment before checking them.

Both designs make the same point for practitioners. The check should run outside the agent's own reasoning, against a fresh copy of the work, and it should fail on the starting state. If the check passes before the agent touches anything, it is not measuring anything.

The NIST AI Risk Management Framework is voluntary guidance, and it is meant to help teams build trustworthiness considerations into the design, development, use and evaluation of AI systems. Evaluation is part of the job, not an afterthought.

A short checklist before the first run

• Can you state the trigger, the artifact and the tools in one sentence each?
• Is every required output described in a form someone can inspect?
• Does each automatic check run in a clean environment, outside the agent?
• Is there a named human who approves anything hard to reverse?
• Are the stop rules written down, including the number of retries?
• Have you run the check against the untouched starting state, and confirmed that it fails?

Common mistakes

The first mistake is defining done as 'the output looks good'. That standard shifts from run to run. The second is writing the check after seeing the result, which tends to fit the check to the output. The third is letting one agent both produce and approve the work. The fourth is giving the agent broad tools for a narrow job, which widens the range of ways it can finish in the wrong state.

The fix for all four is the same. Write the finish line first, keep the job small enough to check, and keep the judge separate from the worker.

Key takeaways

• Write the definition of done before the agent's instructions. Most weak runs trace back to an unstated finish line.
• A narrow job has one trigger, one kind of output, a short tool list and an explicit stop rule.
• Use automatic checks that run outside the agent, against a fresh copy of the work.
• Keep a named human in the loop for anything hard to reverse, and confirm that the check fails on the untouched starting state.

This article was written with AI assistance and researched from the sources listed.

Sources

1. Building Effective AI Agents
2. A Practical Guide to Building AI Agents
3. AI Risk Management Framework
4. AgentRewind: Recoverable Execution for Long-Horizon LLM Agents
5. FDE-Bench: Evaluating LLM Agents for Deployment
6. LLM-based agents for automating the enhancement of user story quality: An early report
7. From Weak Task Specifications to Scientific Extraction Agents: Optimizing Task Construction

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.