Why Internal Controls Prepared Us for AI Harness Design
Accounting is vibing — now it's time to design the harness. What the Big 4 are actually telling clients about AI internal controls, and why the vocabulary explaining it all is only five months old
Hey there 👋,
It’s been a minute since the last issue - and somehow it’s now July. Is anyone else feeling AI whiplash?
We opened June’s AI Shareforum — 150 practitioners, 85% Big 4 audited — the way I always do. With a practice poll:
Vibe check: Where are you on the AI journey?
💬 Still living in chat for a lot of it — 59% 📊 Excel & PowerPoint sidekick — 47% 📈 Vibing dashboards — 17% 😵💫 …okay, I’ve now made too many dashboards — 6% 🛠️ Built apps for real workflow use cases — 20% 🚀 Solutioned whole workflows end to end — 6% 🧹 I’ve overvibed — send help, I need to consolidate & govern — 2% 🤹 Honestly? A little bit of all of the above — 11%
Read as a sentence, one in five of us has built a real application. That isn't experimentation anymore — that is where internal controls kick in.
For a solid 28-minute stretch of our June AI Shareforum, members compared notes on what the Big 4 are actually telling clients about AI in controlled processes. All four firms came up. All four answers were materially different.
At first, it sounded like disagreement. The more I sat with it, the more I realized something else was happening.
The technology is moving faster than the shared language we need to govern it. Engineers, auditors, and controllers are often describing the same underlying ideas with completely different words.
I’ve become convinced that one of those new important words for us is harness design.
Let me show you what I mean.
This newsletter is brought to you for free by Right Rev:
Every Case Accounted For. AI-Powered Revenue Recognition. Simplify and automate complex revenue recognition, gain real-time insights, and ensure ASC 606 / IFRS 15 compliance – now with the Revi suite of AI tools. Request a demo.
What the four firms are saying
A quick caveat on how Gaapsavvy works: Shareforums start with one member's crowdsourced question — on the premise that one member's conversation stands in for hundreds of identical 1:1s happening across the industry between individuals at companies and firms. Members compare notes, reconcile differences, and bring a more informed perspective back to their auditor. No one can stay on top of all of this alone, we can be each other's eyes and ears. Here's what we heard:
PwC is the most aggressive. Members attending PwC’s AI conferences in SF and San Jose watched the firm present its proprietary platform, PwC One — a full platform posture where every agent is documented from day one: the testing sample, a lifetime accuracy threshold it must maintain, a review cadence for the life of the deployment, and a captured log of every step of every run. The pitch: the human stops re-performing the output and instead reviews the agent’s steps, leaning on the tested deployment. Partners are calling it deterministic AI agent deployment, and report that auditors of PwC’s consulting clients are satisfied with the level of documentation. (Said with affection: putting a language model through prescriptive steps makes it better behaved, not deterministic — the same way a strong close checklist never made your staff deterministic either. The honest claim is "we shrank the judgment zone and controlled it" — and that claim is both auditable and directionally right.)
Deloitte told one member — in a call the day before our session — that human-in-the-loop alone won’t be enough: expect continuous monitoring controls, operating outside the execution moment. First time she’d heard it. I suspect the first of many as teams really start to build.
EY pushed back on one public company’s use case — using AI to extract information from contracts and pre-fill a rev rec checklist. Their question: “How do you evidence that every contract term has been properly extracted, without 100% manual human re-performance?” Meanwhile, EY is telling clients it plans to deploy AI agents in its own audits next year. The chat wrote its own punchline: “yet the audit fees are not being decreased 🤷🏻.” Within sixty seconds, other EY clients in the room were comparing notes — and I offered that this might be exactly the place the community pushes together.
KPMG told a December financial reporting conference that it sees AI agents auditing clients in the future — “definitely more questions than answers.”
And above all four: the PCAOB has published observations, not standards. Staff spotlights and outreach summaries exist; the thing a national office can actually lean on does not. Which is why, per one member’s outreach, one of the largest companies in the world has sorted every AI use into assist, augment, automate — and banned the automate bucket outright for two years while it waits for the regulator to speak.
Here's the part that matters: the firms aren't contradicting each other.
Put the four positions side by side and they’re recognizably branches of one decision: how much reliance on the AI, proven how. Full human review with no reliance? That’s a management review control everyone already knows how to test. Reduced review? Then reliance with conditions — tested at deployment, proven accuracy, sustained validation.
Four institutions, translating the same underlying logic into four ad-hoc dialects, client by client, partner by partner. Why dialects instead of one language? Because the connective vocabulary for this entire space is younger than a busy season.
A Word that is Five Months Old
Earlier this year I kept hearing the word “harness engineering” and didn’t know what it was. It turns out the phrase was coined in February 2026 — five months ago — by Mitchell Hashimoto, co-founder of HashiCorp. Frontier labs like Anthropic and OpenAI have since published reference architectures around it. An entire emerging discipline, named five months ago.
So what is a harness?
Let’s start with the premise: a model, as a worker, is powerful but stateless and fallible. Every session starts with no memory, holds finite context, and drifts on long tasks. Most dangerously, it fails plausibly — when it’s wrong, it’s confidently, articulately wrong. None of this can be fixed by prompting harder. These are properties of the model as a worker, not the instructions.
A harness is everything you build around that worker so its work can be trusted anyway. Every piece of the harness is engineered because of one specific failure mode:
Because sessions forget, the state lives in files, never in chat — a handoff document the next session reads first. The project files remember even though the worker doesn’t.
Because instructions given in conversation decay, the rules are standing orders loaded at the start of every session, not things you said once and hope stuck.
Because the model improvises under ambiguity, the gates fail closed — an unknown account, an entry that doesn’t balance, and the line stops loudly, instead of a plausible guess sailing through.
Because no author can audit their own work — the whole reason preparer and reviewer were ever separated — review is done by fresh eyes that didn’t make the change, prompted to attack it, not confirm it.
And because every caught failure is information, the harness ratchets: each incident becomes a new permanent check, tested to prove it can actually fire.
Now read that list again. Those engineering - defined failure modes look a lot like our “What Could Go Wrongs”.
Harness design is the discipline of making the system more reliable than the model inside it. It determines how much uncertainty a workflow can safely tolerate before a human must intervene. Prompt engineering tries to make one session behave well; harness design assumes any single session might behave badly — and makes that survivable by designing the environment around it.
It’s the difference between hiring carefully and having internal controls. We don’t build accounting around the assumption that people never make mistakes. Perhaps the interesting question is not whether a model hallucinates, it’s whether the harness designed around that model is strong enough to prevent, detect, and correct those mistakes before they become financial reporting issues.
That’s the harness. And that's why everyone giving governance guidance right now sounds like they're improvising: they are. The connective language of a new discipline is only five months old.
I watched it happen on my own screen
Over the July 4th weekend I forced myself to learn how to use Claude Code in the terminal - and used Anthropic’s newest model Fable to build a data pipeline for this community. I stated my goals, Fable interviewed me and produced a roadmap - the pattern assembled itself out of necessity:
Fable (the brain & mission control): the expensive judgment model planning the work, writing specs and performing adversarial reviews
Sonnet (the builder): the cheaper execution model building from Fable’s specs
Me (the human) - the only seat that never delegates — ruling on anything irreversible.
Sessions ended; the HANDOFF.md file carried the state. A verification battery ran after every change, and when it went red, the work stopped and waited for me. And when the builder’s own checks said clean on something sensitive, a fresh-eyed reviewer agent that hadn’t written the code found dozens of problems the author’s checks had missed. Three review rounds before one came back empty. That rule is permanent now. That’s the ratchet.
Fail-closed gate - (engineering: verification harness; audit: preventive control). Nothing merges until it's green — and green requires my ruling, not the model's guess. ( Sonnet in Claude Code)
Independent review - (engineering: adversarial evaluation; audit: preparer/reviewer separation). The math checks passed. The author’s checks said clean. Fresh eyes found it anyway. (Fable in Claude Cowork)
Persistent state (engineering: context handoff artifact; audit: the workpaper file). The session died. The system remembered in a new context window. An audit trail writes itself. (Sonnet in Claude Code - new context window)
Only afterward did I re-read Anthropic’s engineering post on harness design for long-running work and realized Claude Code is itself a harness. Their team, inspired by Generative Adversarial Networks, split the work between a generator and an evaluator, with concrete criteria for what 'good' looks like — the unlock for rich full-stack applications built over multi-hour autonomous sessions.
Our accounting instincts designed the same architecture for human workers decades before engineering had words for it: separate the doer from the checker, write it down, stop when it doesn't tie."
“Isn’t this just… what we already do?”
Every training, someone asks the honest question: aren’t controls over AI the same as controls over any manual process? A human staff accountant isn’t deterministic either — as one member put it in June, depending on the mood and the weather that day — we were never able to audit the reasoning in their brain - internal controls were how we made people-processes reliable. Preparer and reviewer. Sampling. Management review. The management review control was never a technology; it was a harness for people.
So: Yes. Same architecture. You’ve spent your career doing harness design, which is why this will come faster to you than to almost anyone.
But there are also some very real, very new risks (i.e WCGWs) that we are just starting to feel — and they deserve an honest answer, not just the comforting one.
The architecture transfers. The risk math doesn’t.
Your staff don’t produce confidently wrong answers a thousand times an hour; an agent can. Your staff don’t get their brains silently swapped by a vendor overnight; a model version can. And your staff have never handed you a beautifully written rationale that isn’t actually how they reached the answer — which AI models demonstrably can, and which is why a harness logs actions as evidence, never the model’s narration. Speed, scale, and a new kind of failure — that's what's actually new. Smaller than the panic, bigger than nothing.
The unit of measure that was always ours
The new word is also the fourth rung of a ladder we’ve been climbing in public:
From our context engineering conversation in January, to harness design of the whole environment the AI runs in, the unit we control keeps grows from a use-case to a whole system. Translate “whole system” into the scope of responsibility of the accountant - it’s the end-to-end process.
Quote to cash. Record to report. Procure to pay. Engineers rarely got to think at that altitude — they were scoped to an application or a feature, and accountants were the ones made to assess all the little pieces in between, stitched into one end-to-end flow. The shift doesn’t climb to somewhere new. It climbs to the unit of ownership accountants have been responsible for all along.
And per June’s capabilities poll: 61% of this community has already used Claude Code or Cowork. That means we’re in the fourth column— and mostly without the vocabulary. That’s exactly the gap.
The vocabulary is arriving
In June 2026, FEI’s Committee on Corporate Reporting put a first formal vocabulary in writing — the AI Framework: Internal Control Over Financial Reporting. It keeps your existing SOX program as the foundation, routes deterministic builds back to normal ITGCs, and names four control approaches for the probabilistic branch: human review designed by nature, timing, and extent; testing against known-input/known-output sets; a second independent model validating the first; and population-level analytics watching for drift. It is a starting point in a field moving faster than any framework can publish.
Read those four approaches as a builder and you'll recognize them instantly — engineers call them evals, golden sets, LLM-as-judge, observability. The accounting authors described the harness playbook, just using a different dialect:
One more term that’s worth mentioning from the FEI framework that I suspect we’ll hear a lot more about: Shadow Reliance.
It’s the human in the loop who still signs off but has stopped truly reviewing, because the output kept looking right. A review control on paper; unconditioned reliance in substance.
I can honestly say I didn't really understand this risk until I caught myself shadow-reviewing within one weekend of agent approvals: "Yes — allow bash." "Yes — allow edits every time." "Yes — don't ask again." …and finally:
By Sunday, decision fatigue had quietly retired my review to shadow reliance. It isn’t a character flaw — it’s what happens to any competent reviewer at machine speed.
Before your next auditor conversation
Five things, in order:
Run the routing question: deterministic or probabilistic? If AI built it and fixed code runs it — take the exit ramp. Normal ITGCs. Go run, be glad.
If probabilistic: is the AI part of the process, or is it the control? And what’s the risk if it’s wrong? These two questions place you on the map.
Decide the reliance question explicitly instead of drifting into it. “We rely / we don’t rely, and here’s the condition set” is a sentence your auditor can work with.
Audit yourself for shadow reliance before anyone else does. When did your review last actually catch something?
Walk in carrying the shared words — reliance, performance testing, sustained validation: forward this issue to your engagement team along with the FEI framework (totally worth the price) . The members who arrived with vocabulary report better conversations than the members who waited for their firm to improvise one.
If you’re in the 59% still living in chat: you’re not behind. You’re early — and this time the vocabulary is arriving before your build instead of after.
The frameworks are the profession’s law: necessary, authoritative, and by design, slow. The builders are moving weekly. What’s been missing is the layer in between — where one member’s auditor conversation becomes another member’s opening position, faster than any single firm can publish. That layer is what this community has been building all along. This issue is one piece of it; what you send back is the next.
July 24 — I'm sitting down with Jason Pikoos, one of the authors behind the FEI framework, to go deeper on exactly these questions: reliance vs. non-reliance, shadow reliance, and what human-in-the-loop actually means — anchored on real member cases. Join us here.
And hit reply. If you’ve had the auditor conversation — the one that went well or the one that went sideways — send the exact words that were used.
That’s how the next layer gets built.
And we get to build it together.
-Angela
What’s coming up:
Friday, Jul 24, 10am PT — AI Governance & Internal Controls, with Jason Pikoos (Modern Finance @ Meta · COSO board · FEI framework co-author). Register HERE. Know an advisor or auditor wrestling with this? Forward this along.
Aug 12 — AI in Finance Lab (Gaapsavvy × Coterie CFO, at Deloitte SF) — half-day hands-on workshop; laptop required, in-house practitioners only, in person capped at 60. Register/Apply HERE
From real practitioners, for learning purposes only. Polling data shows industry leans, not final positions — every company’s facts are different. Always work with your auditors and internal controls team before implementing anything new.
Great article!