Mervin Praison

Context graphs are the enterprise layer Jaya Gupta and Ashu Garg (Foundation Capital) argue will define the next trillion-dollar software wave — not another model, but a living record of decision traces: who approved what, under which policy, with which precedent, and why it was allowed. Gupta’s X Article (23 Dec 2025, 5.2M+ views) reframes the shift: systems of record capture what happened; context graphs capture why.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph LR
  subgraph SOR[Systems of record]
    CRM[CRM current state]
    ERP[ERP ledger]
    WH[Warehouse snapshots]
  end
  subgraph CG[Context graph]
    DT[Decision traces]
    POL[Policies + exceptions]
    PRE[Precedent links]
  end
  AGT[Agent orchestration] -->|reads| SOR
  AGT -->|emits at commit time| DT
  DT --> POL
  DT --> PRE
  DT -->|searchable why| AGT

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class AGT agent
  class DT,POL,PRE hook
  class SOR decision

Rules vs decision traces

Agents need both: rules for defaults, traces for organisational memory. Without traces, every exception is re-learned from scratch in Slack every quarter.

What systems of record never captured

Context graph in practice — renewal discount

Foundation Capital’s worked example: a renewal agent proposes 20% discount. Policy caps renewals at 10% unless a service-impact exception is approved. The agent pulls three SEV-1 incidents from PagerDuty, an open “cancel unless fixed” escalation in Zendesk, and a prior renewal thread where a VP approved a similar exception. Finance approves. The CRM stores one fact: 20% discount.

• With traces — full replay: inputs, policy version, exception route, approver, precedent link
• Without traces — auditors and future agents see only the outcome
• Compounding — next similar renewal searches precedent instead of re-debating in Slack

Context graph vs knowledge graph

Why incumbents struggle to own the layer

Capturing decision traces requires being in the write path at decision time — not bolting governance onto exports after the fact.

Three startup paths

Observability complements the stack — Arize positioned as Datadog-for-agent-decisions: monitor, debug, and evaluate agent behaviour as traces accumulate.

Signals for where to build

• High headcount — 50+ people routing tickets, triaging, reconciling manually
• Exception-heavy decisions — deal desks, underwriting, compliance, escalations where “it depends” is honest
• Glue functions — RevOps, DevOps, SecOps exist because no single SoR owns cross-functional workflow

One month in — what resonated and what pushed back

Foundation Capital’s January 2026 follow-up reports Fortune 500 CIO inbound, portfolio builds (Maximor, PlayerZero, Tessera, Tonkean, Regie), and broad founder agreement: decision traces compound while models commoditise.

Human-in-the-loop path to autonomy

Context graphs do not require full autonomy on day one. Start with agent proposes → gathers context → routes approval → records trace. As similar cases repeat, more of the path automates because the system holds searchable precedent. Even when a human makes the final call, the graph grows if inputs, approval, and rationale are captured — not left to die in Slack.

Performance summary

References

• Jaya Gupta — X Article launch post
• AI’s trillion-dollar opportunity: Context graphs — Foundation Capital
• Context graphs, one month in — Foundation Capital
• Context Graph vs Knowledge Graph — Atlan

Most developers still prompt coding agents one task at a time — and become the bottleneck. Daniel Moka argues the shift is agentic loops: bounded systems that discover, plan, execute, verify, and iterate until a hard gate passes, while you own the rules on disk. Average developers write prompts for agents; great developers design loops that prompt agents.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  G[Goal + RULES.md on disk] --> D[Discover]
  D --> P[Plan]
  P --> E[Execute in worktree]
  E --> V[Verifier agent]
  V --> Q{Quality gate tests lint CI}
  Q -->|pass| S[Ship PR notify]
  Q -->|fail| R[Append lesson to RULES.md]
  R --> D

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class D,P,E,V agent
  class G,R hook
  class Q decision

Eight tips from the post (expanded)

Open vs closed loops

Moka’s Loop Engineering 101 article (12 June 2026) frames the closed loop as the one that improves: each pass feeds the next, so the loop you run a month from now is sharper than day one.

Six building blocks of a closed loop

Single agent vs fleet

Closed loop in practice — analytics watcher

• Watcher polls analytics every five minutes; spikes wake the loop
• Loop reproduces bug as a failing integration test
• Maker fixes in a fresh worktree until test passes
• Checker runs full suite
• Gate: green → open PR + Slack ping; red → retry with reason
• Unfixable → leave reproduced test + tag human
• Preventable mistake → human adds rule to RULES.md

# Pseudocode shape (from Loop Engineering 101)
goal, rules = load_from_disk()
while True:
    result = maker.execute(goal, rules)
    verdict = checker.verify(result)      # separate agent / context
    if quality_gate_passes(verdict):      # tests, lint, CI — not LLM opinion
        ship(result)
        break
    rules = human_or_draft_rule(verdict.failure_reason, rules)

/goal in Claude Code vs Codex Goals

# Claude Code v2.1.139+
/goal all tests in test/auth pass and the lint step is clean

Protect the gate — lessons from comments

LinkedIn discussion on Moka’s post (26 comments, 263+ reactions) sharpened several guardrails:

Loop-ready checklist

From operator to engineer

Moka’s closing frame matches the broader loop-engineering movement (Steinberger, Cherny): you replace yourself as the thing that prompts the agent. You step in at decision points — approving rules, merging PRs, escalating unfixable failures — while the loop decomposes, executes, gates, and learns. Pragmatic middle path: loop what repeats and checks; prompt by hand for the rest.

Performance summary

References

• Daniel Moka — Most developers don’t use agentic loops (LinkedIn)
• Loop Engineering 101 — Daniel Moka
• Loop Engineering on mer.vin — expanded harness + factory patterns

A GitHub repository with one markdown file and zero lines of code now has more stars than most open-source frameworks — because it encodes what every developer already knows but AI coding agents keep ignoring. Claude Skills turn that frustration into a reusable behavioural contract: write once, load automatically, compound across every session.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph LR
  P[Repeated prompts] -->|every session| A[Agent]
  S[SKILL.md or CLAUDE.md] -->|startup metadata| A
  A -->|task match| L[Load full instructions]
  L --> W[Workflow scripts assets]
  W --> O[Specialised output]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class A agent
  class S,L,W hook
  class P decision

What actually went viral

In January 2026, Andrej Karpathy posted publicly about frustrations with AI coding agents — silent assumptions, over-engineering, scope creep. Within 48 hours, developer Forrest Chang distilled those observations into a single CLAUDE.md file and pushed it to GitHub as multica-ai/andrej-karpathy-skills.

The star count signals widespread frustration more than technical sophistication — but the adoption pattern is real. A text file compressed a workflow problem into something installable in one move.

The four rules inside CLAUDE.md

# Install the viral file into your project root
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

# Claude Code plugin path (community)
/plugin install andrej-karpathy-skills@karpathy-skills

CLAUDE.md vs SKILL.md — same idea, different harness

Anthropic launched Agent Skills on 16 October 2025. The official anthropics/skills repository now holds ~151,000 stars — production examples for PDF, Word, Excel, frontend design, MCP builder, and more. On 18 December 2025, Anthropic published Skills as a cross-platform open standard adopted by GitHub Copilot, VS Code, Cursor, Gemini CLI, OpenAI Codex, and dozens of other clients.

How progressive disclosure keeps context lean

• Level 1 — name + description preloaded into system prompt at startup
• Level 2 — full SKILL.md body read when Claude judges the skill relevant
• Level 3+ — bundled reference.md, scripts, templates loaded only when needed

Agents with filesystem access do not need the entire skill in context upfront — the bundled context can grow effectively unbounded while token use stays scoped to the task.

Skills worth installing now

The frontend-design skill explicitly targets distributional convergence — the statistical-average UI look (cream backgrounds, terracotta accents, near-black + acid green). It forces deliberate aesthetic choices before any component code ships.

Three ways to install

---
name: my-writing-voice
description: Use whenever I ask you to write emails, posts, or articles. Match my voice below.
---

# My Writing Voice
- Short sentences. One idea at a time.
- Direct — no filler like "it's worth noting".
- Contractions fine. Sounds human.
- Vocabulary: [your words] | Tone: [yours]

Skills vs MCP — complementary, not competing

Simon Willison and others framed Skills as potentially bigger infrastructure than MCP alone for workflow knowledge — procedural “how we do things here” vs MCP’s tool connectivity layer. Anthropic’s own engineering post positions Skills as teaching complex workflows that involve external tools, not replacing MCP servers. Skills encode behaviour; MCP exposes live systems.

Why the ecosystem is self-sustaining

• Low barrier — functioning skills can be 20–100 lines; no code required
• Cross-model portability — same SKILL.md format works in Cursor, Gemini CLI, Codex CLI
• Non-developer contributors — PMs, marketers, writers publishing workflow knowledge
• Community scale — repos with 100+ skills across 15+ professions (May 2026 estimates)
• Viral mechanics — tiny, legible, free to adopt, star count as social proof

Honest limits

Performance summary

References

• A GitHub Repo With One File Just Hit 144,000 Stars — Mike Written
• multica-ai/andrej-karpathy-skills
• Equipping agents for the real world with Agent Skills — Anthropic
• anthropics/skills
• agentskills.io — open standard

Agent Experience (AX) is the design discipline for working with autonomous agents across days, tools, and artifacts — not the polish of a chat sidebar. When an agent owns an issue for hours, opens a pull request, and answers review comments while you switch tasks, the question stops being “was the prompt pleasant?” and becomes “can I trust, audit, and resume this collaboration?”

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  U[Traditional UX] --> AU[Agent UX]
  AU --> AX[Agent Experience AX]
  U -->|reactive screens| Q1["Can I use this product?"]
  AU -->|chat + control| Q2["Can I interact with this agent?"]
  AX -->|relationship over time| Q3["Can I work with this agent over days?"]

  AX --> A1[Artifacts issues PRs sessions]
  AX --> A2[Parallel workstreams]
  AX --> A3[Audit trail chronicle]
  AX --> A4[Accountability merge policy]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class U,AU agent
  class AX hook
  class Q1,Q2,Q3 decision

UX, Agent UX, and AX — three different design problems

The shift is subtle but decisive. UX optimises interactions. Agent UX optimises conversations. AX optimises collaboration — relationship design once agents act asynchronously, maintain context, and own portions of work. Microsoft’s Agent UX principles (Space, Time, Core) address individual agents; AX extends that lens to multi-session, multi-artifact, multi-agent coordination.

Why AX matters now

GitHub’s rationale for the Copilot desktop app (June 2026) states the bottleneck plainly: agentic development made coding faster but created disjointed workflows, scattered context, and more time reviewing agent-generated code. Internal enablement language matches — once agents generate code quickly, the hard part is managing work coherently across branches, workspaces, validation, review, CI, and merge.

• Not a model problem — coherence is an experience-design problem
• Async by default — agents continue when the human looks away
• Review compounds — more PRs from agents means more judgment surface
• Beyond dev tools — any product embedding autonomous agents faces the same delegation question

GitHub reports commits nearly doubled year over year to 1.4 billion per month, with 2 billion Actions minutes per week — agentic workflows are already scaling platform load, not just individual productivity.

Six AX shifts in the GitHub Copilot app

Valentina Alto’s walkthrough of a loyalty-points expiry feature in an e-commerce codebase illustrates AX through GitHub’s agent-native desktop app (technical preview, Build 2026). The feature is incidental; the experience pattern is the lesson.

AX primitives GitHub ships today

Microsoft Agent UX principles mapped to AX

Microsoft Design’s Agent UX framework (Space · Time · Core) predates the AX label but overlaps where agents persist:

Chat vs canvas — where AX lives

GitHub’s Build announcement draws a line that defines modern AX tooling: chat is for instruction and ambiguity; canvases are where intent becomes inspectable work. A long chat scroll of decisions and corrections fails once an agent runs for hours. Canvases — plans, diffs, terminals, browser sessions — let humans edit, reorder, approve, or redirect on the same surface the agent updates.

# Session modes (GitHub Copilot app docs)
Interactive  — agent suggests; waits for input
Plan         — agent plans first; executes after approval
Autopilot    — agent writes, tests, iterates without waiting

# Continuity across surfaces
/chronicle standup   # summarise recent app + CLI sessions

AX design checklist

Open horizon — unified work surfaces

Alto’s closing question: will AX converge into a single work surface across development, architecture, marketing, and operations — where work, agents, and decisions are visible end to end? John Maeda’s 2026 Design in Tech framing pushes the same direction: designers move from shaping screens to shaping behaviours, feedback loops, and trust in agentic systems. The risk in a unified surface is not capability but clarity and accountability as role boundaries blur.

Performance summary

References

• Introducing Agent Experience (AX) — Valentina Alto
• GitHub Copilot app: The agent-native desktop experience
• Working with agent sessions in the GitHub Copilot app
• UX design for agents — Microsoft Design
• Principles of Mixed-Initiative User Interfaces (Horvitz, CHI ’99)

Claude Fable 5 is not a longer chat window — it is a Mythos-class orchestrator built for days-long agent runs, sub-agent delegation, and vision self-checks. Most teams still prompt it for five minutes and close the tab. The fix is a self-improving system: four compound layers, three orchestration primitives, and memory that sharpens every run while the model weights stay fixed.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph BT
  P[Layer 1 Primitives] --> O[Layer 2 Orchestration]
  O --> M[Layer 3 Memory]
  M --> S[Layer 4 Self-improvement]
  S -->|distill rules| M
  M -->|read at start| P
  O -->|/goal Outcomes routines| P

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff

  class P agent
  class O,M,S hook

What Fable 5 actually is

Anthropic launched Fable 5 on 9 June 2026 as the first publicly available Mythos-class model — one tier above Opus, with built-in safety classifiers (Mythos 5 without classifiers remains Glasswing-only). Headline capabilities from launch docs:

• Days-long sessions in Claude Code or Claude Managed Agents (CMA)
• Self-verification — tests, vision checks, rule distillation
• Multi-stage knowledge work with minimal oversight
• Pricing — $10/M input, $50/M output (~5× Opus 4.8); 90% prompt-cache discount on input

Critical distinction: self-improving ≠ self-learning. No production public model updates its own weights from your sessions. Self-improving means the system compounds — STATE files, Skills, eval loops — while Fable 5 stays the same orchestrator.

The four-layer compound stack

14 steps in three tiers

Model routing: who runs what

Production pattern: Fable orchestrator + Sonnet workers + Haiku graders + Opus fallback. Reserve Mythos-tier pricing for orchestration — not lint fixes.

/goal vs Outcomes — same shape, different harness

# Claude Code — v2.1.139+
/goal all tests in test/auth pass and the lint step is clean

# Non-interactive
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Step 6: verifier sub-agent beats self-critique

Anthropic engineers report: “We’ve found that a verifier sub-agent tends to outperform self-critique with Fable 5.” In the Parameter Golf experiment (8×H100, up to 8 hours), Fable 5 with an independent verifier achieved roughly 6× more pipeline improvement than Opus 4.7 — making structural architecture bets and pushing through quantization regressions instead of repeating scalar tweaks.

Dynamic Workflows, worktrees, and Routines

Dynamic Workflows (Claude Code, 28 May 2026) let the model write a custom JS harness with agent(), parallel(), and pipeline(). Three patterns matter for self-improving systems:

• Fan-out-and-synthesize — parallel agents, clean context per piece
• Adversarial verification — independent verifier per maker
• Loop until done — pair with /goal for hard stop conditions

Worktrees are mandatory when Fable 5 spawns parallel sub-agents — maker in worktree A, verifier read-only in B, or one worktree per structural experiment.

/schedule daily at 7am, use Fable 5 in CMA
Goal: Re-run yesterday's eval suite against the latest skills.
Any test that newly passes → distill the pattern into the skill.
Any test that newly fails → investigate, document in STATE.md.
Post the digest to #engineering. /goal don't stop until digest is
posted and STATE.md is updated.

Routines (research preview since 14 April 2026) run saved configs on Anthropic cloud — schedule, API, or GitHub event triggers — so laptop-off compounding is possible. Parameter Golf-class runs need CMA, not a closed laptop.

Memory: five stages and STATE.md

# STATE.md — five sections matching the progression
## Verified facts      # stage 3
## General rules        # stage 4
## Open failures        # stages 1–2
## Lessons learned      # stage 4 distillations
## Last session         # stage 5 resume pointer

Operational rules: write before walking away (every session ends with a STATE update) and read at session start (without this, Fable 5 degrades to Sonnet-class memory behaviour). Skills in ~/.claude/skills/ carry procedural memory across projects — every confirmed lesson goes into the Skill, not just chat.

Vision verify and the Mythos safety boundary

For UI work: maker renders screenshot → verifier (vision) compares against goal, design tokens, and prior screenshot in STATE.md → loop on mismatch. Same pattern as Parameter Golf reading training charts visually.

Fable 5 classifiers decline in cybersecurity vulnerability research, biology, chemistry, and model distillation — then fall back to Opus 4.8. Design Skills to surface this explicitly; silent classifier blocks look like real errors until you debug them.

Common mistakes that waste Fable 5

Performance summary

Google Colab CLI turns Colab from a browser-only notebook into a programmable remote runtime you drive from your terminal — provision a T4 or A100, pipe a local .py file to a Jupyter kernel in the cloud, pull checkpoints back, and tear the VM down, without opening a tab. Google shipped it in June 2026 as an agent-ready bridge between local dev machines and Colab compute.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph LR
  T[Local terminal] -->|colab new / exec| API[Colab assign API]
  API -->|runtime proxy token| VM[Remote Colab VM]
  VM --> K[Jupyter kernel]
  K --> GPU[GPU or TPU]
  VM -->|colab download| A[Local artifacts]
  API -->|keep-alive 60s| VM

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff

  class T,A agent
  class API,VM,K,GPU hook

What problem it solves

Before the CLI, Colab meant: open a notebook in Chrome, click Connect, upload files manually, and babysit the runtime. That breaks down for shell pipelines, CI-style jobs, and coding agents that only speak bash. The CLI exposes the same rented VMs through commands like colab new --gpu T4, colab exec -f train.py, and colab run --gpu T4 train.py — a one-shot provision → execute → teardown path.

Google’s launch post positions it for both humans and agents: any tool with terminal access (Claude Code, Codex, Antigravity, etc.) can provision accelerators, install packages with uv, run local scripts remotely, export replayable .ipynb logs, and download weights — without writing cloud provisioning code yourself.

How the architecture works

Important detail: colab exec -f script.py reads the file locally and sends source to the kernel — you do not need a separate upload step for execution. Use colab upload / colab download for datasets, checkpoints, and zips.

Install and authenticate

# Recommended
uv tool install google-colab-cli

# Or pip (requires Python 3.13+)
pip install google-colab-cli

# Quick smoke test
colab new
echo "print('Hello from Colab')" | colab exec
colab stop

Two auth layers matter:

• CLI → Colab control plane — --auth oauth2 (browser flow, token in ~/.config/colab-cli/token.json) or --auth adc (Application Default Credentials — preferred for agents).
• VM → GCP services — colab auth inside a session for BigQuery/GCS; separate from CLI login.

# Agent-friendly ADC setup (all required scopes)
gcloud auth application-default login \
  --scopes=openid,\
https://www.googleapis.com/auth/cloud-platform,\
https://www.googleapis.com/auth/userinfo.email,\
https://www.googleapis.com/auth/colaboratory

colab --auth=adc whoami
colab --auth=adc new -s my-job

colab new pre-flights scopes: if the colaboratory scope is missing, it unassigns the fresh VM and prints remediation — avoiding silent 403s mid-job.

Command map

GPU and TPU options

Accelerator access is subscription- and quota-gated. HTTP 400 on colab new --gpu X usually means no entitlement — fall back to T4 or CPU. Unrecognized --gpu values silently map to A100 in the client; spell GPU names exactly.

Built for coding agents

Google’s Gemma fine-tuning demo is the canonical agent pattern:

colab new --gpu T4
colab install transformers datasets peft trl bitsandbytes accelerate
colab exec -f finetune_run.py
colab download checkpoints/adapter ./adapter
colab log --output gemma_finetune_log.ipynb
colab stop

Agent-safe: new, stop, exec (piped/file), run, install, upload, download, log. Agent-unsafe (TTY): unpiped repl/console, auth, drivemount.

For parallel jobs, isolate state: colab --config /tmp/job-a.json new -s trainer-a. Always name sessions and call colab stop — idle VMs burn compute units even with keep-alive.

Shebang one-liners with colab run

#!/usr/bin/env -S colab run --gpu L4 --keep
import torch
print(torch.cuda.is_available(), torch.cuda.get_device_name(0))

chmod +x script.py && ./script.py provisions a fresh VM, runs the script with forwarded sys.argv, propagates exit codes, and tears down unless --keep is set. CLI status messages go to stderr; script stdout stays clean for piping.

Three workflows that cover most jobs

1. Training with checkpoint pull

colab new -s trainer --gpu A100
colab install -s trainer torch transformers
colab exec -s trainer -f train.py
colab download -s trainer checkpoints/model.bin ./model.bin
colab stop -s trainer

2. Local notebook on cloud kernel

colab new -s analysis
colab exec -s analysis -f report.ipynb   # writes report_output.ipynb locally
colab log -s analysis -o execution_log.md
colab stop -s analysis

3. Fire-and-forget GPU job

colab run --gpu T4 train.py --epochs 3 --lr 1e-4

Hybrid tip: colab url -s NAME --open attaches the browser UI to a CLI-provisioned VM — explore in the notebook, automate in the shell.

CLI vs browser-only Colab

Limits and footguns

Performance summary

Loop engineering means you stop being the person who types every prompt to a coding agent — and start designing a small system that discovers work, delegates it, checks it, remembers progress, and repeats. The leverage moves from prompt craft to loop design: six primitives that now ship inside tools like Claude Code and the Codex app instead of bespoke bash you maintain forever.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  subgraph Stack["Three layers"]
    H[Harness engineering] --> L[Loop engineering]
    L --> O[Orchestration layer]
  end
  H -->|one agent runtime| T[Tools memory sandbox]
  L -->|schedule + verify| P[Six primitives]
  O -->|fleet + PR lifecycle| R[Reactions state machine]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class H,L,O agent
  class T,P,R hook

Where the conversation landed in 2026

The shift is no longer niche. Boris Cherny, who leads Claude Code at Anthropic, described it on the Acquired podcast as: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” Peter Steinberger put the same idea on X: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Both are saying the human job moved up one floor — from typing each turn to designing feedback systems.

That floor has three names in practice. Harness engineering is the runtime around one agent (tools, memory, permissions). Loop engineering is the harness that runs on a schedule, spawns helpers, and feeds itself from disk. Orchestration is the layer above when you need fleets of agents across worktrees, PRs, and CI — with automatic routing of failures back to the right session.

The universal five-stage cycle

A prompt gives instructions for one turn. A loop gives a job: discover → plan → execute → verify → iterate until done. You set the goal; the loop runs itself.

Open loops vs closed loops

Closed loops need five ingredients on disk: goal (precise done), context (VISION.md, ARCHITECTURE.md, RULES.md), action (scoped tools), feedback (tests, lint, structured errors), and a stop condition (/goal text, Stop hook, or orchestrator brief). Without a quality gate, AI drifts; with one, it improves.

Single-agent loop vs fleet loop

What changed in agentic development

For roughly two years, “good AI coding” meant writing strong prompts and feeding enough context each turn. You typed, read, typed again — the agent was a power tool and you held the handle every step.

Loop engineering is the next layer: a recursive goal where you define purpose and done, and the system iterates until a verifiable condition holds. You design once; the loop pokes agents on a schedule or across turns. This sits one floor above agent harness engineering (the environment one agent runs in) and the factory model (the system that builds software) — same family of ideas, but the harness now runs on a timer, spawns helpers, and feeds itself from disk-based memory.

The six primitives every loop needs

The agent forgets; the repo does not. Long-running loops depend on external state — not context window — to remember what was tried, what passed, and what is next. Common context files beyond SKILL.md: VISION.md (what success looks like), ARCHITECTURE.md (stack and layout), RULES.md (forbidden actions), GUARDRAILS.md (always-on checklists), and AGENTS.md (repo map for agents).

Codex app vs Claude Code — same shape, different names

Once you see the shared shape, the debate shifts from “which tool” to “which loop design still works in either seat.”

1. Automations — the heartbeat

Automations turn a one-off agent run into a loop. In the Codex app you configure project, prompt, schedule, and environment (local checkout or background worktree). Runs with findings land in a Triage inbox; empty runs archive themselves. Internal uses include daily issue triage, CI failure summaries, commit briefings, and regression hunts. Automations can call $skill-name so recurring logic stays maintainable.

Claude Code reaches the same outcome via /loop (interval reruns), cron scheduling, lifecycle hooks, Desktop scheduled tasks (persistent while app is open), Cloud Routines (runs when laptop is closed), or GitHub Actions for headless runs.

Interactive pick: /goal vs /loop vs Stop hooks

# Claude Code — run until tests and lint are clean (v2.1.139+)
/goal all tests in test/auth pass and the lint step is clean

# Check spend and evaluator reasoning
/goal

# Stop early
/goal clear

# Headless single invocation
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

# Codex — long-running performance goal (cookbook pattern)
/goal Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark,
while keeping the correctness suite green. If blocked, stop with evidence.

/goal on Claude Code starts a turn immediately; after each turn Haiku (by default) judges yes/no from the transcript — it does not run tools. Codex /goal is thread-scoped with explicit budget accounting and pause/resume. Pair either with auto mode so each turn skips per-tool confirmations.

2. Worktrees — parallel without collisions

Two agents editing the same file is the same failure mode as two engineers on one branch without coordination. A git worktree is a separate working directory on its own branch, sharing history but not files. Codex threads use worktrees natively; Claude Code offers --worktree sessions and isolation: worktree on subagents that clean up after themselves.

Worktrees remove mechanical collision; your review bandwidth still caps how many parallel agents you can actually supervise.

3. Skills — stop paying intent debt every session

Agents start cold. Every missing convention becomes a confident guess — intent debt. A skill is intent written outside the chat: a folder with SKILL.md, optional scripts, references, and assets. Both Codex and Claude Code load skills when you invoke $name or when the task matches a tight, boring description (clever descriptions match too often).

# Example skill layout
my-project-skill/
  SKILL.md          # conventions, build steps, forbidden patterns
  scripts/
  references/

Skill vs plugin: the skill is the authoring format; a plugin bundles skills and connectors for teammates to install once.

4. Connectors — act in your real environment

MCP connectors let the loop read Linear/Jira, query databases, hit staging APIs, and post to Slack. That is the difference between “here is the fix” and “open the PR, link the ticket, ping the channel when CI is green.” Plugins package connectors with skills so onboarding is one install, not tribal memory.

Feedback signals that keep loops honest

Strongest systems stack multiple signal types: deterministic for reliability, visual/critic for judgment, human gates on high-stakes merges. Signals must route back automatically — full logs, diffs, scores — without you copy-pasting CI output each turn.

5. Sub-agents — maker vs checker

The model that wrote the code is too lenient grading itself. A second agent — different instructions, sometimes a different model — catches rationalised mistakes. Typical trio: explore, implement, verify against spec. In fleet setups, a validator agent reports truth without fixing — failures loop back to the builder.

# Codex — custom subagent (simplified .codex/agents/security-reviewer.toml)
name = "security-reviewer"
description = "Read-only security pass on diffs"
instructions = "Find auth, injection, and secret-leak risks. No edits."
model = "strong"
reasoning_effort = "high"

Sub-agents cost extra tokens (each runs its own model + tools). Spend them where a second opinion unlocks unattended runs — the only reason you can walk away from a loop.

Orchestration — when one loop is not enough

Single-session /goal loops solve “finish this migration without me re-prompting.” Fleet-scale work needs an orchestration layer: deterministic plumbing plus an orchestrator agent for judgment.

Open-source reference implementations like Agent Orchestrator (npm install -g @aoagents/ao) ship reactions engines, worktree isolation, and orchestrator prompts out of the box. The pattern: inner agents execute in bounded loops; outer orchestrator coordinates; environmental signals keep loops honest; you stay on vision and judgment.

Walkthrough: one morning triage loop

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
sequenceDiagram
  participant Auto as Morning automation
  participant Skill as Triage skill
  participant State as STATE.md
  participant WT as Worktree
  participant Maker as Fix sub-agent
  participant Check as Review sub-agent
  participant MCP as Connectors

  Auto->>Skill: Run on schedule
  Skill->>State: Write CI failures + issues
  loop Each actionable item
    Auto->>WT: Open isolated checkout
    WT->>Maker: Draft fix
    Maker->>Check: Submit diff
    Check-->>Maker: Approve or reject
    Maker->>MCP: Open PR + update ticket
  end
  Auto->>State: Log done / blocked for human inbox

• 06:00 — Automation fires; triage skill reads yesterday’s CI, open issues, recent commits.
• Findings — Written to STATE.md or a Linear board (memory outside the chat).
• Per item — New worktree → maker sub-agent drafts fix → checker sub-agent runs against project skills + tests.
• Ship — Connectors open PR and update tickets; blocked items land in your inbox.
• Tomorrow — State file tells the loop what was tried, passed, or still open.

You designed this once. You did not prompt each step — that is the whole point.

Prompt engineer vs loop engineer

Self-check: is your loop healthy?

What loops do not remove — three sharper risks

Verification stays human

An unattended loop is also an unattended mistake machine. Even with a verifier sub-agent, “done” is a claim, not proof. Ship code you confirmed works — especially when diff sizes balloon because agents touch more files than necessary.

Comprehension debt accelerates

The faster the loop ships code you did not write, the wider the gap between what exists and what you understand. Read the reasoning, skim the diff, trace the decision log — or the loop makes the debt grow faster, not slower.

Cognitive surrender

When automation feels smooth, it is tempting to stop having opinions. Loop design with judgement keeps you the engineer; loop design to avoid thinking is the same UI with opposite outcomes. Two teams can run identical loops — one moves faster on work they deeply understand; the other outsources understanding entirely. The loop cannot tell the difference. You can.

Parallel pattern: scheduled content factories

The same week loop engineering went mainstream for coding, creators published parallel “factory” playbooks for media. @0x_fokki’s X Article I Built an AI Animation Factory That Runs 24/7 is not a coding-agent harness — Claude is used as a scriptwriter, not a repo editor — but it shows the same design move: stop hand-driving each step, design a pipeline that runs on a schedule with human approval gates.

Fokki’s pipeline chains six tools end-to-end:

Claude → Midjourney → Runway → ElevenLabs → Suno → Make
script → frames → motion → voice → music → publish

One Make scenario runs Monday and Thursday at 08:00: pull scripts from Google Drive, batch Midjourney scene prompts, download frames, send dialogue to ElevenLabs, pair images with Runway motion clips, assemble in a CapCut template, upload to YouTube with generated metadata, clip a 30-second X preview, post Patreon early access, and ping Telegram on completion. A separate on-demand webhook turns client briefs into finished explainers in shared Drive — quoted turnaround ~6 hours after a one-time ~5-hour setup.

Four SKUs share the pipeline: animated story series (6–10 min), brand explainers (60–90 sec), motion comics, and children’s bedtime channels. The human job is narrow: pick the story, pick the style, approve the output — roughly four hours of direction for a “24/7” factory, per the author.

What transfers to coding loops

• Scheduled heartbeat — the factory does not wait for you to open a chat; neither should triage or CI-repair loops.
• Stage-specialised tools — one brain trying to script, illustrate, animate, and score is the creative version of one agent grading its own code.
• Performance direction in prompts — Fokki writes ElevenLabs stage direction (pauses, volume drops), not raw dialogue paste; coding loops need equally explicit done conditions in /goal text.
• Human gate on output — “approve the episode” maps to Triage inbox review and PR merge — optimise human time, do not remove judgment.
• Setup once, run indefinitely — the Make scenario is the media equivalent of wiring automations + skills once, then letting the loop compound.

Treat revenue figures in social factory posts as illustrative, not audited benchmarks. The architectural lesson is stable: factories — code or content — are designed loops with explicit stages, schedules, and gates. Coding loop engineering just demands harder oracles (tests, type checks, diffs) because “shipped” is easier to fake than “sounds convincing.”

Token economics and balance

Loops are not free — patterns diverge wildly if you are “token rich” vs “token poor.” Direct prompting still matters for ambiguity and architecture. Loops handle repetition; you handle judgement. The leverage point moved — it did not disappear.

Performance summary