# How do I give my AI agent a definition of done?

_Give agents a testable definition of done with observable criteria, required evidence, approval gates and an honest fallback when checks cannot run._

By Saad Ahmed, 2026-10-20

To give an AI agent a definition of done, translate the desired outcome into observable checks and state what evidence must be returned for each one. Also name the actions that require approval and the status to use when a required check cannot be completed.

A good definition of done lets a fresh reviewer reach the same conclusion as the agent. “Build the feature” or “make it production-ready” is a goal, not a verification rule.

## Write outcome-based criteria

Start with what a user, operator or system should be able to observe. Then add the quality and delivery gates that matter.

For a web change, criteria might say:

- the named route renders the required content;
- keyboard navigation and responsive layout work;
- unit, type and production-build checks pass;
- the pull request is reviewed and merged;
- the deployed URL contains the tested change;
- no unrelated behavior or claims were added.

Make every criterion specific enough to test. Prefer “the endpoint returns 401 without a valid session” to “authentication is secure.”

## Pair each criterion with proof

Tell the agent what evidence to attach: a URL, test command and result, commit, pull request, screenshot, trace or document. One artifact may cover several criteria, but the relationship should be clear.

Require honest exceptions. If an environment is unavailable, the agent should mark the task blocked or awaiting verification and name the missing check. It should not silently redefine done.

## Put the definition in durable project state

Store it in the issue, specification or tracked project file before the session begins. The agent reads it when claiming the task, reports against it during work and leaves evidence in the same place.

## Where ecco fits

An ecco task keeps the outcome and proof requirements beside ownership, decisions and artifacts. MCP-connected agents can read the definition before working and return commits, pull requests or test evidence to the task. A review state keeps submitted work separate from accepted completion.

[Connect an agent to ecco](/blog/connect-an-agent), or compare the shared task record with [Claude and ChatGPT used by themselves](/blog/ecco-vs-claude-and-chatgpt).

## A reusable template

```text
Outcome: [observable result]
In scope: [bounded work]
Out of scope: [explicit exclusions]
Done when:
- [criterion and required evidence]
- [criterion and required evidence]
Approval required for: [guarded actions]
If a check cannot run: [blocked or review status and next step]
```

## Frequently asked questions

### How many definition-of-done criteria should a task have?

Use the smallest set that proves the outcome and important risks. A focused task may need three to six criteria; a large list often signals that the work should be split.

### Should the agent write its own definition of done?

It can draft one, but a person should settle criteria involving product intent, risk or acceptance before consequential work begins. The executor should not lower the bar after seeing the result.

### What if the requirements change during the task?

Record the decision and update the definition explicitly. Do not leave the agent choosing between a stale written criterion and an undocumented chat instruction.

### Is a checklist the same as proof?

No. A checklist states what must be true; evidence shows why a reviewer should believe it is true. Keep the criteria and the supporting artifacts connected.