An AI loop is an AI agent that runs repeatedly toward a goal instead of answering a single prompt: it takes an action, observes the result through tools, adjusts, and continues until a stop condition is met. The pattern emerged from AI coding agents in 2026 and is now applied to recurring work generally, from writing code to running business functions on a schedule.

What is a business loop?

A business loop is a scheduled, autonomous AI run, with tools, memory, and a stop condition, that operates one business function continuously: SEO, CRO, bookkeeping, or support triage. Unlike a code loop, it runs on live business data, never fully completes, and keeps a human on the judgment calls while the machine does the recurring execution.

What is the difference between a loop, a scheduled task, and a routine?

They're layers of the same idea. A loop is the general pattern: an agent iterating toward a goal with tools and a stop condition. A scheduled task (Claude Cowork's term) is a loop triggered on a calendar cadence on your own machine. A routine (Claude Code's term) is the cloud-hosted version. The community vocabulary settled on 'loops'; the vendor products implement the trigger and hosting layer.

What is loop engineering?

Loop engineering is the practice of designing AI agent systems that iterate toward a goal without per-turn human prompting, a term coined by Addy Osmani in June 2026. Its core elements are a goal with termination conditions, curated context, tool access, verification, and persistent memory. It emerged from software development; business loops apply the same pattern to business operations.

How much does running an AI loop cost?

Bounded, scheduled loops are cheap: our five production loops run on a $200/month fixed Claude subscription plus roughly $2-$5/month in external data API calls. Cost horror stories almost always involve unbounded loops hammering metered APIs without stop conditions. Bound the runs, cap retries, and prefer subscription compute, and the marginal run costs approximately nothing.

Do AI loops work without a human?

Not safely, and not well. Every production loop we run has an explicit judgment gate: a written list of low-risk actions the loop may take autonomously, with everything else drafted and queued for human approval. The human reviews decisions for minutes a day rather than doing hours of execution. Full autonomy is earned gradually per action type, never granted on day one.

July 7, 2026 · 9 min read

Business Loops: Loops That Run a Business, Not Code

A business loop is a scheduled, autonomous AI run that operates one business function continuously — SEO, CRO, bookkeeping, triage. The anatomy, the five we run in production, what they cost, and the failure modes the tutorials skip.

business loopsloop engineeringAI automationAI agentsautonomous systems

A business loop is a scheduled, autonomous AI run (with tools, memory, and a stop condition) that operates one business function continuously: SEO, CRO, bookkeeping, triage. The pattern comes from "loop engineering," the term Addy Osmani coined in June 2026 for AI agents that iterate on code without a human prompting each turn. Business loops are what happens when an operator points that pattern at the P&L instead of a codebase. Our agency's SEO department has been a loop for 90 days: it reads the search data every morning, checks the AI answer engines we're trying to be cited in, ships the low-risk fixes itself, and queues the judgment calls for a human. This is the field guide: the anatomy, the five loops we run in production, what they cost, and the failure modes nobody puts in the tutorials.

Every explainer published in the last month teaches loops that write code. This piece is about the other kind, and it's written from inside one.

Loops replaced prompts. Here's the 13-week arc.

In roughly 13 weeks, "give the AI a recurring job" went from folk technique to mainstream doctrine. The community settled on the word "loops," the vendors shipped the product surfaces, and by early July the most-cited AI educator alive was predicting that within months nobody would prompt at all. The dates matter, so here they are.

The folk ancestor was the "Ralph" technique circulating in late 2025: run the agent in a dumb loop and let it keep working. In late March 2026, Claude Code shipped /loop and scheduled runs; Claude Cowork's scheduled tasks and Claude Code's cloud Routines followed. On June 7, Addy Osmani published "Loop Engineering" and named the discipline. Boris Cherny, who created Claude Code, put it in one sentence that circulated for weeks: "I don't prompt Claude anymore. My job is to write loops." LangChain, Business Insider, and O'Reilly piled on within two weeks. And on July 1, Andrew Ng published his "3 key loops" and predicted that "in 3 to 6 months everyone will be using self-improving loops. No more prompting."

Read that list again and notice what every voice has in common: they're all talking about software development. Loops that write code, test code, fix code, ship code. That's where the pattern was born and it's where almost all the published expertise lives. It is not where most of the value is.

A loop that writes code vs. a loop that runs a business

Loop engineering optimizes a codebase; a business loop operates a business function. Same mechanical pattern (goal, tools, iteration, stop condition), different object. The difference sounds small and changes almost everything: the data sources, the risk model, who reviews the output, and what "done" even means.

	Code loop (loop engineering)	Business loop
Operates on	A codebase	A business function (SEO, CRO, books, support triage)
Feedback signal	Tests pass or fail; the compiler grades the work	Live business data: search console, analytics, ledgers, ticket queues. Noisy, laggy, no compiler
Cadence	Continuous until the task completes	Scheduled: daily, weekly, monthly, matched to how fast the data actually moves
"Done" means	The PR merges	Never. The function runs indefinitely; individual runs end, the loop doesn't
Failure mode	Broken build, wasted tokens	A wrong price pushed to production, a bad email to a real customer. Judgment gates are load-bearing
Who's accountable	A developer reviewing the diff	An operator reviewing decisions, not diffs

So: a business loop is a scheduled, autonomous AI run, with tools, memory, and a stop condition, that operates one business function continuously. Loop engineering built the pattern for code. Business loops are what happens when an operator points it at the P&L. We've been running them since April, they're the mechanism behind the agentic website we've written about (a website that runs itself is a website with business loops running on it), and they're how service as software actually gets delivered.

Anatomy of a business loop

Every production business loop we run has six parts: a trigger, a context load, tools, a judgment gate, a stop condition, and a ledger. Miss any one of them and you either get a demo (runs once, impressively, in front of you) or a liability (runs unattended, badly, without you).

1. Trigger and cadence. A schedule, not a human. Our flagship loop runs every day and branches by weekday: Monday and Wednesday are working sessions plus a daily health check, Tuesday/Thursday/weekend are lightweight daily checks, Friday is a full deep dive that audits citations, sweeps competitors, and updates the strategic plan. The cadence is matched to the data: search data moves daily, strategy moves weekly, the meta-review of the whole system runs bi-weekly.

2. Context load. The run starts by reading its own operating files: the client profile, the strategic plan, the content calendar, yesterday's log. This is what makes run #90 smarter than run #1 without anyone re-explaining the business.

3. Tools. Real connections to real systems: our search console, a SERP data API, the CMS, the deploy pipeline, Slack. A loop without tools is a newsletter. A loop with tools is an employee.

4. The judgment gate. The single most important design decision: which actions the loop may take alone, and which it must queue for a human. Ours is an explicit written tier list. Title tags, meta descriptions, schema, internal links, freshness stamps: the loop ships them autonomously. New articles, substantial rewrites, anything compliance-adjacent: drafted, previewed, and queued for approval. The human reviews decisions for about ninety seconds a day; the machine does the hours.

5. Stop conditions. Both per-run (the run ends when the day's checklist is done, not when the model feels finished) and per-action (our re-indexing submissions stop after two failed attempts and escalate to a human rather than retrying forever). Osmani's original piece is right that agents without termination rules waste tokens looping. In a business loop the stakes are higher than tokens: an agent that retries an external API forever isn't just expensive, it's the kind of behavior that gets your access revoked.

6. Memory and the ledger. Every run writes a dated log: what it found, what it pushed, what it's waiting on. Every claim it makes is checkable. This is also, not coincidentally, what makes the loop's results publishable. When we say our search visibility grew roughly 850% under the loop, that number has a paper trail.

The five loops that run our agency

We run five production business loops today; the oldest has run daily for about 90 days. Not demos, not weekend experiments: named systems with logs, budgets, and scar tissue. Here they are with real numbers.

The SEO/AEO engine (daily). The flagship, and the system publishing the page you're reading. Every day it pulls Google Search Console data, runs live checks on the AI Overview surfaces we target, diffs the results against yesterday, ships auto-publish-tier fixes, verifies that Google actually crawled what we asked it to crawl, and posts one consolidated Slack report. In its first 90 days: roughly 850% search-visibility growth, a captured Featured Snippet, named citations inside Google's AI Overviews, and one coined term ("automaton agency") adopted into the AI Overview's own definition eleven days after we published it. The full before/after is in the 90-day field report, and the build is documented as a case study.

The client CRO deep-dive (weekly). Every week, a loop reads a client's product analytics (sessions, funnels, rage-clicks, error events), runs a conversion and reliability review, and posts a prioritized findings brief to Slack. The client experiences it as a service: a weekly analyst's report that never skips a week. That's the point worth underlining: a business loop pointed at a client's problem is a deliverable. It's the mechanism behind the "service as software" economics we've written about; the loop is the junior analyst who never leaves.

The bookkeeping loop (monthly cadence). The relatable one. It reads the books through an accounting connector, reconciles transactions, flags what doesn't categorize cleanly, and prepares the close packet a human accountant actually reviews. Back-office loops are the least glamorous and the most obviously valuable: the work is repetitive, rule-shaped, and nobody's passion.

The re-index verification loop (daily sub-loop). Here's where it gets interesting. When our SEO loop publishes or edits a page, it asks Google to re-crawl. But a request is not a result, so a second loop maintains a ledger of every submission and checks back three days later: re-crawled, close the row; ignored, retry once; ignored twice, stop and escalate to a human. It's a small state machine that exists because we learned (the expensive way) that "submitted" and "indexed" are different facts.

The meta-audit (bi-weekly). Every two weeks, a separate run audits the auditor: are the daily logs actually being written, are the recommendations being actioned or silently aging, is the strategic plan drifting from reality? We call this layer the meta-loop: loops that watch the loops. It's the part of the architecture nobody writes about, and after 90 days we'd argue it's not optional. Unwatched automation degrades silently; the meta-loop is how you find out before your customers do.

What business loops actually cost

Our five production loops cost less per month than one hour of agency time. There's a backlash thread making the rounds calling the loop trend "a financial nightmare," and it deserves a real answer with real numbers, because the horror stories are real and avoidable.

Our stack, concretely: the model compute runs on the same fixed-price Claude subscription we already pay for (a $200/month plan covers every loop we run, because scheduled runs are bounded and spread across the day, not hammering an API in a while-true loop). The external data layer for the flagship SEO loop (live SERP reads, keyword volumes, crawl checks) costs in the range of $2 to $5 a month at our cadence; a single live SERP read is about $0.002. The infrastructure (a few serverless functions wiring the data APIs to the agent) rounds to zero.

The cost horror stories almost all share one anatomy: a metered API, an unbounded loop, and no stop condition. That's not a loops problem, that's a missing-stop-condition problem; it's the first of Osmani's five elements for a reason. Bound the runs, cap the retries, run on a subscription where you can, and the economics invert: the marginal cost of the 90th run is the same as the first, while a human doing the same daily sweep would bill more per day than the whole system costs per month. The real cost isn't compute. It's the operator time to build the judgment gate and the first month of supervision while the loop earns trust. That cost is real, front-loaded, and it's exactly the moat.

Failure modes we've actually hit

Ninety days of production means our loops have failed in instructive ways; here are four failures and the guardrail each one bought us. This is the section we most wish had existed when we started.

The blind run. One morning the loop's data connections came up slowly, and instead of waiting, it concluded the tools were unavailable and ran in a degraded mode. It missed six newly published pages, which sat undiscovered by Google for days. The fix: a connectivity preflight that probes every connection, retries with backoff before declaring anything down, and (if a run ever does go degraded) writes a flag file so the next healthy run does a full catch-up reconciliation automatically. Design the loop to distrust its own startup.

The big-wave stall. We once published six pages in one day, lightly cross-linked. Google's crawler ignored most of them for over a week: new URLs get discovered through internal links, and a batch of near-orphans starves. Now no page ships without at least two inbound links from already-crawled pages, computed by a link-graph audit at publish time, and the loop staggers big waves. The guardrail came out of the failure, not the plan.

The infinite politeness problem. Ask Google to re-crawl a page and it may simply ignore you. The naive loop asks again forever. Ours caps at two attempts, then escalates to a human with the evidence, because sometimes "ignored twice" is itself the signal (a quality problem the human needs to look at, not a retry problem the machine can solve).

The unattended-push line. Early on, everything the loop wanted to change queued for approval, and the queue became the bottleneck: the human was rubber-stamping title tags while real opportunities aged. The current posture took weeks to calibrate: mechanical, reversible changes ship autonomously; visible copy, new content, and anything compliance-flavored queues. Getting this line right is the actual craft of business loops. Too tight and you've built a suggestion box; too loose and you've given an intern with infinite energy your production keys.

How to start: the operator's on-ramp

Start with one loop, one function, one report, and a human on every judgment call. Not five loops. Not an "AI employee." One scheduled run that reads one system, produces one useful artifact on a fixed cadence, and changes nothing without permission.

Pick the function where the data already lives in a system a tool can reach (search console, analytics, the books) and where the weekly work is real but rule-shaped. Give the loop read access first; let it run report-only for two or three weeks. You're testing two things: whether its reads are right, and whether its judgment about what matters is earning trust. Then, and only then, grant it the narrowest write permissions that would save you real time, with an explicit list of what it may touch. Widen the list as it earns it. That supervised-first, autonomy-earned progression isn't caution theater; it's how every loop we run went from demo to department.

The product surfaces for doing this with Claude specifically (Cowork scheduled tasks vs. Code's /loop vs. cloud Routines, and when a non-developer should use which) deserve their own guide, and we've mapped them in Claude loops for business. If you'd rather see where a loop would pay off in your own operation first, that's literally what our Revenue Audit is for.

One more honest note: the vocabulary here is three months old and still settling. The tools will be renamed; the pattern won't be. Schedule, tools, memory, judgment gate, stop condition, ledger. That's the durable part, and it's the same six parts whether the loop is optimizing a codebase or closing your books.

FAQ

Published: July 2026. The loops described are in production; the numbers cited come from their run ledgers.

Keep reading

← All insights Start a conversation →