Review AI-agent work with the evidence beside it.

Define acceptance before implementation

Write criteria that describe observable behavior. For a website change, that could include readable phone layouts, working links and a form that accurately reports whether a request was delivered. For a code change, use checks suited to the actual behavior being changed.

TM8 tasks can carry acceptance criteria alongside connected conversations and sessions. That gives a reviewer a shared reference, rather than a different definition of done for every agent.

Ask for evidence that supports the claim

A build passing shows that a build passed. It does not prove a browser interaction works, a customer received an email or a production rollout succeeded. Match the evidence to the claim you are reviewing.

Bring the changed files or artifact, the relevant test results and a concise explanation of remaining limitations into the handoff. A screenshot can explain visual behavior; it cannot establish a complete signup journey by itself.

• Implementation: what changed and why?
• Verification: what was exercised, in which environment?
• Limits: what has not been checked?
• Decision: what should happen next, and who will decide?

Give review its own focused session

A separate review session can examine the implementation against the brief and look for gaps in the reported checks. Keep the review connected to the same task, while giving it a specific question to answer.

This is a workflow choice, not a guarantee that an AI reviewer will find every defect. A person should evaluate consequential decisions, unresolved risks and work that requires real-world confirmation.

Keep release and verification visible

A release handoff should identify the exact deliverable, explain how it was checked and define a way back if the change fails. After release, verify the behavior in the environment people actually use.

We used this pattern while building the TM8 marketing website: design and implementation were followed by browser checks, a checksum-based handoff and separate live verification. The linked first-party story explains what that process established and what it did not.

• Check the intended deliverable before release.
• Preserve the information needed to identify the deployed version.
• Verify live behavior and record anything still unproven.

Common questions