How the Two Loops Run — And Where They Break

Both loops running on the substrate from last week — and, honestly, the four places they break. The finale of the AI-Native Startup Architecture series.

Andrej Karpathy has been tuning neural networks for about twenty years. He helped build the field. So when he wired up an agent to optimize the training of nanochat — his "best ChatGPT $100 can buy" — and let it run overnight, he expected it to teach him nothing. He'd already picked the good settings. He always picks the good settings.

He woke up to find the agent had run hundreds of experiments on a single GPU and found tunings he'd missed.

"I let auto research go for like overnight and it came back with tunings that I didn't see… I shouldn't be a bottleneck, I shouldn't be running these hyperparameter search optimizations, I shouldn't be looking at the results. There's objective criteria in this case. You just have to arrange it so that it can just go forever" (No Priors, March 2026).

Sit with that. One of the most capable practitioners alive looked at a closed-loop result that beat his own twenty years of intuition and concluded: I shouldn't be the bottleneck. That's the whole shift in one sentence. Once the loop runs, the founder's job stops being "do the work" and becomes "arrange the loop, and review the diff."

Over three articles, I built up to this. The axis: conventional companies run as open loops, AI-native ones as closed loops. The architecture: two loops — one that runs the business, one that improves the product — sharing a single substrate. The substrate: four kinds of files in a folder that an agent can read and write. The substrate is built. This is the piece where the loops actually run. And because I promised in Article 2 that I wouldn't sell this clean, it's also the piece where I show you exactly where they break.

The business loop, in motion

Let's use the repo from last week. Helpdesk Copilot: an assistant that answers customer questions from a company's own docs. Its substrate has `specs/`, `evidence/`, `decisions/`, `state/`, and two skills in `.claude/skills/`. Watch the business loop turn once.

Evidence lands. Forty support tickets come in this week and drop into `evidence/tickets/`. Raw, messy, real.

An agent reads it. The `triage-feedback` skill runs:

# .claude/skills/triage-feedback/SKILL.md
Read evidence/tickets/ from the last 7 days. Cluster the tickets by theme.
For any theme where the bot answered wrong, draft a decisions/ entry:
the gap, a proposed fix, and what to add to the eval set.
Do not act. Surface the draft for the founder to approve.

It clusters the forty tickets and notices that twelve are refund questions the bot got wrong — because the docs don't cover the new refund policy, so the bot guessed.

It drafts a decision — it does not act. The skill writes a proposed entry into `decisions/`: gap — refund-policy docs missing, bot is guessing; proposed — write the doc, add five refund questions to the eval set. It stops there and surfaces the draft.

The founder approves. You read the proposed decision. Two minutes, not a meeting. You approve it, sharpen it, or kill it. You are reviewing a diff, not redoing the analysis.

Action, and state updates. The doc gets written, the eval set grows by five questions, and `state/answer-accuracy.md` gets a new line. The next time tickets land, they land on a substrate that now knows about refunds.

That's one turn of the business loop, and notice what made it possible: the agent could only do any of it because the evidence, the decisions, and the state all live where it can read and write them. This is exactly Diana Hu's "queryable organization" — the company made legible to an agent. Strip the substrate out, and step two is impossible; the signal stays trapped in someone's inbox, and the loop never closes. Notice too where the human sits: at the edge, approving, not in the middle, routing every ticket by hand.