Your AI Worker Passed Its Launch Test. Who Checks It on Friday?

Launch day proves it once. Friday proves it still can

Picture a ten-person business in Bengaluru — a boutique, say, or a small services firm. A few weeks ago it put an AI assistant on enquiry duty: it answers routine questions from the business's own price list and service notes, in seconds, in the right tone. On launch day someone tested it twenty times, it passed, and the owner stopped dreading the enquiry inbox. The launch test did its job.

Then nobody checked it again. That is the normal story, and it is where the trouble starts — not with a dramatic failure, but with a quiet one. A delivery policy changes and the document behind the assistant does not. A model update shifts how it phrases an answer. Customers start asking a question nobody tested. Each change is small. None of them throws an error. The assistant keeps answering fluently, confidently, and — on a growing handful of questions — wrongly. The first person to notice is usually a customer, and by then the wrong answer has already travelled.

This post is about the cheapest habit that prevents that story: a 30-minute check, once a week, on a Friday, that asks one question — is the assistant still answering the way we would? It has three parts, one sheet, and one rule. Nothing in it needs a technical team.

Why a working AI worker drifts

Drift is not a malfunction. It is what happens when everything around a working system moves and the system itself stays still. Three things move, and all three are outside the business's control.

• The model moves. Providers update their models, and an update can shift phrasing, emphasis, or which detail an answer leads with — without any announcement the owner would notice. The assistant's answers change while its instructions stay the same.
• The documents move. Prices change, a return window changes, a courier partner changes. If the document the assistant reads from is not updated, the assistant will keep quoting the old version with the same confidence it quoted the new one. A stale answer is worse than no answer, because it arrives looking authoritative.
• The questions move. Customers ask about the thing that changed this week, not the things that were common at launch. A test set frozen on launch day slowly stops covering the questions that actually arrive — and a frozen measuring stick eventually measures a business that no longer exists.

The complaint evidence points the same way. G2's analysis of more than 2,950 verified AI chatbot reviews, as reported in a DEV Community write-up, found accuracy and hallucination the number-one buyer complaint, appearing in 13.7% of negative mentions — above cost. The same account reports that the four vendors surveyed in it, running continuous evaluation pipelines and updating prompts and logic at least weekly, report production failure rates as low as around 1%. Those vendor figures are self-reports inside that account, not independent measurement, so read them as direction, not proof. But the direction is consistent: the difference between a chatbot that stays trustworthy and one that does not is the checking wrapped around it, not the model underneath.

One small business's story makes the mechanism concrete — and it is one business's story, not a study, so it proves a mechanism, not a rate. A family-run homeware business put a chatbot on its product pages to handle delivery and returns questions, because a two-person service team was drowning in the same dozen questions on repeat. The bot had no rule for what to do when it did not know an answer, and nobody was reading its transcripts. During a known courier disruption, a customer asked about a delayed order and the bot cheerfully repeated the standard delivery line four times in a row, ignoring what the customer had said. The customer left a one-star review saying the bot clearly was not a real person and clearly was not listening. That review sat on the page for six weeks before anyone noticed it, because nobody was checking. The fix, when it came, was not a better model. It was honest self-identification, a rule that after two failed attempts the bot hands over to a named person with the full transcript, and a weekly fifteen-minute transcript review on Friday afternoons. Within two months, chatbot-related complaints fell from roughly one a week to almost none, and two customers praised the handover in reviews. The full account is in Lilach Bullock's write-up. The lesson is not that weekly reviews are magic. It is that an unchecked assistant's failures are discovered by customers, on their schedule, in public.

The three-layer check, sized for a ten-person business

Production teams check AI systems in three layers. The layers sound technical; in a small business they shrink to three simple habits, and the Friday Check runs all three at once.

The three layers, and what each one looks like at small-business size:

Practitioner guidance puts the sampled slice at 5 to 10 percent of live runs, scored and watched for drift, per Lanexora's production-evals guide.

Two disciplines from Anthropic's evals framework (January 2026, "Demystifying evals for AI agents") keep the check honest, and both translate directly, plus a third stability check from the explainer workflow around the framework:

• Grade with a separate grader, never the model grading its own work. In a small business this means: the person who reads the sample is not the assistant, and if an assistant helps draft the golden set, a human checks every expected answer against the real documents before it counts. One practitioner's audit against the framework found a writing model rating its own citation accuracy at 90 where a separate model scored the same work at 72 — the student does not also grade the final.
• Calibrate any automated grading against human judgement. Anthropic's line is that LLM-as-judge graders "should be closely calibrated with human experts" before they are trusted, with structured rubrics per dimension — one check per question, pass or fail — rather than one fuzzy score, and with an escape hatch: the grader returns "Unknown" when it does not have enough information, instead of guessing. Once the system is robust, Anthropic notes, occasional human review is sufficient — which is exactly what a weekly check is.
• Check the grader itself for stability: in Neuron's explainer workflow on the framework (not in Anthropic's article itself), a judge is run twice on the same output — if the verdict flips between runs, the grader is not stable enough to trust, and no trend built on it means anything.

Anthropic's own cautionary example shows why the measuring stick deserves suspicion too. Opus 4.5 initially scored 42% on a benchmark called CORE-Bench, until researchers found the grading itself was broken — rigid grading that penalised a correct answer in a slightly different format, ambiguous task specs, and tasks that could not be reproduced exactly. After fixing the grader, the same model scored 95%. The model had not changed. The test had. So when your Friday Check finds a failure, ask two questions before blaming the assistant: is the answer wrong, or is the expected answer stale? A golden set that is never updated will eventually accuse a good assistant of failing a test that no longer describes the business. That is the eval-set half-life: the set must grow from real failures, or it rots. The drift literature makes the same point in platform terms — rolling daily samples scored as the fastest leading indicator, output patterns (average answer length, refusal rate, format conformance) shifting by more than two standard deviations as a drift signal, and a shadow comparison on 5 to 10 percent of traffic to catch silent provider updates, per the LLM evaluation and observability guide. At your size, the translation is simpler: a failure found in a real conversation goes into the golden set the same week, so next Friday's check would catch it.

Where the standards are heading

None of this is a compliance demand today. But the direction of travel is worth knowing, because it tells a small business which habits will age well and which will have to be rebuilt later.

In February 2026, NIST's Center for AI Standards and Innovation launched its AI Agent Standards Initiative, covering identity and authorization, security and risk management, and monitoring and logging, with an AI Agent Interoperability Profile planned for the fourth quarter of 2026, per the Cloud Security Alliance's agentic profile. A March 2026 NIST report on AI monitoring makes explicit that monitoring for agentic systems must span functionality, operations, security, compliance, and human factors — well beyond uptime.

As of the initiative's August 2026 update, the outputs so far are inputs: a request for information, a draft concept paper on agent identity and authorization, and sector listening sessions; guidelines follow. So read NIST as direction, not as a finished rulebook — and nothing in this post is a compliance demand.

The identity pillar translates into one habit a small business can adopt today: give the AI worker its own login and its own permissions, never the owner's admin account. The concept paper's framing, covered by Helix Cyber, treats the agent as a first-class identity with its own identifier, credentials, and permissions, bound to the authorizing user — so the log shows the worker did something on the owner's behalf, not that the owner did everything. When the Friday Check asks "did anything happen this week that nobody approved?", an own-login log can answer it. A shared admin login cannot. The practical version of the same idea appears in governance write-ups: an agent with no human owner gets switched off, and anything that spends money, contacts a customer for the first time, or deletes a record waits for a click, per Justin McKelvey's governance framework. That is the whole standards direction in one sentence: know who acted, watch it while it runs, and keep a human on the irreversible parts.

Build your Friday Check sheet

Here is the one artifact of this post: a single sheet that turns "we should check the assistant sometime" into a 30-minute Friday routine. It has four parts. A week with no check is a week the customers did the checking.

Step 1: Open a blank Sheet and copy the template

1. Open a new Google Sheet and name it "Friday Check — [the job the assistant does]". Expected result: a blank Sheet with that name, ready for the template.
2. Copy the template below into it. Part A is the golden set, part B is the week's sample log, part C is the failure-to-test-case rule, part D is the one-line drift note. Expected result: one sheet with four parts, ready to fill, in under five minutes.

The template to copy — paste it as-is, then replace the bracketed text:

PART A — GOLDEN SET (20 questions; re-run every Friday)
No. | Question a customer really asks | Expected answer (from your real documents) | Pass / Fail
1 | [e.g. What is your return window for damaged items?] | [the exact answer from your returns policy] | [ ]
... | ... | ... | [ ]
20 | [ ] | [ ] | [ ]

PART B — THIS WEEK'S SAMPLE (a handful of real conversations)
No. | Date | What the customer asked | What the assistant said | Verdict: correct / partly correct / wrong / handed over
1 | [ ] | [ ] | [ ] | [ ]
... | ... | ... | ... | [ ]

PART C — FAILURES BECOME TEST CASES
No. | Failure found (golden set or sample) | New test case added to Part A | Document or instruction fixed
1 | [ ] | [ ] | [ ]

PART D — DRIFT NOTE (one line, every Friday)
Week of [date]: [one sentence — what changed, what broke, what you fixed]. Next check: [next Friday's date].

Step 2: Draft the golden set with an assistant, then check it by hand

1. Paste the starter prompt below into the AI assistant you already use, fill in the bracketed facts from your own FAQs and past chats, and ask it to draft twenty questions with expected answers. Expected result: a draft list of twenty questions with proposed expected answers, ready for your hand-check.
2. Read every expected answer against your real documents — price list, returns policy, service notes. Correct any answer the assistant invented, any question no customer has ever asked, and any answer that quotes a document you have since changed. Expected result: twenty questions a real customer could really ask, each with an expected answer you have personally verified. The assistant drafts; you decide. Nothing enters the golden set unverified, because an unverified expected answer is a future false alarm — or worse, a future false pass.

The starter prompt — copy it exactly, fill in the brackets, and paste it into your assistant:

I run a small business in Bengaluru. My AI assistant answers routine customer enquiries from my own documents: [list the documents, e.g. price list, returns policy, delivery notes].

Draft 20 golden-set questions for a weekly check. Rules:
- Every question must be one a real customer has asked or could plausibly ask, drawn from these topics: [your top enquiry topics, e.g. delivery times, returns, prices, timings].
- For each question, write the expected answer using ONLY the facts in my documents below. If a fact is not in my documents, mark that question UNKNOWN instead of inventing an answer.
- Include at least 3 questions about the things customers get wrong most often, and at least 2 questions where the correct answer is "I don't know — let me connect you to a person."
- Do not invent prices, dates, or policy details. Mark anything uncertain as UNKNOWN.

My documents (paste the relevant extracts here):
[ paste price list / returns policy / delivery notes extracts ]

Step 3: Run the Friday Check

1. Re-run the golden set: put each of the twenty questions to the assistant exactly as written, and mark each pass or fail against the expected answer. If the assistant's answer differs from the expected answer, first check whether the expected answer is stale — a changed policy makes the test wrong, not the assistant. Fix whichever one is stale, and note it in part D. Expected result: twenty pass/fail marks, with every failure attributed to either a stale test or a real assistant error.
2. Read the week's sample: open a handful of real conversations from the week — the awkward ones first, not the smooth ones — and tag each correct, partly correct, wrong, or handed over. Judge the wrong-answer share more strictly than the resolution share: one confident mistake costs more than ten unanswered questions, per the pilot-review pattern in LinkAgency's chatbot guide. Expected result: a tagged sample log in part B, with the week's wrong answers visible at a glance.
3. Turn every failure into a test case: for each wrong answer, add one question to part A and fix the document or instruction behind it. A failure that is not added to the test set will happen again, and next Friday's check will not catch it — because the check only knows what you taught it. Expected result: part C filled, one row per failure, each with its new test case and its fix.
4. Check the guardrail log: did anything this week spend money, publish something, or message a customer without approval? If the answer is "I can't tell," that is the finding — fix the logging before next Friday. Expected result: a yes-or-no answer for each guardrail, or a logging fix on the list for next week.
5. Write part D in one sentence and date next Friday's check. Expected result: a completed check in about thirty minutes, with a dated next check. If it takes much longer, shrink the sample, not the golden set — the golden set is the spine.

Step 4: Work one illustrative example through the sheet

1. Read the example below once, so the shape of a completed check is concrete. Every number in it is illustrative — invented to show the routine, not a measured result from any real business. Expected result: you recognise what a completed Friday Check looks like, so you can judge your own when it is done.
2. Notice what the example's owner does with the one failure: she adds it to the golden set the same week, instead of fixing the answer and moving on. Expected result: you can picture your own Friday Check, with your own questions, and you know the loop to run on it: fail, add, fix, note, repeat.

Illustrative example only. A fictional Bengaluru boutique runs an enquiry assistant. (Illustrative example only — every detail here is invented to show the routine, and no part of it is a measured result from any real business.) In week one, its golden set has twenty questions and the assistant passes nineteen. The one failure: a customer asked about delivery to a newly added neighbourhood, and the assistant quoted the old delivery note, which did not cover it. The owner checks the expected answer first — it is current — so the failure is real. She adds a second delivery-area question to the golden set, updates the delivery note the assistant reads from, and writes part D in one line: "Week of October 26: delivery-area question failed; delivery note updated; golden set now 21 questions." The sample that week also shows one handover that worked well — a customer asked about a damaged item, the assistant said it did not know the replacement process and connected them to a person, and the customer thanked them. That handover stays in the sample log as evidence the escape hatch works. Total time: under half an hour. The point of the example is not the boutique. It is the loop: fail, add, fix, note, repeat.

Guardrails: the backstop the check verifies

The Friday Check assumes one thing: that the assistant cannot quietly do irreversible things while nobody is watching. That assumption is the guardrail layer, and the check's job is to verify it still holds — not to redesign it.

• Its own identity: the assistant works under its own login with the least access the job needs — never the owner's all-access account — so the week's log can show who did what, per the BOAi guardrail stack (identity, least privilege, input controls, tool controls, approval gates, runtime limits, observability).
• Human approval for what cannot be undone: spending money, publishing, and sending external messages wait for a person, per Rogue Agents' guardrail set. The shortest form of the rule: the assistant can prepare almost anything; a human approves anything that cannot easily be undone.
• A real stop: caps on what a run can do, and a way to switch the assistant off in one step. If you cannot say how you would stop it, you do not have a guardrail — you have a hope.

This section is deliberately short. The full approval treatment already exists on this site — the approval inbox post covers the mechanism in depth — and this post does not re-argue it. The Friday Check only asks, once a week, whether the backstop held: nothing spent, published, or messaged without approval, and every exception logged. A guardrail nobody verifies is a decoration.

The rule: a failure that is not a test case will happen again

The rule is short enough to pin above a desk: every failure becomes a test case, or it will recur. The golden set is not a trophy from launch day. It is a living list, and its growth is the evidence the business is learning.

• A golden set that never grows means either the assistant is perfect — it is not — or nobody is looking at real conversations.
• A sample nobody reads is a log, not a check. Logs comfort; checks correct.
• A drift note nobody writes is a week nobody remembers. The one-line note is what turns thirty minutes into institutional memory: six months of one-liners is the history of your assistant, written by the person who owns it.

That is the work this site's MLOps, Evals & Production Hardening does at full size: keeping AI systems reliable, measured, and safe in production — the same discipline, with the same loop, run by people who do it every day. But the Friday Check is the version a ten-person business can run itself, starting this Friday, with one Sheet and thirty minutes. Open the Sheet, draft the twenty questions, run the first check, and date the second one before you close the laptop. Launch day proved the assistant can do the job once. Friday proves it still can.