By Sean Hsieh, Founder & CEO, Runline
Every credit union is already running a loop. Deposit comes in, a decision gets made, the institution moves to the next case, the loop runs again. It has been running since the day the charter was granted. The only question is where the verification step sits inside it, and for most institutions, the honest answer is: once every eight to eighteen months. Worse CAMELS ratings and bigger balance sheets get checked more often, not less. You call it an exam.
An NCUA examiner does not primarily test whether your BSA policy is well written. Policies are easy to write well. What the examiner tests is whether your institution’s story holds together across a year of loop iterations: whether the exception logged in March matches the board minutes from April, whether the SAR your BSA analyst filed lines up with what a loan officer told the same member six weeks earlier, whether the reason you gave for clearing an alert last year is the reason you would give today. That is not really a compliance question. It is a verification question, asked by someone with subpoena power, about a loop that has been running unverified for eighteen months.
Conor Brennan-Burke, founder of the YC-backed startup Hyperspell, posted a piece on X this month that names a version of this problem, outside financial services entirely. His argument: intelligence is getting cheap, but coordination is not, and coordination is the real ceiling on how fast any company can grow. One person carries the whole company in their head for free. At ten people, information starts to fragment. At a hundred, nobody knows everything the company knows. What he calls the coordination tax is every meeting, every status update, every “let me check and get back to you” that exists to reconstruct a shared picture of reality that used to be free. His sharpest line: “Bureaucracy is what an organization builds when it has no brain.”
That is a good description of a real problem. It is also, I would argue, the same problem I just wrote about, wearing a different costume.
What engineers mean when they say “loop”
It is worth being precise about this before going further, because the word is suddenly everywhere and rarely explained.
An AI agent loop has five parts, and none of them are exotic. A trigger: what starts it. A scope: what it is allowed to touch. An action: what it actually does, write code, pull a report, draft a response. A budget: how many turns or how much time it gets before it has to stop and ask a human. And a stop condition: the thing that has to be true before the loop is allowed to finish. Claude Code’s /goal command, which shipped in May, is the clearest current example. You type something like /goal all tests in test/auth pass and the lint step is clean, and after each turn a second, smaller model reads the whole session and answers one question: has the condition been met, yes or no. If no, it loops again. If yes, it stops.
That second model, the one asking yes or no, is the verifier. It is not the part of the architecture most people talking about this right now find interesting. It is the only part that matters if you are betting a real outcome on the loop running unattended, because the verifier is the only thing standing between “the agent did the task” and “the agent thinks it did the task.”
This is why loop engineering is dominating the conversation in AI right now. A post on X this summer describing the pattern picked up 8.7 million impressions. Jensen Huang quoted it on stage. Boris Cherny, who built Claude Code, has described running thousands of these loops overnight while he sleeps. The Loop Isn’t the Hard Part made the argument I keep coming back to: building the loop itself, trigger, scope, action, budget, is becoming a commodity. Claude Code, Codex, LangGraph, the tooling is mature and getting more accessible every month. What almost none of that conversation addresses is the verifier, because for a software team the verifier is easy. Tests pass or they do not. Exit code 0 or it is not. Binary. Solved.
Now translate the same five parts to a credit union, because this architecture has been running there since before any of it had a name.
The AI agent version. Trigger: a task gets assigned. Scope: the files and tools it is allowed to touch. Action: write the code, run the tests. Budget: how many turns it gets before it has to stop and ask a human. Verifier: a second model reads the transcript and checks the condition. Stop condition: “tests pass,” binary, no judgment required.
The version already running in your BSA department. Trigger: a transaction alert fires. Scope: the analyst’s authority to clear, escalate, or file. Action: review the pattern, apply judgment, decide. Budget: the analyst’s time before it goes to a second reviewer. Verifier: nobody, until the exam. Stop condition: “defensible to an examiner,” a judgment call, checked by no one in real time.
Every part on the left has an equivalent on the right that has been running at your institution for years. What is missing is the row in the middle: something that checks the loop’s work as it runs, instead of an examiner who checks eighteen months of it at once, by hand, under a deadline.
Brennan-Burke’s coordination tax is the same gap, described from the outside instead of the inside. A credit union is not one BSA analyst’s loop. It is hundreds of loops like it, running in parallel, across every department, every day. He is right that the tax comes from a missing brain. I would say it more specifically: it comes from a missing verifier, multiplied by every department that does not have one.
What an unverified loop actually costs
Hyperspell’s version of the company brain verifies a different kind of loop, the internal one, running inside a venture-backed startup, where the cost of an unverified iteration is a duplicated feature or an annoyed customer. That is real money, and it is recoverable money. Ship the wrong thing twice, apologize, ship the right thing next quarter. The verification there can afford to be a person noticing, eventually, in a search result.
A credit union’s loop cannot afford an eventual verifier. If the gap sits between what your BSA analyst knows and what your teller line knows, an unverified iteration is a suspicious transaction that clears because nobody asked the right question at the right desk. If it sits between your fair lending policy and what your underwriting team actually does day to day, an unverified iteration is disparate impact you find out about from an examiner instead of from yourselves. TD Bank’s $3.09 billion BSA/AML settlement in 2024, the largest in U.S. history, was not in the end a story about bad actors. It was a story about a loop that ran for years inside a $400 billion institution with a verification layer too thin to catch what was moving through it. And unlike a missed feature, a missed filing deadline does not wait for you to notice: BSA suspicious activity starts the clock the moment your institution has the information, whether or not anyone has checked yet.
That is what the tax looks like at the scale of a settlement. Most of the time it is quieter. I’ve heard this same two-week scramble described, almost word for word, by more than one CU compliance officer, in the run-up to an exam. Pull the board minutes. Pull the policy exception log. Reconcile the BSA case files against what the policy says should have happened. Track down the loan officer who handled a file eight months ago, because the system captured the decision but not the reasoning behind it.
That two-week scramble is the loop’s verification step. It is just an unusually bad implementation of one: manual, backloaded, run by whoever on the compliance team drew the short straw this cycle, checking eighteen months of iterations at once instead of one iteration at a time. It is needless in a specific way: the institution already produced the information a verifier would need, all year, one decision at a time. Nobody captured it anywhere durable enough to check without two weeks of archaeology first.
The same gap shows up in smaller, quieter iterations that never make it into an exam finding but cost the institution anyway. A teller notices a pattern that looks like elder financial abuse and mentions it to a supervisor, who means to loop in BSA and does not get to it for a week: an unverified iteration. A collections rep learns a member lost their job and is trying to work something out, and lending sends the next notice before anyone tells them: another one. A fraud analyst overrides an alert because she recognizes the merchant, and that judgment, the actual verification that happened, lives in her head instead of anywhere the next analyst inherits when she changes departments or retires. Nobody made a mistake. Everyone did their job correctly. What is missing is a verifier that catches the gap between what one part of the loop knows and what the next part needs, before it becomes eighteen months of archaeology.
More loops multiply the gap, they do not close it
Brennan-Burke’s own post gets to this before I do: “AI is making execution much cheaper… this will let companies do far more work. It will also create far more information… fast execution without coordination produces chaos faster.” He is right, and it is worth being specific about what that means at a credit union that is deploying its own AI Runners.
Every Runner is its own loop. The Loop Isn’t the Hard Part described the three-layer verification architecture a Runner needs before it can be trusted on real member data: deterministic validation, a review pass against a Playbook, and an audit trail an examiner can follow. That architecture verifies a single Runner’s loop. It does not, by itself, verify the institution’s loop: the one where a lending Runner’s decision needs to reach collections, and a BSA Runner’s flag needs to reach the teller line, and a fraud override needs to reach whichever analyst inherits the case next.
Add five Runners to a credit union with no shared verification layer connecting them, and you have not fixed the coordination tax. You have given it five more places to hide, each one moving faster than the meetings and status reports ever did. The institutions that deploy agents onto a coordination gap will find the gap running at machine speed before they find out it was there.
Paid continuously, or paid all at once
Here is the reframe I would offer back: coordination tax and compliance cost are the same line item, and the fix is the same fix. Most institutions budget for them separately, with separate tools, separate owners, and separate meetings, which is exactly backwards. A GRC platform that stores what happened after the fact is a record, not a verifier. It does not check the loop while the loop is running. It produces a file for the desk that comes asking later.
Examiner-Ready by Design made the case that compliance requirements are a design specification, not a burden, because every capability the NCUA expects (monitoring, control, audit trails, a kill switch) is something you would want anyway if you were building AI responsibly. This is the same argument, one layer down, in loop terms. The audit trail was never a compliance artifact bolted onto the real work. It is the verification log of the institution’s loop, read by two different audiences. What Your Credit Union Looks Like in 150 Lines of Python described the mechanism: capture the override at the moment it happens, with the analyst’s reasoning attached, and it becomes training data for the next analyst who hits a similar case. The same capture, read differently, is what an examiner is asking for eighteen months later. One verification log, two audiences, instead of a loop that runs for eighteen months with no verifier and a compliance team that reconstructs one from memory under deadline.
Coordination tax and exam risk are the same unverified gap, caught by two different people: your own team, on a random Tuesday, if you are lucky, or the examiner who shows up every eight to eighteen months to check the loop’s work for you.
Three ways to check whether your loop has a verifier
You do not need to wait for the exam cycle to find out.
-
Pick one open BSA case, one active policy exception, and one member hardship situation in progress. Ask three people in three different departments to describe each one, separately, without letting them compare notes first. If you get three different stories, or a person who does not know the case exists, you have found an unverified iteration. You found it for free, months before an examiner finds it for you.
-
Ask your compliance officer how many hours the last exam prep took, and how many of those hours went to producing new information versus reassembling information the institution already had somewhere. If it is mostly reassembly, your loop does not have a compliance problem. It has a verification layer that only runs once every eighteen months, by hand.
-
Ask what happens to a senior analyst’s reasoning on the day she retires. If the honest answer is that it leaves with her, the verifier for that part of the loop was a person, not a system, and it just walked out the door.
Brennan-Burke is right that intelligence is getting cheap and coordination is what is left standing in the way. I would put it in the vocabulary from the piece right before this one: the loop was never the hard part, for an AI agent or for the institution running dozens of them. The verification layer is, and it is the whole product. Credit unions have been running the loop, unverified, for decades, and calling the once-a-cycle catch-up exam season. The institutions that build a verifier into the loop itself, so it checks its own work continuously instead of once every eighteen months, will spend that two-week scramble on something else. The ones that do not will keep adding Runners to a loop nobody is verifying, and wonder why the coordination tax went up instead of down.
Runline builds AI Runners for credit unions: agentic systems with the compliance, governance, and audit-trail infrastructure that make the institution’s loop verifiable, not just faster. If you want to see where your loop’s verification gap is hiding, I would like to hear about it.
