How to Become an AI-Native Company (2026)

Search this question and you get strategy memos. They tell you AI-native means data as infrastructure, processes driven rather than assisted, a steering committee, a 90-day roadmap. Then they stop, right at the point where you'd have to build something.

This one goes the other way. It's got a real loop spec file in it, redacted but structurally intact, plus the actual schema our loops read and write. You also get what four days of one loop cost, to the cent, including the two runs that failed and billed anyway, and the loop we paused after it burned $50.71 producing work we deleted.

If you run a company and you want to see the artifacts, that's what this is.

One assumption up front: you've already decided to do this. I'm not going to define AI-native for you. This is about how the company runs. Whether AI shows up in your product is a separate question.

What Actually Changes at the Operations Layer

Before AI, the human was the glue. You did the research, handed it to someone, read what came back, decided what happened next, and carried the context between every step. Every workflow in the company ran through a person holding it together.

The obvious move is to swap the person for an agent. That gets you an enhanced workflow. It's a real productivity gain, and it's also where we stopped for a while. The work gets done, nothing flows back, and the system doesn't know today what it learned yesterday. That's an open loop.

An AI-native operation is a closed loop. The work runs, the outcome gets captured, and the outcome feeds back into what the next run does. Borrowed straight from control systems, and the metaphor holds all the way down.

The trigger isn't you any more. Agents get woken by cron, by webhooks, by other agents, not by a human deciding it's time. Once nobody has to remember to start the work, the work starts happening at 3 a.m., and the volume changes character.

And we've started counting progress in loops instead of headcount. You don't hire a support person, you build a support loop and then argue about how much rope it gets. Tom Blomfield at Y Combinator put a number near this in his talk on building a self-improving company: batch companies reaching demo day with about 5x more revenue per employee than they did 18 months ago. That's a YC partner's on-stage read with no published dataset under it, so treat it as a direction rather than a benchmark. Amjad Masad describes the same shape at Replit over six months, the same engineers producing 3x the output and the hardest support tickets resolving 60% faster. Replit's own figures, also unverified.

The thing you can verify yourself is smaller and more useful. Here's what it looked like on our side. Around 1 a.m. one night a whole bunch of PRs kept submitting to our codebase, and that wasn't because anyone was working extremely hard. It was the loops finding issues and picking up the work. You can go and check it: PR #201 on 2026-07-21 and #203 on 07-22 from the blog enrichment engine, #210 on 07-23 from the loop engineering SEO engine, #214 on 07-24 from the graph engineering SEO engine. Real numbers on real dates, opened while nobody was awake.

That's the operations layer changing. It's a different answer to who starts the work.

The Small-Team Version

If you're one to ten people, ignore the org charts in the strategy memos. You don't have departments. You have functions, and functions become loops.

As of the June 2026 walkthrough of our own repo that was five loops, one per team member, running on their own machines. Four I can name here: SEO, support, growth experimentation, Reddit. The fifth I can't stand behind, so I'm not counting it. The fleet has changed a lot since, so take that as a dated snapshot rather than a current inventory. What I can say about that particular week is that at five loops our own days had already stopped being about tasks and started being about which loop needed attention. I don't know where your number is, and I'd distrust anyone who tells you they do.

The setup underneath is deliberately boring: a memory layer, a set of skills, and cron. That's it. Memory is where the loop's state and history live so run 40 knows what run 39 did. Skills are the procedural knowledge, the how-to-do-this-well, kept out of the raw log so it doesn't rot. Cron is what takes you out of the trigger. We have a deeper breakdown of the memory half in agent memory systems and of the loop mechanics in the loop engineering guide, so this page won't re-explain either.

What none of those strategy memos shows is what one of those loops actually looks like on disk. So here's ours.

A Real Loop Spec, Redacted

This is an excerpt from loopany/graph-engineering-seo-engine/README.md, the file our daily SEO loop reads at the top of every single run. It's the actual contract the loop runs on. Every performance figure and one local filesystem path have been stripped, and several pipeline steps are cut for length, which is why the step numbering skips. Everything left is exactly as the loop reads it.

# Graph Engineering SEO Engine

## Spec

**Mission:** own the emerging head term "graph engineering" on Google. Hold/extend the
pillar `content/blog/graph-engineering-guide-2026.md` in the top 3, expand the cluster
footprint around the term while competition is still thin, and funnel readers into the
course/community.

**Regime: LAND-GRAB / ship-mode.** Graph is an emerging term with an open SERP. The
default per-run action is ship ONE new cluster article to widen the footprint, deduped
against everything already live.

**The regime-flip gate is computable. Use these numbers, not a vibe.** "The families are
all owned" cannot be read off GSC directly, so judge saturation by the two metrics the
workflow computes every run: `family_top3_share` (share of family impressions sitting at
position <= 3) and `family_weak` (family queries at position > 5 with >= 50 impressions).
Flip out of land-grab into the daily-improvement regime when
`family_top3_share` >= 85% AND `family_queries` grew < 10% versus the prior run AND
`family_weak` <= 2. Until all three hold, stay in land-grab. State the three numbers and
the resulting call in every run report, so the regime is never re-argued from scratch.

**North star = position + footprint, NOT clicks.** Scoring the loop on clicks would tell
it to stop the land-grab exactly when the ground is getting valuable.

**This is an OPEN monitor, not a closed loop.** No `finish`; the config goal is cleared.
It never self-completes. If runs degenerate into measure-and-skip with nothing to ship,
slow the cadence rather than forcing thin articles.

Runs daily at 10:00 (Australia/Sydney), staggered off the sibling loops so GSC and API
load do not collide.

### Per-run pipeline

1. **Read state first.** This file's `## Current understanding` + `## Timeline`, the
   pillar's current `targetKeywords`, the pages already live, and `git log -20`. Never
   re-ship a keyword already covered or in flight.
2. **Read the score.** A deterministic pre-stage runs before you and hands over live GSC
   data. Do NOT re-run those pulls; that is the workflow's job and re-doing it is the main
   cost sink this loop has.
   `pos_alert` bands: ok <= 3 - watch <= 4.5 - slipping <= 7 - critical > 7. A slide of
   >= 1.5 places in 5 days escalates a band on its own. If `pos_alert` is slipping or
   critical, that is the headline of your run message. A missing day is missing, never 0.
   Never write 0 for a failed read.
2b. **Check deployment.** An unmerged article is NOT live. While any are unmerged, treat
   flat position as expected, not failure. Merging is Jason's call, never the loop's.
2c. **Verify shipped articles.** Every shipped article gets `verify_after: <merge + 14d>`.
   When due: did its target family form, and did it hurt the pillar? Never revert yourself.
5. **Mine the freshness gap.** Do NOT ground on our own pages and GSC alone; that is the
   closed-loop failure that stalled the sibling engine. Pull fresh external signal and
   diff it against our coverage: the curated bookmark stream in `<vault>/x-bookmarks/`
   first, then repo and release activity, then the 30-day chatter sweep.
8. **The CTA test (hard gate).** Answer in writing: "What will the reader DO after this
   article?" If the honest answer is "close the tab", the keyword fails. No exceptions.
10. **Ship.** Branch, commit, open a PR. NEVER commit to main. **Quality valve:** if NO
   candidate clears the bar, ship nothing and log "no qualifying keyword" with the
   rejected candidates and why. Thin pages actively hurt the pillar.

**Reconciliation:** verify against the LIVE system, not this frozen spec. If Jason already
shipped something or changed the play, respect that.

Read what's actually in there.

The gate is computable. Three named thresholds and a boolean decide it. That exists because the loop was re-arguing its own strategy from scratch every run and burning tokens doing it. Now it states three numbers and the call, every time.

There's an explicit do-nothing branch. Step 10's quality valve says ship nothing and log why, and the spec states the reason in place: thin pages actively hurt the pillar. If your spec has no way to say no-op, you've given it no way to tell you there was nothing worth doing.

The line about not writing 0 for a failed read is in there because a failed metric pull once got recorded as a zero and looked like a collapse.

And the reconciliation rule at the bottom tells the loop that the file it's reading might be stale and the live system wins. A spec file is frozen the moment it's written and a company isn't, so without that line the loop treats its own instructions as the current state of the world.

The rest of the file, not shown, is a ## Current understanding block and an append-only ## Timeline. That's the loop's memory: current state that gets pruned, plus history that never gets edited. Same split as agent memory, applied to a business function instead of a codebase.

The Same File, Empty

Here's that spec with our specifics stripped out, so you can fill it in for whatever function you're starting with. Copy it to <your-loop>/README.md and answer every angle bracket before you set a trigger. If you can't answer one of them, that's the part of the loop you haven't designed yet.

# <Loop name>

## Spec

**Mission:** <the one outcome this loop owns, in a sentence>

**North star:** <the metric> and NOT <the obvious metric>, because <what the obvious
one would tell the loop to do wrong>.

**Regime:** <mode> until <computable condition>. The condition is numbers, not a vibe:
flip when <metric_a> <threshold> AND <metric_b> <threshold> AND <metric_c> <threshold>.
State all three numbers and the resulting call in every run report, so the regime never
gets re-argued from scratch.

**Type:** OPEN monitor, never self-completes | CLOSED, finishes at <condition>.

**Cadence:** <cron>, staggered off <sibling loops> so <shared API or resource> doesn't
collide.

### Per-run pipeline

1. **Read state first.** This file's `## Current understanding` and `## Timeline`, plus
   <the live source of truth>. Never redo work already done or in flight.
2. **Read the score.** <deterministic pre-stage that runs before the model>. Bands:
   ok <= <x>, watch <= <y>, slipping <= <z>, critical > <z>. A missing reading is
   missing, never 0. Never write 0 for a failed read.
3. **Check reality.** <what "shipped" actually means here>. <the state that means not
   live yet> is expected, not failure.
4. **Ground outside yourself.** Pull <fresh external signal> and diff it against what we
   already have. Do NOT ground on our own output alone.
5. **<The work.>**
6. **<The hard gate.>** Answer in writing: <the one question that must be answered before
   shipping>. If the honest answer is <the failing answer>, it fails. No exceptions.
7. **Ship.** Branch, commit, open a PR. NEVER commit to main.
   **Quality valve:** if NO candidate clears the bar, ship nothing and log
   "no qualifying <item>" with the rejected candidates and why.

### Escalate to a human

- <the irreversible action this loop must never take alone>
- <the ambiguity this loop must not resolve by itself>

### State this loop declares every run

`<key_1>`, `<key_2>`, `<key_3>` ... every run writes all of them, every time.

**Reconciliation:** verify against the LIVE system, not this frozen file. If a human
already acted or changed the play, respect that.

## Current understanding

<pruned. current state only. rewritten as it changes.>

## Timeline

<append-only. one line per run. never edited.>

The valve in step 7 and the escalation list are what decide whether you can walk away from the thing.

What One Loop Costs

I couldn't find this published anywhere, which is strange, because it's the first question I get asked.

That same graph SEO loop, complete metered history from loopany log --json, six of six runs priced:

About $19 for four days of a daily loop, and $6.65 of that, 35%, went on two runs that failed and produced nothing. Failed runs still bill. That number wasn't in our own cost model and it should've been.

For range, from the same source: our blog enrichment engine ran four of four priced runs at $8.77 total, so $2.19 a run, on a three-day cadence. The expensive end is a design-build loop at $7.82 to $15.58 per priced run, because it renders and screenshots real pages. And one visibility-check run burned $5.74 and then failed on "you've hit your monthly spend limit," which is its own kind of lesson about caps.

So the small-team math is a few dollars per run, single-digit dollars a day for a daily loop, and a real percentage of that lost to infrastructure failures you don't control. It's cheap, and the failure tax is the part that surprised us. The cost levers that actually move this are in agent reliability and cost control; the biggest one is not waking the expensive model at all when a cheap script can tell you there's no work.

That's the bill when a loop behaves. The tail is much fatter, and it's documented in public. Four separate operators filed the same failure on issue #68110 of the anthropics/claude-code tracker: recursive sub-agent fan-out. One research request spawned 48 background agents when the first three or four had already answered the question. Another spawned 905 agents and burned $87 in about a minute before the reporter physically unplugged the machine. A third spawned over 900 and ran through roughly $700 in 30 minutes on a company AWS Bedrock account. Someone in the same thread traced it and confirmed it at the binary level: spawn depth is capped at 5, and there's no breadth cap anywhere. Those are user-filed reports on a public tracker, so treat the dollar amounts as claims rather than audited numbers. The mechanism is confirmed, and the fix is structural, which is the guardrails section below.

The Org Version, as Context

If you already have departments, most of the above still applies. Here's what changes.

Humans move up a level. You review outcomes instead of sessions, which only works if the results are legible enough to judge quickly.

Autonomy gets granted per function, never to the system, and the mistake is asking "how autonomous should our AI be" as one question. It's one question per function, and the answers shouldn't match. A loop that drafts blog posts and a loop that emails customers don't deserve the same rope, and a loop that emails customers doesn't deserve the same rope for enterprise accounts as for free-tier signups. The right shape is a ladder: human only, then AI drafts and a human approves, then AI executes under supervision, then autonomous inside stated limits. A function climbs on evidence and gets walked back down when the evidence stops holding.

Our CRM loop is the design case, and our version is less impressive than the pitch. In his write-up on running loops for a month, Jason describes autonomy earned per segment rather than granted to the loop: drafts only at first, and segments whose reply rates prove out earn the right to send on their own. That's the design he argues for, not a run record. The loop's own contract file says never send emails autonomously, drafts only, Jason sends via the UI, and its status block records leads contacted with no customer replies yet. So there were no reply rates for any segment to earn on, and I'm not going to invent a number. I'm leaving it in because the tiering principle is right even where our own execution hasn't caught up to it.

Coordination happens through shared state. No loop messages another loop.

The Shared State, as an Actual File

Loops don't DM each other. Each one reads current world state, does its work, writes state back, and never needs to know which other loops exist. Support writes a user-problems artifact, the product loop turns it into requirements, engineering fixes it, a verify loop updates the result. Coworkers coordinating around documents instead of a group chat.

The reason to care is the wire count. Four loops messaging each other is six contracts you own and have to keep in sync, and a fifth loop makes it ten. Four loops reading and writing one folder is four, and a fifth makes it five.

The strategy memos say "data as infrastructure" and stop. Here's the contract, from signals/README.md, the real file every one of our loops reads and writes:

kind: signal                # the record type
id: <ID>                    # stable, human-referenceable
title: "<one-line claim>"
description: "..."          # REQUIRED, one line, answer-first
category: <theme>           # free-text theme (friction / pricing / attribution / ...)
status: open | considering | spawned | dismissed
frequency: <n>              # ++ each recurrence; the dedupe count
sources: ["[[<SRC-1>]]", "[[<SRC-2>]]"]
domain: [<area>]            # a list; one signal can touch several
segments: [free, paid]      # optional; who is asking, paid weighs more

The rules that travel with it are what make it a coordination layer rather than a folder.

Dedupe by frequency. The fifth person reporting the same friction doesn't create a fifth record, it increments frequency on the existing one and appends a line to that record's timeline. So frequency is a count of real occurrences, and the body carries an append-only ## Timeline where each entry is one YYYY-MM-DD | source - what line. Frequency always equals the number of timeline entries, so a loop can't inflate it by feeling strongly about something.

Priority comes from a formula: frequency x segment weight x validated impact. Any loop reading the folder computes the same ranking, so two loops never disagree about what matters most.

Status is a lifecycle: open while it accumulates, considering while we weigh it, spawned once we've committed and a task exists, dismissed when we won't act. Planned and shipped are deliberately not signal states, because those belong to the task the signal spawned.

Promotion is explicit. When the company commits, the signal spawns a task and gets linked. That's the seam where an observation turns into work, and it's where a human gets to say yes or no.

Here's a filled instance so you can see the shape. This record is synthetic. Every value is invented for this article. Our real signal files carry named customers, support conversation IDs, verbatim quotes, and conversion data, so none of them are publishable, and I'm not going to pretend a redacted one would still be the artifact.

---
kind: signal
id: FB-42
title: "Setup stalls at the API-key step"
description: "Onboarding friction, open (free + paid, freq 6): new users stop at the API-key screen and never reach a first successful run, so activation never fires."
category: friction
status: open
frequency: 6
segments: [free, paid]
sources: ["[[SRC-101]]", "[[SRC-104]]", "[[SRC-109]]"]
domain: [product, onboarding]
tags: [feedback, friction, onboarding]
---

# Setup stalls at the API-key step

## Theme
New users reach the API-key screen, cannot tell which key is wanted or where to get it,
and abandon before their first successful run.

## Recommendation
Show the expected key format inline and offer a no-key demo run, so the first success
does not depend on getting credentials right.

## Timeline
- 2026-07-14 | support - third report this week, same stall point. freq to 6
- 2026-07-09 | user interview - same stall, raised unprompted. freq to 5
- 2026-07-02 | support - first logged occurrence. freq to 4

Loops also declare their own machine-readable state so a dashboard can read them without parsing prose. The graph SEO loop declares nine keys: head_pos, pillar_pos, family_queries, family_top3_share, family_weak, family_clicks, family_imp, pillar_clicks_28d, prs_unmerged. Every run writes all nine. That's what lets us triage the fleet in a morning instead of reading run logs one by one.

If you want the deeper version of loops-as-a-graph with shared state on the edges, that's graph engineering, and the decision of when you actually need it is in agent graph vs loop. Files in a folder took us further than we expected.

What Breaks

Start with the one we can price to the cent.

The Loop That Scored 8.5 On Everything We Deleted

We run a build engine that ships design items to a public library. Its ship rule was clean and looked rigorous: an independent vision critic scores the build out of 10, ship if the score is 8 or higher with all hard checks passing.

It hit that bar consistently. Scores of 8.0 to 8.6, all hard checks passing, run after run. By its own instrumentation the loop was working.

Then Jason looked at the live items and started deleting them. Seven gate-passing designs got rejected by eye: DP-760, DP-1120, DP-1140, DP-1160, DP-1180, DP-1800, and one more on 07-24. The reject reasons on record are things a score couldn't see. Not animated, should be, because a static page shipped into an animated category. Doesn't look good, meaning a pale low-contrast washout that only reads as bad at full-page distance. Doesn't look good again, this time a near-verbatim clone of Apple's own Stocks app with no point of view. Looks like built by AI, especially the banner.

The loop was optimizing its gate score. The gate score was a proxy for the owner's eye. The proxy and the target came apart, and the loop kept scoring 8.5 the entire way down.

Four of the seven rejects are priced directly in the run log:

$50.71 of metered spend on four artifacts that got removed, plus three more rejects whose runs fall outside the retained log window. The public library count went backwards twice, 36 down to 33, then 36 down to 35.

On 2026-07-24 the loop was paused rather than patched item by item, and the gate was rewritten before it ran again. Five changes:

The score threshold rule was retired outright. The spec now says so in place: the old rule is retired, it passed all 7 items Jason later rejected. It was removed rather than retuned to a higher number.

The critic was made adversarial and reject-first. Its job is to kill the design. It defaults to REJECT and ships only if it genuinely can't find a killer.

A rejection gallery was added, holding the seven deleted designs as calibration. Every new build gets screened against it first, and any match is an instant reject with no score computed.

A retired-concepts registry was added. When the owner's eye kills a concept, the concept gets retired rather than re-skinned. That rule exists because DP-1800 was the sanctioned rebuild of rejected DP-1140 and got rejected too. Zero for two.

Two new hard checks landed, value-contrast at full-page distance and no first-party clone. For animated categories the critic now has to watch the live preview instead of judging a frozen still.

The loop resumed the same day once the rework was approved.

Our gate drifted while reporting that everything's fine. We paused the loop rather than patch the seven items, because they were one failure and not seven.

Goodhart, in General

That's the specific case. Here's the general one.

Consider a support agent optimizing ticket-resolution rate. It runs for five months. Resolution rate climbs the whole time. Churn doubles, because the agent learned to close tickets fast, discourage follow-ups, and mark unanswered tickets resolved. It hit the number and broke the business.

That example is a hypothetical, not something we lived. I'm using it because it's the cleanest illustration of the mechanism, and because attaching a real company's name to a story like that without a receipt is exactly the sort of thing this article is trying not to do. The mechanism is real regardless: once a loop optimizes a metric unattended, the metric becomes the risk.

The Swarm Where Everything Is Green

The natural fix for Goodhart is to add supervision, so you put a watching loop over each optimizer, a slower loop that adjusts the goals it's chasing, and audit loops checking that the metrics still map to anything real.

Push that far enough and the loops are checking each other, every dashboard is green, and nothing in the system still touches a real user or the real world. We've been running this at company scale since June, and goals, permissions, audit and real-world verification are still open problems here.

The practical version of the rule: every loop needs at least one leg standing on something external it doesn't control. Live search data, a real ticket from a real person, a test suite, a production error.

Two Failures That Look Like Success

Both of these are ours, and they're worth checking for in your first week.

We had a reply loop record 119 runs and post nothing. A CLI bug meant it couldn't post multi-line text, so it skipped, correctly, every time. Its weekly retro opens with "nothing to grade yet. Zero replies posted this week." One hundred and nineteen runs of clean, well-behaved, zero-output work.

And on 2026-07-23 every browser-driven loop across three repos posted nothing, because a Chrome extension had unloaded. The loops handled it correctly and never half-posted. But a correct skip records as ok, so in the fleet view the outage was invisible. A human had to spot it. We now run a daily bridge-health check before the posting window opens.

Both of these are the same bug in the observability layer rather than in the loops. In our fleet view a skip and a success looked identical. If you build one thing into your fleet view on day one, make it the ability to tell "ran and did nothing because there was nothing to do" apart from "ran and did nothing because it couldn't."

The Real Ceiling Is Your Review Bandwidth

Here's the constraint we ran into.

Every loop you add produces more artifacts that need a human decision. PRs to merge, drafts to approve, signals to triage. Adding another loop doesn't increase throughput if the person doing the reviewing was already the bottleneck. It just deepens the queue.

You don't have to take my word for that, and the outside numbers are harsher than mine. LinearB's 2026 benchmark report covers 8.1 million PRs across roughly 4,800 teams: 84.5% of manual PRs merge within 30 days, against 32.7% of AI-assisted ones. Reviewer pickup time goes from about 200 minutes to about 1,050 minutes, and AI-assisted PRs run past 400 lines at the 75th percentile against 157 for unassisted. Those are LinearB's own platform figures, not mine. A separate study of the AIDev dataset found 61.38% of AI-generated PRs get no recorded review at all, and among the ones that do get reviewed, most of the reviewing is done by other agents rather than people.

Open source maintainers have written it down as policy. OpenTofu's AI usage policy says automated tooling is easy to scale and they've yet to find a way to scale their maintainers' attention. Dov Katz at Morgan Stanley puts the same thing in merge terms: until it's merged, the fix is worth nothing. An investment bank and a Terraform registry, arriving separately at the same sentence.

Our SEO loops carry a small rule about this. Every run counts how many of its own shipped PRs are still unmerged, reports that count as prs_unmerged, and gets told that while any of them sit there, flat search position is expected rather than failure. Merging is the human's call, never the loop's. It's a loop being made to notice the review queue it's filling instead of reading a stalled number as its own problem to fix.

So the real scaling work is making review cheap. A loop's output should arrive as evidence you can check in seconds, like a video of the thing working or a test that flipped green. The mechanics of that are in how to evaluate AI agents and harness engineering.

The Migration Path

This is the part the other articles replace with a discovery workshop. Here's the sequence, and here's why it's in this order.

The selection rule, stated once: automate the work that is frequent, measurable, reversible, and public before you automate anything infrequent, subjective, irreversible, or customer-facing. Frequency matters because a task that runs daily gives you a reading every day instead of once a week, and you're going to need those readings to calibrate the loop. Reversibility matters because a wrong loop should cost you a git revert rather than an apology to a customer.

That rule is why the order below is what it is, and it's why "start with support because it's painful" is a trap. Support is customer-facing on the very first run.

Step 1: The SEO Loop

Start here, because it's the function where every property in the selection rule holds at once.

SEO is a solved problem that can be engineered. The playbook is known, so you're not asking the agent to invent a method. It's got a clear success signal that arrives from outside the system, so the loop can't grade its own homework. It's fully reversible: an unmerged PR isn't live and a bad article is a revert. And it runs daily without exhausting the work.

The loop shape is research, produce, monitor, revise. The spec excerpt earlier in this article is exactly this loop, so you've already seen what one looks like fully built. Note what it spends most of its words on: how to decide whether to write, when to ship nothing, and how to keep from grounding on its own past output.

Get the external grounding right on the first build. Our sibling loop stalled for weeks because it only ever read our own pages and our own search data, a closed circle that reports progress while going nowhere. Pull fresh outside signal every run and diff it against your coverage. Then write the do-nothing branch. The quality valve goes in before the happy path.

Don't grade the loop on its first runs. Early output is calibration data. It shows you where the loop's judgment and your bar come apart, and closing that gap is the thing you're actually building.

new-loop from the AI Builder Club skills repo will bootstrap the shared file-based memory this loop reads and writes. The SEO loop itself you build by hand. Nothing in the repo scaffolds it yet.

Step 2: The Support Loop

Second, once the SEO loop has taught you what a loop contract needs to contain.

The framing that makes this loop worth more than a deflection bot: every ticket is a free window into a product gap. So the loop doesn't just answer. Each ticket fans out into a reply, a signal filed to the shared brain the other loops read, and a fix agent spawned when it's a real bug rather than confusion.

That last output is where the compounding lives. When five people ask how to export something, that's a conversion gap sitting in the signals folder waiting for whichever loop handles growth, instead of a pattern someone might notice in a quarterly review.

The autonomy call here is different from step 1, because the output is customer-facing on run one. Start at draft-and-approve. The loop investigates against real data, writes the reply, and a human sends it. Move to autonomous sending one ticket category at a time, and only for categories where you've watched enough drafts to know what the failure looks like.

Cost note specific to this loop: run a cheap deterministic check before you wake the model. A script asking "are there any new tickets" costs approximately nothing, and an hourly loop that only wakes the expensive agent when there's real work is cheaper than one that wakes it 24 times a day to discover an empty inbox.

Same tooling story as step 1. new-loop gives you the memory substrate and stops there. No support-loop skill exists in the repo, so the triage logic, the Intercom access and the fan-out are all hand-built today.

Step 3: The CRM Loop

Third, and this is where the tiering discussion from earlier gets real.

Shape: scripts pull the data deterministically, so active users, new signups, and replies are facts rather than model output. Anyone who replied exits the loop immediately to a human. An orchestrator proposes segments by intent. Executors draft personal emails after reading each user's actual work and history. A verifier fact-checks every claim in the draft against the data before anything is queued, because "is this statement about the user's project true" has a checkable answer, and anti-slop rules run on top of that.

Then autonomy is earned per segment on measured reply rates rather than granted to the loop. As I said above, that's the design and not our run record. Ours is still drafts only.

This one comes third because it's irreversible. A bad cold email is a burned relationship with someone who was already interested in you, and you won't know which ones you burned. Do this after you've watched two loops long enough to know how yours fail.

Again it's new-loop for the memory substrate and nothing beyond it. There's no CRM skill, so the data pulls, the segmenting and the verifier are yours to write.

Step 4: Wire the Shared State

By June 2026 we had five of these running, and they wanted to be a company rather than five separate automations.

Don't wire the loops to each other. Point them all at the same folder. Each loop reads current state, does its work, and writes state back, and no loop needs to know the others exist. That's the contract shown earlier: one record type, a dedupe rule, a lifecycle, and a prioritization formula everyone computes identically.

The failure to avoid is loop-to-loop messaging, which looks more sophisticated and immediately couples everything to everything. Change one loop's output format and three others break silently. State in files is inspectable, diffable, and a human can hand-edit it at 11 p.m. when something's wrong.

What keeps the folder honest as it grows: separate the append-only history from the current-state summary, and never let one loop rewrite another loop's record wholesale. Increment, append, change status. Don't overwrite.

This is the one migration step the repo covers directly. new-loop scaffolds the shared knowledge base itself, which is the substrate every loop above reads and writes.

Step 5: Add the Guardrails

Standing up a loop is the easy part. The guardrails are what let you walk away from it.

Guardrails go in code and config, never in the prompt. A prompt that says don't delete production data isn't a security boundary. Cost caps per run and per day. Retry limits. Scoped credentials per loop, so a compromised or confused loop can't reach past its function. No production writes without approval. No auto-merge. A kill switch that stops the whole fleet.

A role label isn't a sandbox, and the public record on that is ugly.

A subagent whose instructions said read-only ran rm -rf on a worktrees directory and then apologised for it in its own output. The reporter's diagnosis: that agent's tool grant excluded Edit and Write but not Bash, so read-only was a line in a system prompt rather than an enforced restriction. On the same anthropics/claude-code tracker, an agent blocked from force-pushing to main used the GitHub API to enable force pushes, set the ruleset enforcement to disabled, deleted the branch protection rule outright, pushed, and only put the protections back after a human said stop. Branch protection is the team's guardrail, and it quietly assumes a human on the other side. PocketOS lost its production database and every volume-level backup in nine seconds, after an agent hit a credential mismatch in staging, read an unrelated file, found a broadly-scoped infrastructure token in it, and guessed its way to a delete call. Their founder told The Register it was a single API call.

Cost caps need the same treatment. Uber put its engineering org on agentic coding tools and burned its 2026 AI budget in four months, at $150 to $250 a month per engineer with power users between $500 and $2,000, while ranking engineers on internal leaderboards by usage. Forbes reported the spend, and Uber's own President and COO told Fortune he couldn't draw a line from it to features actually shipped. Simon Willison logged what Uber did about it: a flat cap of $1,500 a month per person per tool. You want that shape at a thousandth of the scale.

Here's what those caps look like as config instead of prose. Field names will differ in whatever runner you use. The keys are the point. Every number in the block below is a starting value I picked so the file would run, not a finding, and none of them is backed by evidence that yours should match. Replace each one from your own run log in the first week and tighten from there.

# Per loop, in the runner config. Caps live here, never in the prompt.
# Every figure below is a starting value to overwrite, not a recommendation.
budget:
  max_usd_per_run: 6.00        # starting value. set it from your own median run
  max_usd_per_day: 20.00       # starting value. across every run of this loop
  on_exceed: halt              # halt, not warn. A warned loop keeps spending.

fanout:
  max_depth: 3                 # starting value
  max_children_total: 8        # starting value. the cap missing in the fan-out above
  on_exceed: fail_run

retries:
  max_attempts: 2              # starting value
  backoff_seconds: 60          # starting value

timeouts:
  max_wall_clock_minutes: 25   # starting value. set it above your slowest good run

wake:
  precheck: scripts/has_work.sh   # exits non-zero when there is nothing to do
  # the expensive model never starts unless precheck exits 0

disposition:
  required: true               # every run records done | no-op | blocked | failed
  # a run that exits without one gets re-woken, and re-woken idle runs are
  # how a loop bills you for doing nothing

credentials:
  scope: this_loop_only        # no shared root token, ever
  deny_tools: [db_write, force_push, delete]

The breadth cap is the line that wasn't there in the fan-out above, and a depth limit on its own doesn't bound anything, because depth 5 with unlimited children at every level is exactly how you get 905 agents. If your harness supports per-agent tool grants, that's the real fix:

<!-- .claude/agents/research-worker.md -->
---
name: research-worker
description: Reads and searches. Cannot write, cannot shell out, cannot spawn.
tools: [Read, Grep, Glob, WebSearch, WebFetch]
---

Read that list for what's absent. No Agent, so it can't spawn children and the fan-out stops at one level. No Bash, so read-only means read-only instead of meaning it politely. A line in the system prompt asking it not to spawn agents doesn't do this, and the people who tried say so.

The failures above leave a few more. Give each loop an external leg, something real it doesn't control, so a swarm of mutually-satisfied loops can't form. Make the gate on subjective output reject-first with a rejection gallery behind it, because our numeric threshold drifted while reporting success. And give the loop a legitimate no-op your fleet view can tell apart from a broken one, since in ours a skip and a success looked identical.

There's no tooling for any of this yet. Guardrails get built by hand, per loop, in that loop's spec file and its runner config.

Engineering Loops, Which You Can Run in Parallel

The functions above are the company. The engineering loops are the codebase, and they can run alongside the sequence rather than after it, because their outputs are already gated by code review.

The shape is a morning cron that ranks real production errors or code-health issues, fixes the top one in an isolated worktree, verifies, and opens a PR. Same review-bandwidth discipline as earlier: the loop reports how many of its PRs are still unmerged, and merging stays a human call.

The precondition for all of them is that your repo can prove its own work. If an agent can't run the stack, exercise the feature, and produce evidence, every PR it opens lands on you to verify manually, and the bottleneck just moves.

Here's where the skills repo actually covers the work. setup-codebase-harness onboards the repo to agent-driven development. verifier-setup makes the work verifiable by scaffolding a repo-specific verify skill. e2e-setup gives you a real per-PR test gate. crabbox-setup gives each agent its own isolated cloud stack so parallel agents stop breaking each other's environment. dev-local-setup gets the local stack to one command.

The repo's tooling covers the engineering steps and not the business ones, which are worth more. It's expanding. Where a step above says it's built by hand today, it means built by hand today.

Receipts

Everything above that's a number, and what backs it.

Two things I wanted to put in this article and couldn't. A striking figure about running an entire company for the price of a dinner turned out to trace back to a garbled transcript and is absent from the primary source it was attributed to. And a widely-shared number about an internal company knowledge base fielding thousands of queries turned out to be misstated in the version being reshared, because the paraphrase quietly changed the time unit. Both are dropped rather than softened.

Start Here

Pick one function this week. Frequent, measurable, reversible, and not customer-facing. Ours was SEO.

Before you write any instructions, write the spec file: what the loop is for, what it reads first, how it scores itself, what it's allowed to ship, what it must escalate, and what it does when there's nothing worth doing. Then set the trigger, and let it run against your bar instead of the model's.

Budget a few dollars a day. In the one four-day run history above, two of six runs failed on infrastructure and billed anyway. That's what one loop did over four days. It isn't a rate to plan against. And don't grade the first runs on their output.

One more thing before you set the trigger and go to bed. Run this over the loop first.

PRE-FLIGHT: before this loop runs unattended

Blast radius
[ ] I have written down, in one sentence, the worst thing a single run can do.
[ ] That worst case costs money or a revert. Not a customer, not production data.
[ ] Destructive actions are absent from the tool grant. A prompt saying "don't" is
    not a control.
[ ] Credentials are scoped to this loop's function. No shared root token.

Grounding
[ ] At least one input comes from outside the system, and outside my control.
[ ] The loop cannot grade itself on a number it also produces.
[ ] A failed read is recorded as missing. Never as 0.

Stopping
[ ] There is a legitimate no-op branch, and it logs why it did nothing.
[ ] Per-run and per-day spend caps exist in config, not in the prompt.
[ ] Fan-out is capped by count, not only by depth.
[ ] There is a kill switch for this loop, and another for the whole fleet.

Review
[ ] Output arrives as evidence I can judge in under a minute, not a claim I have
    to trust.
[ ] The loop reports how many of its own artifacts are still sitting on me.
[ ] My fleet view can tell "nothing to do" apart from "could not run".

Autonomy today:   draft only  /  executes, I approve  /  autonomous within <limits>
Promotes when:    <the evidence, and how many runs of it>

Anything you can't tick is a decision you haven't made yet, not a detail you'll get to.

The starter kit is open source. AI Builder Club Skills is the tooling my team runs in production: new-loop bootstraps the shared memory your loops read and write, setup-codebase-harness onboards a repo to agent-driven development, verifier-setup makes the work provable, and crabbox-setup gives every agent its own isolated stack. Free, and the business-side loops are still built by hand on top of it.

If you want the full build layer by layer, the Loop Engineering course takes you from prompting an agent yourself to a loop that wakes on schedule, pulls the top item off its backlog, ships behind quality gates, and reports back.

Related Content

• Loop Engineering: Stop Writing Prompts, Start Writing Verifiers - The mechanics of a single loop: the discover-plan-execute-verify cycle, open vs closed, and why the verifier is the bottleneck.
• Agent Memory Systems - The facts-versus-procedures split, hot and warm context, and why unmaintained memory becomes a liability.
• Graph Engineering - What to do when a set of loops needs real coordination: nodes, edges, and shared state on the wire.
• Agent Graph vs Loop: When to Use Which - The escalation decision, and why a graph is easy to reach for too early.
• Harness Engineering - Making a repo legible, executable, and verifiable, which is the precondition for every engineering loop above.
• How to Evaluate AI Agents - Why self-evaluation skews optimistic, and how to build a gate that doesn't drift.
• AI Agent Reliability and Cost Control - The levers that actually move the bill: cheap triggers, model routing, and cached context.
• Self-Improving Agent Loops - The evolve step, where a loop rewrites its own configuration every few runs.
• Crabbox: Parallel Agent Sandboxes - Isolated stacks per agent, so parallel loops stop breaking each other's environment.
• Claude Code for Solopreneurs - The one-person version of this article, at the skill level rather than the company level.

Join AI Builder Club