By Sean Hsieh, Founder & CEO, Runline
A post on X recently (a guide to “loop engineering” by AI writer Anatoli Kopadze) has 8.7 million impressions. Jensen Huang quoted it on stage. Boris Cherny, the engineer who built Claude Code, is on video describing how he runs thousands of AI agents in loops every night while he sleeps. Peter Steinberger, who built the OpenClaw agent runtime, put the thesis in twelve words: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
The energy around this is real. So I spent a few days reading the actual technical substance under the hype. Here’s what I found, and why it matters differently for credit unions than it does for everyone tweeting about it.
What /goal Actually Is
The feature driving most of this conversation is Claude Code’s /goal command, which shipped in May 2026. The way it’s being described on social media, you’d think Anthropic reinvented autonomous computing. The actual implementation is more interesting in its modesty.
When you type /goal all tests in test/auth pass and the lint step is clean, Claude Code sets up a loop. After each turn (each time the main agent finishes a unit of work), a second, smaller model (Haiku, by default) reads the full session transcript and answers one question: has the stated condition been met, yes or no? If no, the reason gets fed back to the main agent as context and it runs another turn. If yes, the loop clears.
That’s it. The loop is a while loop. The “verifier” is a fast model reading a transcript. The innovation isn’t the architecture. It’s that the architecture is now a single slash command instead of a 107-line bash script.
For context: that bash script is real. The community-built “Ralph loop” that predated /goal by over a year was literally that: a bash while loop that repeatedly spawned a fresh Claude Code instance to work through a task list until stories passed. Anthropic’s contribution was productizing the pattern, cleaning up the session management, and adding the separate evaluator. Those are meaningful improvements. They are not a paradigm shift.
What is genuinely new is the model capability crossing the threshold where this becomes reliably useful. Earlier agentic loops (AutoGPT in 2023 is the canonical example) became famous for spinning indefinitely and accomplishing nothing. The underlying pattern was the same; the models just weren’t good enough to converge. Claude Opus 4.x changed the math. In our own production deployments, tasks that used to require fifteen or more iterations now stabilize in three to five. That’s what made the pattern reliable enough to matter.
I’m being precise about this because the distinction matters for what comes next.
The Real Hard Problem
Here’s the thing the loop engineering conversation is skating past: the loop is the easy part.
Addy Osmani, who wrote the most technically careful treatment of this moment, in an essay simply titled “Loop Engineering,” buried the key line where most readers miss it: “Unattended loops generate unattended mistakes. Code quality remains the engineer’s responsibility.” The New Stack put it more plainly, in a piece on agent verification: “Loops are replacing prompts. Verification is about to be your biggest problem.”
They’re right. And in regulated industries, verification isn’t a footnote. It’s the entire product.
If you’ve started exploring Claude Code’s /goal command for your credit union’s operations, and the conversations I’m having suggest many of you have, here’s the question you probably haven’t answered yet: what is your stop condition, and could you explain it to an NCUA examiner in thirty seconds? Not in principle. For the specific workflow you’re thinking about deploying. Right now. Because the loop will run whether or not you’ve answered that question, and the examiner will ask it whether or not you’re ready.
Here’s why that question is harder than it sounds. When a software developer runs /goal all tests in test/auth pass, the stop condition is deterministic. npm test either exits with code 0 or it doesn’t. The Haiku evaluator doesn’t make a judgment call. It reads the output and the answer is binary. This is a genuinely solved problem with decades of tooling behind it.
Now replace “tests pass” with the conditions that actually govern credit union operations:
- This member’s suspicious activity report has been correctly flagged under FinCEN guidance.
- This tax garnishment calculation is accurate to the member’s outstanding balance and applicable exemptions.
- This outbound collection queue excludes members protected by active bankruptcy stays.
None of those conditions are binary in the way exit code 0 is binary. They require domain knowledge, regulatory context, and in some cases human judgment that isn’t encoded anywhere a Haiku model reading a transcript can reliably reach. The loop doesn’t know what it doesn’t know. In financial services, what it doesn’t know can mean a CFPB complaint, an NCUA examination finding, or direct harm to a member.
The software developer’s verification layer is tests. The credit union’s verification layer is federal regulatory standards. Those are not equivalent problems, and the tooling built for one doesn’t transfer to the other.
What We Actually Built
I’m not speaking theoretically here. We deploy Runners (Runline’s term for purpose-built AI agents; the industry calls them agents, I’ll use both) in credit union operations. One of them runs a daily field modification analysis: it surfaces changes to member accounts that require human review, and the output lands in an analyst’s inbox every morning.
The agent runs overnight. The analyst’s inbox is real. The members are real.
The first engineering question we faced wasn’t “how do we build the loop.” Loops are straightforward. The first question was: how does the analyst know whether to trust what’s in that report?
The answer has three layers.
Layer one: deterministic validation before anything leaves the agent. Before the runner’s output reaches any human, it passes through a rules engine that checks structural correctness: field counts, format compliance, date ranges, required fields present. This isn’t an LLM. It’s a deterministic script that either passes or throws an exception. If it throws, the report doesn’t go out and someone gets paged. This layer exists because an LLM-generated report that looks correct but has a malformed date range or a missing required field shouldn’t reach a human reviewer. It should fail loudly before that.
Layer two: a separate review agent against a domain-specific rubric. A second agent reads the primary agent’s work and checks it against criteria that encode the actual regulatory and operational standards, not a generic “does this look right” prompt, but specific questions derived from the workflows we’re replacing. We call this rubric a Playbook: the SOP encoded as verifiable criteria, not documentation. This is closer to the /goal evaluator pattern, but the rubric isn’t written to evaluate generic code quality. It’s written to evaluate compliance with the specific process the Runner is executing.
Layer three: an audit trail the examiner can follow. Every decision the runner made (what data it examined, what rules it applied, what it flagged and why) is logged in a format a human auditor can read and a federal examiner can follow. Not because examiners review every run. They don’t. But because the audit trail is what makes the other two layers credible. Without it, you’re asking a credit union to trust a black box. Would you stake an examination finding on a loop that stops when it “feels done”? That question answers itself.
Three layers sounds like a lot. It is a lot. It’s also the minimum viable architecture for running AI agents unattended on real member data in a regulated environment. The loop is one line of that architecture.
Where the Industry Goes Next
The current loop engineering wave is solving a real problem for software development teams. Building the loop (trigger, scope, action, budget, stop condition) is becoming a commodity. Claude Code, Codex, the OpenAI Agents SDK, LangGraph: the tooling is mature and getting more accessible every month.
The next competitive surface is verification infrastructure for specific verticals. Not generic evaluator models reading session transcripts. Domain-specific verification layers that encode what “correct” actually means in a regulated context, and that produce evidence of correctness that satisfies regulators, not just product managers.
For credit unions, that means:
- Stop conditions that reference regulatory standards, not just test suite results. A Runner that stops because FinCEN guidance requires it is categorically different from one that stops because a Haiku model said yes.
- Audit trails built for examiners, not developers. The log that proves a decision was made correctly matters more than the log that helps you debug what went wrong.
- Kill-switch infrastructure at multiple levels (the individual runner, the workflow, the entire organization), because at 3 AM when something goes wrong, the question isn’t how to fix it. It’s how to stop it right now, and how to prove it stopped.
- Human escalation paths that are part of the loop design, not bolted on afterward. The loop should know when to stop and call a person. That’s a design choice, not an edge case.
The institutions that figure this out first won’t just run better agents. They’ll run the only agents that are actually safe to run unattended, which is the whole point.
Jensen Huang is right that the new job is to write and handle loops. But “handle” is carrying a lot of weight in that sentence. Handling a loop in a software development context means reviewing a pull request and approving it. Handling a loop in a credit union context means being able to account for every decision the loop made to a federal regulator.
Those are different products. They require different architectures. And the current wave of loop engineering enthusiasm, for all its genuine momentum, hasn’t seriously addressed the second one.
The loop isn’t the hard part. The verification layer is. And the institutions that understand that distinction before their vendors do will have a significant advantage in what comes next.
Next in this series: the verification problem has a specific shape in BSA/AML workflows: where the cost of a false negative is categorically different from the cost of a false positive, and where standard software testing patterns fail completely.
Runline builds AI Runners for credit unions: agentic systems with the compliance, governance, and kill-switch infrastructure that regulated institutions require. If you’re thinking through what loop engineering means for your operations, I’d like to hear what you’re working on.
