Verification before done

When an AI coding agent says the work is done, I want something to inspect. Has the code been written? Has it run? Has the behavior someone asked for been checked? Those are three different stages, even when they arrive in one confident summary.

My project Constellation brings coordination and verification into the same workflow. I authored it to orchestrate coding agents across Claude Code, OpenCode, and Codex, using model dispatch, file queues, and verification gates to turn objectives into tested programs. It runs locally and on a VPS.

The distinction between producing work and accepting it matters well beyond that architecture. Here is how I would approach verification when setting up an AI coding workflow.

Decide what a good result looks like

Imagine asking an agent to build a small program that summarizes a file. Before it starts, several questions deserve answers. What file format should it accept? What should happen when the file is empty? What counts as a correct summary? Should the input remain unchanged?

A program that prints something has satisfied a much weaker requirement than one that handles those cases correctly. If the criteria appear only after the code arrives, it becomes easy to judge the result by whatever it happens to do well.

I’d start with a short list of observable requirements. Each should lead to a check: a test result, an inspected output, or a manual review. Subjective requirements deserve a place too. If a summary needs to be understandable to a non-specialist, name that audience before deciding whether the writing works.

Give the next agent a clear handoff

Multi-agent work adds handoffs. One agent produces something another must understand. A long conversation can contain the necessary context, but it can also bury the current task among abandoned ideas, corrections, and earlier versions of the work.

Constellation uses files and queues as the coordination medium. More generally, an explicit handoff gives the next participant a smaller, clearer account: what was requested, what was produced, where to find it, and what still needs checking.

The file is a place to keep that information, not a substitute for getting it right. A useful handoff should let the next agent examine the actual output rather than depend entirely on the previous agent’s description. It should also make unfinished work easy to find.

Allow the check to stop the work

A verification gate needs the possibility of a negative answer. If every outcome becomes success with a longer explanation attached, the gate is only a delay.

For the imagined file program, a test might show that ordinary input works but an empty file causes a crash. The next step should follow the requirement. If empty files must be handled, repair the program and test it again. If they are outside the agreed task, state that limitation clearly enough for someone using the program to see it.

Keep the test outcome separate from the judgment about readiness. A test records what happened under particular conditions. Accepting the software for a use requires deciding whether those conditions cover the important risks. That judgment deserves attention even when every recorded check passes.

Choose evidence that fits the question

A second model can offer a useful critique, but two models agreeing that code looks correct is different from executing it against a known example. They may share an assumption or overlook the same missing requirement.

Match the check to the behavior. A calculation needs examples with known answers. A visual interface needs inspection of how it renders. A message sent to an external service needs evidence at the receiving end, beyond confirmation that a request was submitted.

For the file-summary example, an output could be technically valid and still omit the most important information. Running the program and reading the summary answer different questions. A sensible review makes room for both instead of expecting one check to stand in for the other.

Make completion useful to the next person

I’d want the final report to say what changed, what was checked, and what remains unresolved. Include where to find the result and enough detail to understand the checks. The reader should be able to choose a next action without reconstructing the entire conversation.

That is the kind of clarity I want from AI workflows. Generating code, coordinating contributions, and verifying behavior are distinct jobs. Giving each a place makes it easier to understand what has actually been accomplished when an agent reaches the word done.