The job was an opinion, not another summary
The brief asked for an opinion piece about the future of findability, supported by real data, with realistic scenarios and different models challenging the argument. Would Google still matter? What should a business actually do?
The result was Google will survive. The click is less certain., published on 20 October 2026. This walkthrough follows that completed run. It is not a fictional client example or a claim that every DLVX article follows an identical process.
Our working definition of done was a defensible position, evidence with dates and limits, plausible alternatives, and a page that readers could use on a phone. We did not measure hours saved or sales caused by the article. Publishing it proved that the workflow could produce and deliver this piece; it did not prove commercial impact.

Turn the rough request into decisions
Before drafting, we settled the reader, question and boundaries. The reader was a business owner deciding how customers might find and evaluate them. The article needed a view, not a list of AI products. Thailand mattered, but US or French research could not silently become evidence about Thai buyers.
We chose a planning horizon of 2027 to 2029 and separated things observed today from things we expect. We also ruled out invented customer stories and numerical probabilities without a model to justify them. These choices became the brief that the research and writing work shared.
The important human input was the owner's intent and quality bar. AI agents performed the research, writing and review passes described below. We are not claiming a human expert separately approved every source. If your article depends on professional judgement, assign a qualified person to that review explicitly.
Decision to copy: agree what the reader should be able to decide after reading. “Write something about AI” gives the writer freedom to produce a polished answer to the wrong question.
Give research jobs that can disagree
We split the research into three questions: what supports Google's staying power, what the click evidence actually measures, and how Thailand changes the interpretation. The run used GPT-6 Astra, GPT-6 Sol and GPT-6.1 Sol for those assignments. These are variants within one provider's model family; using them did not create independent scientific evidence.
Each researcher had to return original links, the publication date, the period the data described, the population or event counted, and what the result could not establish. A writer then worked from those notes. Separating the jobs made a weak inference easier to challenge than asking one model to research, write and approve its own answer in a single response.
For example, a search referral percentage does not count every decision made in a chat app. A product announcement does not establish how many people completed an order. If those distinctions disappear from the notes, they usually disappear from the article too.
For a smaller team, use one research pass and a fresh review conversation. Give the reviewer the draft and source links, without telling it that the draft is already correct. Another model can help challenge assumptions, but reopening the source does the evidential work.
Keep the limitation beside the number
One source was Pew's study of Google result clicking. It reported different click rates for pages with and without AI summaries. The useful question was what those rates counted, and whether the study could establish that AI caused the difference. We retained its US population, historical observation period and reconstruction caveat rather than treating it as a worldwide traffic forecast. Read the original study.

The working record kept four things together: the proposed claim, the original source, the allowed interpretation and the caveat. A source link alone was insufficient. A page can contain the number and still fail to support the sentence written around it.
We used the same discipline for opinions. A prediction needed a visible label and a condition that would change our mind. “We expect” is an editorial judgement; adding a citation does not turn it into a measured outcome.
The sentence that sounded reasonable and failed review
The draft described shoppers completing purchases on merchants' stores through an in-app browser. That wording was too broad. The source described that route for Shopify, while also describing a Walmart experience inside ChatGPT. The draft had compressed different arrangements into one general account. The announcement shows the distinction.

We narrowed the wording to the Shopify path and named the Walmart alternative. A later pass caught another small problem: buyers complete purchases, not merchants. Neither correction needed a more impressive sentence. Both needed a more exact one.
The review also challenged the argument. Search, Maps and YouTube can look like different places to get found while sharing an owner. We added that distinction and made clear that the future scenarios could coexist. Those changes improved the reasoning, rather than merely polishing the tone.
Stop rule: when a source supports one example and your sentence implies a general rule, narrow the sentence or find evidence for the general rule. Do not ask another model to make the broad claim sound safer.
Use a visual only when it explains something
The article needed to compare two observed click rates, so we used a simple bar chart. The labels state the rates, and the caption identifies the study and the limits of the comparison. We did not add a probability chart for the future scenarios because we had not estimated their probabilities.

The scenarios use expandable conditions. Readers can see the basic argument without clicking; the controls reveal what would strengthen or weaken each case. No looping animation was necessary to understand either the evidence or the choices.
A useful test before making a visual: what will the reader understand faster because this exists? If the answer is only “the page will look more AI”, leave it out.
Check the delivered page, not just the draft
Once the wording was settled, we checked the page on a hosted preview and a production candidate before publication, then opened the public URL again. The checks covered desktop and mobile, source anchors, the scenario controls, navigation and the page's place in the Academy. The saved live browser receipt records six renders across the article and its two discovery pages.

Two things went wrong around verification. The automated visual judge returned a service error, so it could not certify anything. We used a separate model to inspect the actual screenshots through the documented alternative review path. That was model-based visual review, not human approval.
The first browser request immediately after promotion returned a 404 for the new article. We did not call that a pass. Separate checks then confirmed the public article matched the saved source, and a fresh complete browser run passed without a code change. Release propagation was a possible explanation, but the cause was not established.
You do not need our deployment system to copy the principle. On your own publishing tool, open the actual public link, test the important controls and check it on a phone. A successful publish notification does not show what a reader received.
Copy the useful parts of the workflow
These prompts are adapted teaching templates derived from the run, not verbatim exports of the original agent instructions. Use sources you are allowed to share with your chosen tool. Start with one article and a small set of material claims.
Research brief
Reader: [who is making a decision] Decision: [what they should be able to decide] Question: [one precise question] Geography and language: [scope] Evidence cutoff and forecast horizon: [dates] Return original source links. For each material claim give: publication date; data period; what was counted; what the evidence supports; what it does not support. Find the strongest evidence against our proposed position. Keep measured results, vendor claims and our opinions separate. Do not invent examples from our business.
Independent review request
Review the attached draft against the original sources. Do not rewrite it yet. For each material problem, return: the exact sentence; source passage or location; why the sentence exceeds the evidence; the smallest correction that resolves it. Check dates, populations, denominators and causal language. Look for a single example expanded into a general claim. Identify the strongest missing counterargument. Mark anything you could not verify. Agreement is not proof.
Final publication check
Claim | Original source | Data period | Allowed wording | Limitation [Fill one row for each claim that could change a reader's decision.] Before publication: Resolve every material review finding. Recheck claims changed after review. Label predictions and illustrative examples. Confirm permission for screenshots and quotations. After publication: Open the actual public URL on desktop and mobile. Follow source links and test the important controls. Confirm the delivered copy matches the approved version. Record unresolved issues and the person who owns them.
Download the plain-text prompt pack
For a small team, the minimum is a brief, a claim record, a draft and a separate review. One person can coordinate those steps, but should not silently turn an unverified model answer into a company claim. For bilingual work, keep the same evidence boundaries in each language and have a capable speaker check the final wording.
What this run proves, and what it does not
It proves we used this process to publish this article, retained the review finding, corrected the scope of a claim, and checked the delivered page. It does not prove that three models are better than every other setup, that all errors were caught, or that the article generated a lead.
The result we would repeat is the decision process: give the work a clear purpose, preserve the boundaries of the evidence, make a reviewer name the exact problem, and check the version a reader actually gets. The extra model mattered less than giving it permission to say the sentence was wrong.
Evidence note: the source check and review excerpts come from the saved 20 October 2026 run. Screenshots on this page were captured later that day from the public article or from those saved excerpts displayed in a browser. Text views are labeled. No screenshots are AI-generated. The full internal run records remain with DLVX; the linked excerpts expose only the relevant editorial evidence.
Read the finished opinion piece or learn how to compare AI outputs without favouring a model name.