An AI information workflow: where human review belongs
Design a small workflow that retains sources, exposes uncertainty and pauses before taking action.
Checking local voices…
In brief
Design a small workflow that retains sources, exposes uncertainty and pauses before taking action.
On this page
Start an information assistant with a narrow question: can it summarize selected sources and show where each claim came from? This is a design example for a personal experiment, not a deployed client project or a measured success rate.
Separate collection from action
Choose three technical documents manually. Retain each document's title, address and review date. Instructions found inside a page must not become authority for your system. A model-generated summary must not replace verified evidence either.
Display claims beside their sources. Mark an unsupported sentence as unverified rather than quietly filling the gap. Investigate dates and versions when documents conflict. Fluent writing alone is not evidence of correctness.
Put approval before the action
n8n's human-in-the-loop tool approach lets a person approve or deny before a tool runs. Place consequential steps, such as notifications, record updates or publishing, behind this gate. The review screen should show the destination, proposed action and data involved.
An initial “continue” is not meaningful approval for a different action proposed later. Treat denial and timeout as separate outcomes. Design an operation identifier and duplicate check so a retry does not send the same email twice.
Send or stop?
A safe simulation. No real requests, messages or payments; choices stay on this page.
A small acceptance test
Try a relevant document, an unrelated document and a sample containing misleading instructions. Write down the expected outcomes first. The purpose is to expose failures such as accepting the wrong source or acting without approval, not to manufacture a success percentage. The steps below are explanatory and do not start a live automation.
Treat the approval screen as a decision record
Suppose the workflow prepares a weekly note from three product documents. A screen that merely asks for approval hides the decision's substance. Show the destination, final message, supporting links and any attachments together. Someone may agree with the wording while objecting to the recipient. If the text is edited, make it clear which version the decision covers. The review step should explain the proposed effect rather than offer a decorative confirmation button.
A useful distinction is between preparation and execution records. Preparation contains evidence and a proposed action. Execution records which proposal was acted on, for which destination and following which decision. A small table can express this distinction in a personal experiment. Before building an elaborate dashboard, explain how the same preparation record would be prevented from generating duplicate external actions.
Silence is a separate state
After a notification arrives, the reviewer may not respond. A link may expire, or the information on the screen may become outdated. Keep pending, rejected and expired decisions separate instead of converting silence into approval. When reopening an expired proposal, show its current text and destination again. Urgency does not make invisible changes part of an earlier decision. A useful interface tells the operator both what is waiting and what would happen next.
Another difficult case is losing the response after the provider has accepted an operation. A failed-looking workflow does not prove that a message was never delivered. Before retrying, examine the provider's operation lookup and duplicate-prevention facilities. In a test, submit the same preparation record twice. The desired behavior is understanding the previous operation's state rather than issuing two messages and hoping that only one arrives.
Separate three classes of failure
Start with an evidence failure: can the workflow identify a date or feature absent from the source? Then try a permission failure: can an instruction inside a document introduce a new destination? Finally, test a state failure: does restarting a rejected record accidentally send it through the execution path? These cases reveal different problems and should not all be blamed on the model's writing quality.
Record the expected outcome and actual observation for every example. Keep a successful ordinary example too, because a fix can break the normal path. If you cannot explain a control's purpose in one sentence, simplify its design. The point is not to add friction everywhere. It is to make the moment of human judgment real, informed and connected to the exact action that follows.
Source
Next step
Continue with Estimate an AI request cost: tokens and limits, or download this guide and its working notes as a PDF.
Frequently asked questions
Does every AI step need approval?
Different actions deserve different controls. Preparing a summary from sample text has a different effect from sending a message to another person. Define permissions per operation and put meaningful review before changes or external disclosure.
What if the approved text changes?
A changed payload, recipient or attachment may fall outside the earlier decision. Show the new version instead of silently reusing the approval. Connect the decision record to the version that was actually reviewed.
Does a source link establish truth?
No. A link makes examination possible; it does not establish that the source supports the claim. Relevance, date, version and surrounding context still matter. A long bibliography cannot compensate for evidence that nobody checked.
How can I detect instructions hidden in a document?
Include an out-of-scope instruction in a test document and define the expected behavior first. The content should remain data and should not authorize an external action. One successful test does not prove resistance to every possible prompt injection.
Does the checklist run an automation?
No. It is a design exercise and sends no operation to an external provider. Your implementation still needs actual target checks, permission controls, operation identity and tests using an isolated environment.