Hallucination & Verification

To verify well you have to understand what you are verifying against, and the honest answer is unsettling: an agent's fluency tells you nothing about its accuracy. A large language model, the engine inside most agents, is trained to predict plausible continuations of text. Given a question, it produces the words that most convincingly fit - drawing on patterns in its training data, the tools it can call, and the context you gave it. When the true answer is well represented and the agent can look it up, the plausible continuation and the correct one usually coincide, and you get a right answer. But when the true answer is obscure, absent, or contradicted by the pattern, the model still produces a plausible continuation - and now the plausible answer and the correct one part company. The model does not know it has crossed that line. It has no separate faculty that says "here I am guessing." It produces the confabulation in exactly the same confident register as a fact.

This is why the failure mode is so treacherous for professionals. A hallucination is not garbled or hedged; it is clean, specific and authoritative. An agent will invent a clause number for a code that has none, quote a standard that does not say what it claims, produce a dimension that is internally consistent but wrong, or cite a reference that does not exist - all in the measured voice of an expert. The tone carries no signal. You cannot separate truth from confabulation by how sure the answer sounds, because the answer always sounds sure. Worse, agentic systems compound the risk: an agent that has hallucinated a fact early in a multi-step task will treat it as established and build on it, so a small early fabrication can propagate silently through research, calculations and documents.

None of this makes agents useless - it makes them powerful instruments that require an external check. The mistake is to treat a fluent answer as a verified one. The discipline is to treat every agent output as a draft claim whose truth is still open until you have confirmed it against something outside the agent - the actual code text, the real drawing, the manufacturer's datasheet, a second independent method, or your own trained judgement. That external check is the only thing that reliably separates a correct answer from a confident wrong one, and building the habit of applying it is the whole of this lesson.

Verifying everything to the same depth is impossible and unnecessary; the practical discipline is to verify in proportion to what a mistake would cost. Before you rely on any agent output, ask one triage question: if this were wrong and I acted on it, what happens? The answer sorts the work into tiers, and each tier gets a matching level of check.

At the top are the must-verify outputs - anything touching life safety, structural adequacy, code and regulatory compliance, cost commitments, contractual claims, or a statement made to a client or authority as fact. These are verified against an authoritative source every time, without exception, before they leave your hands. A quoted code clause is checked against the actual code text, not another agent. A structural or egress number is re-derived or confirmed by a qualified professional. A specified product's performance is confirmed against the manufacturer's current datasheet. A cost is checked against real rates. Here the standard is not "it looks right" but "I have confirmed it right," because the consequence of a confident error is a dangerous building, a legal exposure, or a broken promise - with your name on it.

In the middle are outputs where an error is costly but recoverable - a research summary that will shape a decision, a draft schedule, a first-pass analysis. These deserve a real check: verify the load-bearing claims and any specific figures, sample the rest, and treat the whole as a draft to critique rather than an answer to accept. At the bottom are low-stakes outputs - internal notes, brainstorms, first-draft prose you will rewrite - where a glance suffices and heavy verification would be waste. The skill is calibrating the tier correctly, and erring upward when unsure. Two habits make this reliable: ask for sources and check them (an agent's citation is itself a claim to verify, not proof), and verify against something outside the agent - never ask the same or another agent to confirm the first, because a second fluent voice agreeing is not evidence, only correlated confidence. Build the triage question into your workflow and it becomes automatic: goal in, work out, check sized to the stakes, then rely.

Beyond triage, verification has a practical anatomy - specific things that go wrong in agent output and specific ways to catch them. Learn the failure modes and the checks become fast.

Fabricated specifics. Agents invent citations, clause numbers, standards, product codes, statistics and precedents that sound exact because they are exact-looking - a plausible IS number, a real-sounding case study, a precise figure. Check: never accept a specific reference on the agent's word. Open the actual source. If a clause is cited, read the clause. If a study is quoted, find the study. A citation that cannot be located almost certainly does not exist. Numerical and unit errors. Agents make arithmetic slips, drop or confuse units (mm versus m, kN versus kg), and produce internally consistent but wrong calculations. Check: re-derive critical numbers by an independent method or tool, sanity-check magnitudes against known benchmarks, and confirm units explicitly. Stale or wrong-jurisdiction facts. An agent may confidently give a superseded code edition, an old rate, or a rule from the wrong country or state - a live risk in India, where the model may default to foreign norms. Check: confirm the edition, date and jurisdiction against the current governing document.

Misread inputs. When an agent works over your drawings, schedules or documents, it can misread a dimension, transpose a value, or miss a note. Check: spot-check its outputs against the source document, especially where it summarises or extracts. Silent scope drift. Over a long task an agent may quietly answer a slightly different question than you asked, or carry an early assumption into every later step. Check: read the output against your original goal and watch for propagated assumptions. The unifying method is simple and it is the one non-negotiable: check against an authoritative source outside the agent. The code text, the real drawing, the manufacturer's data, a second tool, a qualified colleague, your own trained knowledge - these are what confirm truth. An agent confirming its own or another agent's claim is not verification; it is two confident voices, which is exactly the trap. Make "where did this come from and can I confirm it independently?" the reflex you apply to anything that matters, and the discipline holds.

A verification discipline that lives only in good intentions fails under deadline pressure - the moment you are busy is exactly when the unverified output slips through. So the goal is to make verification structural: built into your process, your prompts and your studio's habits, so that relying on unchecked output feels wrong rather than convenient.

Start with how you direct the agent. Ask for its sources and its reasoning, not just its answer - an output you can trace is one you can check, and an agent that must show where a claim came from is easier to catch when the source is invented. Ask it to flag its own uncertainty and to distinguish what it looked up from what it inferred; it will not be perfectly honest, but it surfaces some risk. Constrain it to grounded sources where you can - an agent working from a document you supplied, or retrieving from a trusted corpus, hallucinates less than one answering from memory (Module 2.3). None of this replaces your check; it makes your check faster and better targeted.

Then build the check into the workflow. Define, for each recurring task, what tier it sits in and what the verification step is - so "draft the specification" always carries "confirm each product against its current datasheet," and "check the layout against the code" always ends with "read the actual clauses." Keep the human verification step as a named, non-skippable stage, not an optional afterthought - this is human-in-the-loop by design (Module 6.3). In a studio, agree the tiers as a team so verification is a shared standard, not one person's caution, and make clear that the person who relies on an output owns having verified it. Finally, cultivate the mindset that makes all of it work: treat every agent output as a capable draft from a fast, fluent, unreliable assistant - genuinely useful, never authoritative. You are not being paranoid; you are being professional. The designer who verifies as a reflex captures the full productivity of agents while carrying none of the hidden liability, because nothing confident and wrong ever leaves their hands unchecked. That reflex is the foundation the rest of this module - responsibility, data, ethics - is built on.