Review the work, not the confidence of the answer
AI-agent output can sound complete before it is correct. A polished summary may hide a missing source. A working draft may have crossed a boundary. A long activity log may still leave the main goal unfinished. Good review does not depend on whether the answer feels confident. It checks the result against the request and the evidence.
This does not mean repeating every step yourself. The reviewer should focus on the decisions and risks that matter. A simple five-check method works across research, writing, operations, and software tasks. It also gives the agent a clearer idea of what evidence to return next time.
Check 1: Did it solve the stated problem?
Begin with the original issue, not the agent’s final comment. Read the outcome and acceptance checks. Then compare the delivered artifact with them. A strong result answers the requested question, serves the named audience, and reaches the agreed stopping point. Extra work does not compensate for missing the central goal.
- Can you point to the requested output?
- Does it cover every acceptance check?
- Did the agent report anything it could not complete?
- Is the result in the location or format the team expected?
- Would another teammate understand what happens next?
If the task was vague, review may expose several reasonable interpretations. That is useful feedback. Clarify the issue before asking for a large revision. Do not make the agent guess which interpretation you silently preferred. A correction should narrow the goal and preserve what was already valid.
Check 2: Did it use the right sources?
Facts should have a traceable basis. For research, inspect the cited pages and their dates. For content, compare claims with the approved brief and source documents. For operations, confirm the report used the right project, period, and filters. For software, check the relevant specification, existing behavior, and project guidance.
Separate source failure from an empty result. “No risks found” is different from “the risk register could not be opened.” Ask the agent to name the sources it used and the sources it could not reach. When official wording matters, store the document in Knowledge Base rather than relying on a remembered summary.
Check 3: Is there evidence for the result?
A useful completion report contains evidence that matches the type of work. A research brief has citations and comparison criteria. A rewritten page has the final copy and a note about preserved claims. A project report links to underlying issues. A software change lists the checks it ran and any checks it could not run.
| Work type | Useful evidence | Weak signal |
|---|---|---|
| Research | Source links, dates, and stated comparison method | A confident conclusion with no path back |
| Writing | Final draft plus approved brief and claim checks | It sounds good to me |
| Operations | Time window, filters, item links, and exceptions | A count without the source set |
| Software | Focused diff, tests, screenshots, or reproducible steps | Changed the code successfully |
Evidence should be proportional to risk. A low-stakes internal outline needs less proof than a public claim or a production change. Ask for the smallest set that lets the reviewer decide. Too much undirected evidence can hide the important part as effectively as too little.
Check 4: Did it stay inside the boundary?
Review not only what changed, but what the task allowed to change. An agent may discover an adjacent problem while working. That does not automatically authorize a fix. Check whether it touched only the approved files, systems, accounts, dates, audiences, or records. Confirm that it did not publish, deploy, delete, spend, or contact someone without explicit authority.
A good agent reports useful discoveries as follow-up work. It can create or suggest a separate issue, explain the relationship, and stop. This keeps the original review focused and prevents a small request from turning into an unbounded project. Boundaries protect both the team and the quality of the result.
Check 5: What decision must a person make?
Every review should end with a visible decision. Accept the work, request a focused revision, block it on missing information, or create follow-up work. Do not leave an important result in an ambiguous comment thread. MagicAssist statuses help show whether the issue is waiting, active, ready for review, or complete.
The reviewer owns the decision even when the agent produced excellent work. Approval may confirm factual accuracy, brand fit, customer impact, security, budget, or technical quality. Name which kind of approval occurred. “Looks good” is less useful than “Sources checked; claim wording approved; ready to publish.”
Write revision requests that preserve progress
When work needs changes, identify the failed check and the smallest correction. Link the relevant source. Say what should remain unchanged. If the original goal changed, update the issue instead of pretending the agent misunderstood. This creates a clean record and reduces the chance of losing valid work during a broad rewrite.
- Name the check that failed: goal, source, evidence, boundary, or decision.
- Quote or link the exact place that needs attention.
- State the corrected requirement in one or two sentences.
- List any parts that are already accepted and should remain.
- Ask for new evidence only where the correction changes the result.
Use a new comment when mentioning an agent for the revision. In MagicAssist, a newly created mention starts work; silently editing an old comment does not. Keep the original request and revision in the same issue so the next run has the full conversation and the reviewer can see how the decision evolved.
Adjust review depth to the consequence
Not every output deserves the same ceremony. A private brainstorm can receive a quick sense check. An internal summary needs source and omission checks. A public article needs claim, tone, and approval checks. A production change needs technical evidence, access review, and a rollback path. Decide the review level before the work begins.
For recurring tasks, record the review method in a Skill. The agent can then return the expected evidence in a stable shape. Reviewers spend less time asking for missing details. If the same correction appears across several runs, improve the method or source context rather than repeating the comment forever.
Confidence comes from a visible chain: a clear goal, trusted sources, relevant evidence, respected boundaries, and an explicit human decision.
A two-minute review card
- Goal: the requested outcome is present.
- Sources: important claims trace back to current authority.
- Evidence: the result includes the proof needed for its risk level.
- Boundary: no unapproved action or scope expansion occurred.
- Decision: a named person accepted, revised, blocked, or followed up.
Use the card for the first pass. Slow down only where consequence or uncertainty demands it. The purpose of review is not to distrust every agent action. It is to make responsibility clear and help good work move forward without hiding the judgment that still belongs to people.