I've started offering one-page websites to small local businesses in Turkey: vet clinics, dietitians, beauty salons. The idea is simple. Someone finds the business on Google Maps, taps the website link, and lands on Instagram, where the opening hours and services are buried somewhere in a grid of photos. A single page fixes that.
To find businesses worth writing to, I need a list: a good rating, enough reviews, and no real website. On 18 October 2026 I asked my AI assistant for that list; it scoped a first wave and handed the search to an agent. About twelve minutes later (18:51–19:03 Istanbul time) the agent came back with 261 candidates from 42 searches, covering 14 provinces and three business types. Each row had a rating, a review count and a status column: "Instagram only", "no website", and so on.
The table looked finished. This post is about the one row that got checked, why one row was enough to stop trusting a whole column, and what I do with the list now.
The rule I use for agent output
I have a standing rule for anything an agent hands me: before a delivery is used, one claim from it is picked at random and verified against the source, by a different path than the one that produced it. If the claim holds, the rest is accepted for now and work moves on. If it fails, that slice of work goes back to full verification.
The rule is cheap on purpose. Checking every row of every table would make the agent pointless. Checking nothing turns the agent's confidence into my claim, and I am the one whose name is on the message. One random check is the smallest amount of evidence that can still say no.
In my setup the check is usually run by a second AI assistant, in a separate run from the agent that built the table. It does not reuse the agent's data. It opens the source the way a person would.
The check
The row that came up was a vet clinic. The status column said "no website".
The check opened the clinic's own Google Maps page. In the website slot there was a link, and it pointed to whatsapp.com.
So the agent was not exactly wrong about the thing I cared about. The clinic still has no real website; a WhatsApp link is not a page that lists services and hours. The clinic was still a good candidate. But the column did not mean what it said. "No website" in the table most likely meant "nothing in the website field of the data the agent read". On the page a person sees, there was a link in that slot. If I had written "your listing has no website link", the owner would have looked, seen a link, and stopped reading.
That was enough. The check failed, so the column failed, for all 261 rows.
Why one failure condemns the column
The tempting move is to fix the one row and keep going. It feels proportional: one error out of 261 is under half a percent.
But that number is not real. Nobody measured an error rate of 1 in 261. What was measured was 1 failure in a sample of 1. A single check cannot estimate how often the column is wrong. A pass tells you very little; a fail tells you the rate is not zero. Before the check I was assuming close to zero, because the table looked clean. After it, I had no estimate at all, only one known failure and one known reason.
The reason matters more than the count. The mismatch was not a typo. It most likely came from the difference between where the agent read the data and where a person reads it. I did not open the agent's raw data for that row to prove it, but nothing else explains it as well. Any row could have the same gap: an Instagram link, a booking page, a WhatsApp link, a link added last week. When the cause is systematic, the error is too, and you cannot know which rows it touches without opening them.
There is a second reason. The status column was the one field my messages depended on. Rating and review count go into a message as context; if one is slightly off, the message is still true in substance. The status column is the premise. "Your listing sends people to Instagram" is either true, or it is a cold message from a stranger who did not look. A wrong row costs more there than anywhere else in the table, so the bar for trusting that column should be higher too.
What full verification looks like here
Re-checking 261 pages in one sitting would be wasted effort. I send at most five messages a day, so most of those businesses will not hear from me this month.
So the list is now a queue, not a source of truth. The header of the file says the status column is weak. Each row is measured again right before it is used, against the business's own page: is the Instagram account still theirs, what is actually in the website slot, are the rating and review count still close to the table. Only then is the message written, and it only states what that check saw.
This moves verification from "once, at the start, for everything" to "once, at the moment it matters, for one row". The measurement is also fresh when it is used. A check from last week says little about today's listing.
On 19 October 2026 the first two rows from this list went out this way, together with three businesses from an earlier, hand-picked batch. All five were re-measured shortly before sending (19:14 Istanbul time) and all five held. That says something about those rows. It says nothing about the rest, which is exactly why they stay in the queue marked weak.
The parts I'm still not happy with
Two things are open.
First, none of these checks was me opening a page with my own eyes. The re-check on 19 October was another agent run. It was told to read each business's own page, not the search data the table came from. That separation is the same thing that made the first check useful. But it is still an agent's statement. If both agents share a blind spot, sampling one with the other will not find it, and I do not have a test for that yet.
Second, the failure was caught because the random draw happened to land on a bad row. A different draw could have landed on a good one, and the same flaw, in however many of the other 260 rows it sits, would have been trusted. One check gives a "no" with some probability; it never gives a clean "yes". I accept that, because the alternative is checking everything, always, which in practice means nothing gets checked carefully.
What I took from it
- A table that looks finished is a claim, not data. The agent's confidence is in the formatting. It does not transfer to the content.
- One random check per delivery is the minimum, and it can only veto. A pass means "no evidence against", not "verified".
- When a check fails, ask why before you count. A typo is local. A mismatch between the agent's source and the human's view is systematic and spreads to every row.
- Verify at the point of use. A row checked minutes before a message goes out is worth more than a whole table checked once.
- Write the uncertainty into the artifact. My list now says in its header that the status column is weak. Anyone who opens the file, including a future agent, sees that before row 1.
A question for you
If you use agents to collect data you then act on (outreach lists, dependency inventories, test inventories), how do you decide what to spot-check? Mine is random. I am starting to think the field the action depends on should be checked every time, and only the rest sampled. Have you found a better split?
This post was written with AI assistance. The candidate list, the random check and the re-check were produced by AI agents working under my rules; the rules, and the calls on what to do with the results, were mine. Measurements: 18–19 October 2026, Istanbul time.
Top comments (1)
The distinction between a sample of 1 failing and a 1-in-261 error rate is the part most people skip. A fail tells you the column's meaning is wrong, not how often. One cheap addition: record what the status was derived from (field empty, field absent, link present but not a real site) so a column like no website splits into those cases. The WhatsApp link would then land in its own bucket instead of silently counting as no website, and the same check works on every future run.