Treat an AI agent screenshot as evidence of a visible state within a known capture. It can show a clipped heading or a displayed error. A success banner alone cannot establish that a record was saved in the right account or that another person can open the result.
Start with the sentence the image is meant to prove. “The confirmation message appeared” is narrower than “the task is complete.” This reference helps reviewers accept the useful observation while requesting the missing evidence for a stronger claim.
- 01Write the claim first.The same image can support a layout observation and fail to support a completion claim.
- 02Keep capture context.Save the page, account scope, build or revision, time and viewport with the image.
- 03Check beyond the frame.Interaction and destination checks answer questions that pixels alone leave open.
01 — Match the image to the claimMatch the image to the claim
Each row names a claim, the observation a genuine relevant capture can support, and the missing check. This is not a pass/fail score for image quality. A screenshot may be sufficient for the narrow visible-state claim while remaining insufficient for a broader delivery promise.
| Claim and group | What the image can support | What still needs checking |
|---|---|---|
| Visible state: Text and layout | A heading, chart label or arrangement is visible at the capture size | Other viewports, hidden content and whether labels match the underlying values. |
| Visible state: Error message appears | The captured state contains an error message | Whether the message describes the actual failure. |
| Interaction: Button or menu | The control’s appearance in the captured state | Activation, selection, dismissal and the resulting application state. |
| Interaction: Keyboard focus works | A captured focus indicator is visible | Reachability, focus order and movement through the flow. |
| Interaction: Loading completes | A captured frame shows one loading or completed state | The transition, duration and eventual result. |
| Stored outcome: Form was saved | A success message is shown | An identifiable record exists in the intended destination. |
| Stored outcome: File was exported | The interface shows an export result | The actual file opens and contains the requested content. |
| Stored outcome: Change was published | A publishing confirmation is visible | The intended public URL serves the changed content. |
| Stored outcome: Record was removed | A removal message or empty view is shown | The correct record’s state, including active filters. |
| Capture context: Cropped image | The selected region’s pixels are preserved | Excluded notices, account identity and surrounding content. |
| Capture context: Full-page image | A full scrollable page is represented by the capture tool | Hidden dialogs, nested scrolling and interactive states. |
| Capture context: Old image reused | The file contains a previously captured appearance | Capture time, build identity and current applicability. |
| Capture context: Unknown origin | Only the supplied image content can be inspected | Who captured it, where, and whether it was altered. |
02 — Capture scope is part of the evidenceCapture scope is part of the evidence
Playwright’s screenshot documentation distinguishes full-page captures from captures of a single element. That makes the capture method consequential: a cropped button image and a full-page image do not contain the same context.
The W3C accessibility evaluation overview explains that tools cannot determine accessibility on their own and that knowledgeable human evaluation is needed. A screenshot is one input to a review, not an accessibility verdict.
03 — Keep a small record beside the imageKeep a small record beside the image
An evidence record should identify the task, the page or application, the relevant account or workspace, the time of capture and the build or document revision where available. Add the viewport size and the action immediately before capture. Those details let another reviewer understand why this image is relevant.
Retain the original capture separately from an annotated copy. Arrows and highlights can make a defect easier to explain, but record any cropping or redaction. Do not remove a warning or account label and then use the edited image to support a claim that depends on the missing context.
Protect confidential content when sharing evidence. An internal original and a redacted review copy can serve different purposes. If the recipient cannot inspect a critical detail, state that limitation rather than implying they verified it.
04 — Pair appearance with a destination checkPair appearance with a destination check
Suppose an agent updates a public biography. The editor screenshot shows the revised text; it is useful evidence that the editing interface displayed the change. A fresh request to the public page tests a different claim: whether the intended audience can see it. Record both if the assignment required publication.
For a saved file, keep the file itself and open it with the expected application. For a created record, retain an identifier and inspect the intended destination. Avoid treating an empty filtered list as proof of deletion. The relevant check depends on the promised outcome, not on which screenshot is easiest to obtain.
The file-output acceptance reference covers deliverable checks. The browser-or-API reference helps choose how to inspect an outcome when both interfaces are available.
05 — Ask for the missing check, not more screenshotsAsk for the missing check, not more screenshots
If the evidence gap is keyboard behavior, another static frame may add little. Ask for a short, reproducible interaction and its result. If the gap is the saved destination, inspect that destination. If the gap is capture age, rerun the relevant check against the current revision.
Request the smallest observation that resolves the unsupported claim. Another image of the same state adds little when the missing evidence is a saved record or keyboard interaction.
For appearance-focused work, the screenshot-driven development guide explains the visual critique loop. The distinction here is what you may conclude from its output.
- Scope
- Visible states, interactions, stored outcomes and capture context, with the follow-up evidence each requires.
- As-of date
- September 7, 2026. This is the actual source collection and review date; publication is assigned to the September 6 batch.
- Collection
- Read capture-scope and accessibility guidance, then distinguish each visible observation from the stronger outcome claim. Follow-up checks are editorial recommendations.
- Sources and interpretation
- Playwright documents capture scopes. W3C explains that accessibility evaluation requires knowledgeable human evaluation in addition to tools. The evidence matrix and required follow-up checks are editorial reasoning, not measured detection performance.
- Exclusions
- No vendor census, model benchmark, search-volume estimate or observed failure rate. Examples are hypothetical; no customer operations were tested.
- Gaps and limitations
- UNVERIFIED means the supporting evidence has not been inspected. Similar cases can overlap in practice; classify the particular claim or operation, and retain uncertainty when the distinction cannot be established.
06 — DecisionWhat to do next
Accept the observation the image actually contains.
Keep a screenshot when it answers a visible-state question. Pair it with an interaction, artifact or destination check when the completion claim extends beyond the frame.
For implementation support, explore our AI transformation services.