We recently helped a tax accountant in India get an AI agent working inside their return-filing workflow: reading government tax statements, reconciling tax-deducted-at-source credits, building the computation sheets that back a filing. Two machines run Claude Code. Ours runs a frontier model and does the building. The accountant's runs a small model billed per token and does the day-to-day filing, and the accountant is not an engineer.
The agent worked on the first day. That same first day, it was on a cost trajectory that would not survive a filing season. The same work is now on track to cost about a dollar per client on that same small model. We did not find a better prompt. We changed who does the thinking, and when. I have taken to calling the pattern Papa Claude and Baby Claude.
Correct first, then cheap
Like any process, you get it right before you make it fast. The first phase costs money on purpose. A frontier model read the actual tax code, the schema the government publishes for electronic returns, and last year's already-accepted return, and wrote logic that verifies against all three. Getting a real return to come out correct, once, end to end, is worth spending tokens on: measured after the fact, the build ran to roughly $400 at API prices, a number a flat-rate subscription conveniently flattened.
The bill that actually arrived was the runtime's: nearly $50 of per-token operator sessions for the first two returns. We had a correct system and had not made it economical. So we did the ordinary engineering thing and optimized what we had already got right.
Where the money went
When the bill spiked, I pulled the transcripts, deduplicated them, and added up the damage. The first few days had run to nearly $50, and four long sessions caused about 95 percent of it. Each had accumulated 110,000 to 145,000 tokens of context, and every one of its requests, and the sessions ran from 150 to 750 requests each, re-read that context from the top. The worst single session ran well over ten dollars, almost all of it re-reading history it had already paid for.
What was the model doing with those turns? Reading 30-page government PDFs straight into its context. Hand-patching a document parser, three separate times. And once, retry-looping on an unexpected capital-gains case, paying the full context toll on every lap. In other words: thinking. Thinking is the one thing a small operator model is worst at, and the failure mode is expensive precisely because the model does not know it is failing.
None of this was the model being bad at tax. It was the deployment being bad at economics.
The split
The fix is an architecture, not a prompt.
Papa Claude is maintainer mode: the big model, on our machine, with an engineer watching. It writes deterministic, self-verifying tooling, with tests. Parsers for every document the government can produce. An extraction pipeline that turns a folder of portal downloads into a draft data file plus a short gap digest listing only the judgment calls a human actually needs to make. A one-command verification chain that checks a generated return several independent ways. You want your most expensive model building the machine, not standing at the counter.
Baby Claude is operator mode: the small model, on the accountant's machine. It never opens a document. It reads digests, resolves the listed gaps, and runs commands. The design principle, written into the repo's handbook: logic lives in scripts, not in-session reasoning. If the operator model is reading a document, that is a tooling failure, not an AI win.
Why tax is a good place to start
This pattern does not suit every process. Tax has two properties that make it close to ideal, and both are about verification rather than trust.
First, the rulebook is public and precise. The tax code, the schema for electronic returns, the validation rules the processing center applies: all documented, all authoritative. A capable model is genuinely excellent at reading those and encoding them, then checking its own code and output against them. It is not being trusted to know tax. It is verifying against documents that are themselves the source of truth.
Second, there is a ground truth to test against: last year's return, which the tax authority already accepted. The maintainer treats the prior filing as a template and the published rules as an oracle, and refuses to emit anything that fails either. A well-documented domain with a checkable history is where this style of AI earns its keep, because the model's confidence is never the thing you are relying on.
Seven mechanisms that make the split hold
Git is the message bus
When the operator hits something the toolkit cannot do, it does not improvise tax law. It writes an OPEN entry to a markdown gap ledger, commits, pushes, and parks that filing. On our machine the maintainer pulls, implements the capability with tests, and marks the entry done. Escalate, do not extend. No queue service, no orchestration framework: a text file in git.
Park, do not retry
Every failure message ends with exactly one next action, and a two-strikes-then-park rule stops retry loops cold. When a guard fires it says, verbatim, do not retry or work around this. Small models follow explicit failure instructions remarkably well. What they do with a vague error is retry-loop, and every retry re-reads the entire context. A vague error message is a cost center.
Interlocks, not trust
The extraction step writes its open questions directly into the data file it produces, and every downstream step refuses to run while any remain. You cannot file a return over a placeholder. Not because the model is careful, but because the tooling makes the careless path unrepresentable.
The system remembers so the model does not
Every verified build writes a small carry-forward file: computed totals, loss roll-forwards, the handful of numbers next year's return needs from this year's. Institutional memory as a few hundred bytes of JSON, not as 100,000 tokens of re-read context.
Ask for machine formats
We spent three rounds patching a PDF-layout parser before anyone thought to ask whether the government portal offered the same data as JSON. It did. Same download dialog, one extra click. The best token optimization is often upstream of the model entirely.
False alarms are expensive
The return generator used to print 74 boilerplate warnings on every run. Collapsing them into one summary line surfaced the 5 real warnings that had been invisible in the noise, and stopped the operator model spending tokens chasing ghosts.
Measure before you optimize
One obvious-looking cost fix, pinning a cheaper model in the environment config, silently broke prompt caching. The identical request then cost 14 times more: about 25 cents versus under 2 cents. We caught it only because we ran both configurations live before rolling the change out.
This is not about taxes
The maintainer and operator split generalises to any team putting agents in front of non-engineers: operations, finance, support, compliance. One expensive thinking loop, supervised, that writes deterministic self-verifying capability. Many cheap doing loops that consume digests and run commands. A ledger between them, so escalation is a written artefact instead of a judgment call the small model has to make mid-task.
The intelligence belongs at design time. Runtime should be boring.
Everything described here is public: the parsers, the verification chain, the gap ledger, and the operator handbook the small model runs from, at github.com/kznconsulting/india-itr-toolkit. The client folders never touch git, so what you see is the machine, not anyone's tax data. The design-time spend is in there too: clone it and you start at the cheap phase.
If your team is putting agents in front of non-engineers and the token bill looks like ours did, happy to compare notes.
A note on the numbers
The build and operating figures above are measured from session transcripts, priced at API rates. The one-dollar-per-client figure is a design-basis projection rather than a measurement, and it stays labeled that way until a full client has run through the pipeline. We will write the follow-up either way.