## All roads led to /goal

In the span of a few months, every major agentic coding tool independently converged on the exact same primitive: an autonomous loop that takes a goal and runs until it decides it's done.

- Claude Code shipped `/goal`.
- OpenAI Codex shipped `/goal`.
- Antigravity built its whole model around loops.
- GitHub Copilot shipped Routines and Automations.

Four teams, four codebases, four sets of incentives. One primitive. When Boris Cherny, the creator of Claude Code, describes how he works now, the line is telling:

> "He stopped writing code. He writes loops."

This isn't coincidence. When independent teams under competitive pressure land on the same abstraction, that's evidence of a genuine primitive, the way `map` and `reduce` were genuine primitives. The interesting question isn't why the convergence happened. It's what you do with it. Because if everyone has the loop, the loop itself is worth nothing. Episode 1 of Agents, Orchestrated is about where the actual value moved.

## What a loop actually is

"Run until done" is not a loop. It's a hope with a timeout. A well-formed loop has three parts, and I've found that naming them explicitly is the fastest way to spot a badly designed one.

**Outcome.** What success looks like. This is the goal state the agent is trying to reach, and the key word is state. Not a task ("refactor the auth module") but a verifiable endpoint ("all auth tests pass and the module exports the same public interface"). If you can't state the outcome as something checkable, you don't have a loop yet. You have a vibe.

**Proof.** How you know it's done. This is the verification step: tests pass, output matches spec, the diff is correct. This is where most loops fail, and it fails quietly. An agent that declares victory on its own say-so will declare victory whether or not the work is right. The proof has to be something the agent cannot generate by wanting it to be true.

**Guardrail.** What prevents runaway. The exit condition, the budget, or the human gate that stops the loop from spinning forever. Without it, a loop that can't reach its outcome doesn't stop. It burns tokens, mutates state, and retries until something external intervenes. The guardrail is what makes the failure mode boring instead of expensive.

Outcome, proof, guardrail. Every loop I've seen in production has all three. Every loop I've seen fail was missing at least one, usually the proof.

## Four kinds of loops

Not all loops are equal, and one framework made the whole space legible for me. Two axes define it: where the loop runs (in your session or in the cloud) and what gates its exit (a trigger or a verification).

That gives you four quadrants:

| | Gated by trigger | Gated by verification |
|---|---|---|
| **In-session** | Ad-hoc run | Goal-driven run |
| **Cloud** | Scheduled job | Autonomous agent |

**Ad-hoc run** (in-session, trigger-gated). The user starts it, the agent runs until timeout or budget, and it stops when you stop it. This is most agent usage today. It's useful, but the human is the verification layer, which means it doesn't scale past the human's attention.

**Goal-driven run** (in-session, verification-gated). The agent runs until proof of completion. This is `/goal`. The agent proposes it's done, the verification step checks, and the loop only exits on evidence. This is the loop you can audit, because the exit condition is inspectable after the fact.

**Scheduled job** (cloud, trigger-gated). Cron fires it, the agent runs for a fixed time, and there's no verification loop at all. This is where a lot of "autonomous agent" marketing quietly lives: a cron job wearing a trench coat.

**Autonomous agent** (cloud, verification-gated). Cloud-hosted, goal-driven, long-running. This is where agentic work is heading, and I'd argue it only works if the verification layer is solid. Everything else in that quadrant is a scheduled job that occasionally gets lucky.

The framework earns its keep because it separates two things people conflate: where the agent runs and why it stops. Autonomy questions are almost always "why does it stop" questions in disguise.

## The moat is verification, not autonomy

The convergence is exciting, and I understand why the demos focus on autonomy. But autonomy alone isn't a moat. Every lab has it now. Four tools shipping the same primitive in the same quarter is proof that the primitive is a commodity.

The moat is what happens inside the loop when it thinks it's done. A verification layer that catches bad output, rolls back mistakes, and produces an audit trail is the difference between a demo and a product. I work with financial institutions, and the first question is never "how autonomous is it." It's "show me why it did that," and the loop that can't answer isn't a capability, it's a liability.

That's the thesis of the whole episode, and honestly of the whole series: **the loop you can audit is the only one that ships.**

## What didn't make the LinkedIn post

The episode itself was built with the primitive it describes, and that part deserves the honest version.

EP 01 shipped as a roughly 58-second, 4:5 motion graphic with presenter voiceover, built with my explainer-video-studio skill and Claude Code's `/goal` primitive running against a written spec. Which means the loop's three parts were mine to design: the outcome was the spec, the proof was a still-frame verification pass that checked the rendered frames actually showed the locked captions, and the guardrail was me, watching the run.

Two honest notes. First, the proof step is the entire reason the video shipped. The naive loop happily produces an mp4 that exists and is wrong; only frame-level verification against the spec caught caption and timing drift. Second, this was an in-session, goal-driven run, not the autonomous cloud quadrant the framework points toward. I was the human gate. I'm not going to describe a supervised run as autonomy, because the gap between those two quadrants is exactly the verification layer this episode is about.

The spec, the loop setup, and the output are all in the repo, so you can check the claims against the artifact.

## Ship log

- **Format:** ~58s motion graphic, 4:5, presenter voiceover
- **Built with:** Claude Code `/goal` against a written spec
- **Pipeline:** explainer-video-studio skill
- **Renderer:** Remotion
- **Verification:** still-frame checks of rendered output against the locked spec
- **Repo:** [letmereviewyourcode/what-are-loops](https://github.com/letmereviewyourcode/what-are-loops)