Your Examples Might Be Causing Your AI Agent to Fabricate.
Examples can show Claude which call to make at the boundary. They can’t tell it where the boundary is. That part is still yours to write.
👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.
The goal is to keep you steering the tools, not the other way around, by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.
I build my own AI agents in the open, and advise a few companies a year on where AI belongs in their work, at dewilliams.co. This newsletter is where I document the patterns, commands, and habits that help you grow from babysitting prompts to building reliable systems.
Join 34,000+ senior technical professionals learning the discipline that keeps your judgment valuable.
Domain 4 · Lesson 4.2 · Structured Output and Grounded Verification
tl;dr When your extraction agent is inconsistent, examples beat more instructions, but only if each example carries the inference rather than repeating the input. And there is a class of cases “no example” can resolve, where forcing the model to pick is the actual bug.
Last week I argued that most of what gets called hallucination is a schema-design failure, since a required field with no legal way to say “absent” is an instruction to invent. I’ll keep calling it fabrication from here, because “hallucination” is the “be careful” of AI vocabulary: it sounds like a diagnosis and contains no mechanism. This week’s failure is different, and this time the fix really is examples.
Your agent reads a contract and returns null for the governing law, even though the clause is sitting in the third paragraph, phrased as “operating under the statutes of the Commonwealth of Massachusetts.” No instruction repairs this. “Read carefully” does not, “always extract the governing law” does not, and a colleague will propose “read carefully, always extract, pick the primary one,” where every clause fails for its own separate reason. The model is not being sloppy. It does not recognize that phrasing as a governing-law clause in the first place, and prose cannot fix recognition: you can describe a shape all day, and an example shows it. So you reach for examples, and you are right to do so. The reach order when behavior is inconsistent goes explicit criteria, then examples, and only after both a bigger model or some other knob. Most people never get past the first step.
The defect that is probably already in your example set
I want to slow down here, because I got this wrong myself while working through this lesson. You write an example: input, then output, then a middle line you label “reasoning,” because you have read that examples should show reasoning. And what goes on that line is a restatement of the input. Mine said, in effect, that the contract states it operates under the statutes of the Commonwealth of Massachusetts; therefore, the governing law is Massachusetts.
Read that back. It contains no reasoning at all; it is the input with the answer stapled to it. An example built that way teaches Claude to match a surface pattern, so it handles contracts phrased almost exactly like yours and falls over on the next variation. And the defect is invisible while you are making it. Nothing in the output flags it, and your set looks complete because it has inputs, outputs, and a line called reasoning.
The problem examples cannot touch
Then there is the second failure, which produces no error and no flag at all. A contract names Delaware as the governing law at the document level and specifies New York for one section on dispute resolution. Your agent picks one; it is not obvious which, and it is not stable across runs. You can add examples that demonstrate a precedence rule, but an example can only ever show a rule being applied; it cannot be the rule. Meanwhile, your schema has one string field called governing_law, so whatever the model decides, the conflict itself is destroyed on the way out. The output is a single confident jurisdiction, and nothing downstream will ever know there was a second one.
In L4.1, a required field forced a value where none existed. Here, a single-value field forces a choice where two exist, and the effect is the same: the structure demanded one answer, so one answer is what you got. Green light, no flag, nothing in the pipeline aware that a decision was made at random. Most extraction pipelines I have looked at carry both defects at once, with reasoning lines that are restatements and schemas that leave no room for ambiguity. The common cases pass, the accuracy numbers improve, and the genuinely hard documents quietly pick a jurisdiction by coin flip. Consistent and unverified, which is the failure this whole domain is about.
The rest of this piece is the repair: how to write a reasoning line that carries an inference, how to choose which examples to spend, what to do about the conflict case examples cannot solve, and a prompt you paste into Claude Code that takes your own failing extraction case and builds the example set for it. Your documents, your failures, your set, on your machine.
