Use the Model to Write the Parser, Not to Be the Parser

Here is the single most valuable design move in agent systems, and it fits on one line: use the model to write the parser, not to be the parser. Get this right and the economics work; get it wrong and you’ve built something that demos beautifully and loses money on every unit of volume. It’s the direct consequence of the governing principle — the model belongs where being wrong is cheap, which means it belongs at design time, not in the hot path of every transaction.

The naive design that quietly kills you

The obvious way to handle messy inbound data — files, forms, documents that never quite match — is to run a language model over every row of every file and let it interpret each one. It works. It demos wonderfully. And it’s fatal for three reasons at once: cost scales linearly with volume (every row is a model call, forever), outputs aren’t reproducible (the same row can parse two ways on two days), and you can’t answer the audit question — when someone asks “why did this row become that number,” the honest answer is “the model felt like it,” which is not an answer.

You’ve turned a data-processing problem, which software solves at near-zero marginal cost, into a per-item inference bill with no reproducibility. That’s not automation. That’s a very expensive intern who gives slightly different answers each time and can’t show their work.

The inversion: once per class, not once per instance

The right design uses the model once per class of problem, not once per instance of it. A new source of data arrives in an unfamiliar shape. The model looks at a sample and proposes a mapping — which column is which, how this format relates to your schema. A human confirms that mapping once. From that moment on, the mapping is a deterministic parser: every subsequent file of that shape is parsed by code, costs effectively nothing, and produces byte-identical results every time.

The model did the hard, genuinely-AI part — making sense of an unfamiliar structure — exactly once. Everything after is software doing what software is good at. Generalise the rule: the model’s job is to produce artifacts that code then executes. Mappings. Proposed rules. Classification schemes. Extraction templates. Not decisions, and never the per-instance reinterpretation of something it has already interpreted before.

Why the fingerprint stage matters more than it looks

This is why a cheap-looking piece of plumbing — fingerprinting incoming data and routing exact matches straight to a known deterministic parser — is not a minor optimisation. When a large majority of your volume is being handled by exact-match parsers a few months in, with no model call at all, that isn’t a tuning win. It’s the difference between a software gross margin and a services one.

A system where every unit of volume pays an inference toll has the cost structure of a consultancy dressed up as a product. A system where volume compounds into a growing library of confirmed, deterministic parsers — where marginal cost falls as you scale — has the cost structure of software. Same feature set, same demo. Completely different business. And the fork between them is entirely a matter of whether you let the model be the parser or made it write the parser.

It’s worth being honest about the one part of this that’s moving. As inference gets cheaper and faster every year, the raw cost argument softens — running a model over every row stings a little less each time. But cost was never the whole case, and the rest of it is model-proof. A deterministic parser is reproducible and auditable no matter how cheap or clever the model becomes, and a library of confirmed parsers is a compounding asset the model can’t hand your competitor. Faster, better models make the wrong design less painful; they don’t make it the right one. (More on what model progress does and doesn’t change in the companion post.)

The test to apply everywhere

Whenever you’re about to put a model call in a path that runs per-item, stop and ask: is this genuinely a new problem each time, or the same problem I’ve already solved, re-solved from scratch? If it’s the same shape recurring, the model should have produced a reusable artifact the first time, and code should be handling every instance since. Reserve live inference for the genuinely novel — the file you’ve never seen, the reply that doesn’t fit — and let everything you’ve seen before run as deterministic, reproducible, near-free code.

Cheap to Be Wrong — a six-part series on agent architecture

1. Put the Model Where Being Wrong Is Cheap
2. Use the Model to Write the Parser, Not to Be the Parser — you are here
3. Where the Model Is Genuinely Load-Bearing
4. An Agent Is a State Machine, Not a Loop
5. The Model Upgrade That Quietly Breaks You
6. The Model Is the Least Defensible Part of Your Agent