AI Education

The Karpathy Loop: How AI Agents Learned to Improve Themselves

700 experiments in 2 days. Zero humans involved. Here's what autoresearch, AgentHub, and Anthropic's swarm playbook actually mean - and why "graph engineering" is the next phase of AI automation.

12 min read
July 30, 2026
The Karpathy loop diagram showing an AI agent running autonomous experiments in a keep-or-revert cycle

On the night of March 7, 2026, Andrej Karpathy pushed a small project to GitHub and went to sleep. By morning, an AI agent had run dozens of machine learning experiments on its own - proposing changes, testing them, keeping the wins, discarding the losses, and committing everything to Git. No human touched the keyboard in between.

That project, autoresearch, went on to collect over 86,000 GitHub stars. Within days, Karpathy followed it with AgentHub - "GitHub for agents" - and within two months Anthropic shipped dynamic workflows that let Claude orchestrate up to 1,000 sub-agents at once. A widely-shared synthesis note now calls the whole progression "graph engineering."

We read the paper, verified every reference in it, and in this post we'll walk you through exactly what happened, what actually matters, and what it means for businesses that just want AI to do the work.

What Actually Happened: A 5-Month Timeline

Between December 2024 and July 2026, the way professionals work with AI went through three distinct phases. Here's the sequence of real events:

December 2024

Anthropic publishes "Building Effective Agents"

Erik Schluntz and Barry Zhang lay out five simple, composable workflow patterns - prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. The core advice: start simple, add complexity only when a simpler shape fails.

December 2025

The agentic inflection point

Karpathy (and many others) report a step change: coding agents stopped being helpful autocomplete and started producing large, correct chunks of work. Karpathy's own ratio flipped from writing ~80% of his code to delegating ~80% of it. He calls the disciplined version of this "agentic engineering."

March 2026

autoresearch launches - and breaks the internet

Karpathy releases a ~630-line autonomous research loop. An agent edits train.py, runs 5-minute experiments, and keeps or reverts changes based on a fixed metric. Roughly 700 experiments in two days produced ~20 retained optimizations and an ~11% training speedup - on a model Karpathy had hand-tuned for years. Shopify CEO Tobi Lütke reported 19% on an internal model.

March 2026

AgentHub: "GitHub is for humans. AgentHub is for agents."

Days later, Karpathy sketches the collaboration layer: one Go server, one SQLite database, one bare Git repo, and a message board. No main branch, no PRs, no merges - just a sprawling commit DAG that agent swarms traverse. He later took the repo private; it survives through community forks.

April 2026

Sequoia AI Ascent: vibe coding vs agentic engineering

Karpathy declares vibe coding already obsolete as a professional standard. Vibe coding raises the floor (anyone can build). Agentic engineering raises the ceiling (specs, diff review, eval loops, guardrails).

May 2026

Anthropic ships dynamic workflows

Claude Code can now write its own JavaScript orchestration scripts and spawn fresh-context sub-agents in parallel - up to 16 concurrent, 1,000 per run. The same month, Jarred Sumner uses them to port Bun's 535,496 lines of Zig to Rust in 11 days, passing 99.8% of the test suite.

July 2026

"Graph engineering" gets a name

An independently compiled synthesis note (not affiliated with Karpathy or Anthropic) ties it all together: loops → swarms → DAGs → knowledge graphs, arguing that the real bottleneck isn't the model - it's where memory and evaluation live.

The Pattern in One Line

Each step removed a human bottleneck: first the human writing the code, then the human running the experiments, then the human coordinating the agents. What never got removed: the human defining what "good" means.

Karpathy's Sequoia AI Ascent 2026 talk - the "agentic engineering" moment this post is built on.

How the Karpathy Loop Works (And Why It Works)

Autoresearch is almost offensively simple. Three files, one loop, no human:

prepare.py (locked)

Fixed data preparation and evaluation. The agent is not allowed to touch it - so it can't cheat by making the test easier.

train.py (editable)

The ~630-line experimental surface: model, optimizer, hyperparameters. This is the only thing the agent changes.

program.md (the boss)

Plain-English instructions: the metric, the rules, crash handling, commit/revert policy, when to escalate. Karpathy calls this "programming the program."

# The ratchet loop
LOOP FOREVER:
  1. Read current train.py + recent history
  2. Propose ONE motivated change
  3. Commit the candidate
  4. Train for ~5 minutes
  5. Measure val_bpb
  6. Crash? Inspect, fix, or revert
  7. Improved? Keep. Worse? Git reset.
  8. Record result. Never ask a human.

The model's intelligence is almost beside the point. The loop works because the environment was engineered for autonomy. Four conditions, and they're a checklist you can steal:

The output is verifiable

A number either improves or it doesn't. No taste, no debate, no "looks good to me."

Every action is reversible

Git reset returns to the last known-good state. Failed experiments cost nothing but time.

The feedback cycle is short

Five-minute runs mean hundreds of learning cycles per day instead of three.

The action space is bounded

One editable file. The agent can't wander off and break the world.

AgentHub: GitHub for Agents, Not Humans

One agent emulates one PhD student. Karpathy's next post said the goal is to emulate a research community - "asynchronously massively collaborative for agents, think SETI@home style." AgentHub was his sketch of that layer.

The design is radical because of what it deletes. Human Git assumes a few contributors, a canonical main branch, and that merging is the goal. Agent research inverts all of it: thousands of agents explore simultaneously, most results are never merged, and a failed experiment is still valuable evidence. So AgentHub has no main branch, no pull requests, no merge queue. The primary operation isn't "merge this into main" - it's "traverse the search graph."

The CLI is a graph interface

ah push

Push HEAD as a new node in the DAG

ah children <hash>

What was tried on top of this result?

ah leaves

Show the unexplored frontier

ah lineage <hash>

Trace the path that produced this outcome

ah diff <a> <b>

Compare any two experiments

ah log -agent X

What has this agent been doing?

Here's the insight the paper makes literal: the commit DAG is a knowledge graph. Commits are nodes. Parent links are edges. Each node carries the hypothesis, the code diff, the metric, the agent's identity, and the keep-or-discard verdict. Suddenly you can ask questions that are awkward in normal Git: Which retained result has the best metric under a memory limit? Which experiments descend from the batch-size change? Which leaves have no evaluation yet?

Reality check: AgentHub's own README warned "Work in progress. Just a sketch." Karpathy took the repo private within days of launch. The lesson is architectural, not a product you can download: when agents become numerous, single-main-branch thinking, human-paced review, and transcript-based memory are the first things that break.

Anthropic's Production Playbook

While Karpathy sketched the future, Anthropic shipped the hardened version in three layers:

1. Five workflow patterns (Dec 2024)

Prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. The enduring advice from "Building Effective Agents": find the simplest pattern that works, and only add structure when a simpler shape demonstrably fails.

2. Dynamic workflows (May 2026)

Instead of you writing the orchestration, Claude writes a JavaScript script for your task: spawn fresh-context sub-agents in parallel (16 concurrent, 1,000 cap), filter findings, have reviewer agents try to refute them, then synthesize one cited report. Real-world proof: Bun's 535,496 lines of Zig ported to Rust in 11 days, 99.8% of tests passing.

3. Knowledge graph cookbook

Turn unstructured documents into a queryable graph with nothing but prompts: Haiku extracts typed entities and relations against a Pydantic schema, Sonnet resolves duplicates by reasoning over descriptions ("Edwin Aldrin" = "Buzz Aldrin" - zero character overlap, caught anyway), NetworkX assembles the graph, and answers cite the exact edges used.

Notice the shift: the 2024 guide said you build the workflow. The 2026 feature says Claude builds the workflow. What didn't change is what the human still owns: the objective, the scope, the permissions, the verification policy, the budget, and the rollback rule.

The Paper's Big Idea: Graphs as Shared Memory

The synthesis note's central claim is worth quoting in spirit: the bottleneck is usually not the next model call - it's the placement of memory and evaluation. Each architecture in this story externalizes a different kind of memory:

ArchitectureWhat it remembers
A loopIteration & evaluation - what was tried, what scored what
A chainTask order - what happens after what
A swarmParallel search - many independent contexts at once
A commit DAGExperiment lineage - what descends from what
A knowledge graphShared facts & provenance - what's known, from which source

The catchphrase: "The agent forgets; the graph does not." A swarm of agents that each rebuild the world from scratch in every context window wastes everything they learn. Agents that read and write a shared, typed, provenance-tracked graph compound each other's work across sessions. That's the jump from agentic engineering (humans orchestrating agents) to graph engineering (agents sharing durable state).

The paper is equally clear about the dangers: metrics get gamed (a ratchet optimizes what it can see), entity resolution can catastrophically merge the wrong things, 1,000-agent runs burn money fast, and a knowledge graph is only as honest as its sources. Their closing test for any such system: every important output can be traced to an objective, a plan, an artifact, a source, a graph path, an evaluator decision, and a bounded execution record.

A Note on the Paper Itself

The document making these claims is an independently compiled study note - not by Karpathy or Anthropic. We verified its 12 references: the events are real and accurately described, with minor errors (it says Bun was ~750K lines; the actual figure is 535,496). The "graph engineering" framing is the compiler's synthesis - a good one, but an editorial conclusion, not gospel.

What This Means for Your Business

You don't need a GPU cluster or a commit DAG. But the discipline that made autoresearch work is exactly the discipline that separates businesses getting real ROI from AI from businesses getting demos. Strip it down and it's four rules:

Give AI a verifiable goal, not a vague wish

"Improve our SEO" is a wish. "Publish one optimized post per day and grow organic clicks month over month" is verifiable. Autoresearch worked because success was a number. Your AI initiatives need one too.

Keep actions reversible and supervised

Karpathy's agent could run wild because Git reset made every mistake free. Your AI employees should draft, stage, and log - with humans approving anything irreversible like sending money or publishing under your name.

Shorten the feedback cycle

Five-minute experiments beat monthly reviews. Daily reports, weekly metric checks, fast corrections - the businesses winning with AI iterate like the loop does.

Put memory outside the chat

If everything your AI knows lives in a conversation thread, you restart from zero every session. Persistent instructions, stored results, and a real knowledge base are the small-business version of the knowledge graph.

This is precisely how we build AI employees at Dooza: each one has a defined role with measurable outcomes (posts published, calls answered, leads followed up), operates inside bounded permissions, keeps a durable memory of your business, and reports what it did so you can verify it. It's the Karpathy loop philosophy - verifiable, reversible, bounded, recorded - packaged so you never touch a Git repo. See it in action on the Dooza Workforce platform, or read our guide on how to automate business processes with the same principles.

Get AI Employees That Actually Do the Work

Dooza gives you pre-built AI employees for email, social media, SEO, content, sales, and support - with measurable outcomes, human oversight, and persistent memory built in. From $49/month.

When to Use What: A Practical Decision Guide

The paper ends with a decision framework we've adapted for non-research teams. The golden rule: use the least architecture that solves the problem.

Your situationStart withWhy
Simple, low-risk questionA single AI callLowest cost and latency; no system needed
Output can be checked objectivelyA loop (generate → evaluate → revise)Repeated feedback measurably improves the artifact
Stable, predictable stepsA chain / fixed workflowTestable, boring, reliable - boring is good
Many independent units of workParallel agentsCuts wall-clock time; keep a clear reducer
Variable, decomposable tasksOrchestrator + workersDynamic specialization per subtask
Facts must survive across sessionsPersistent memory / knowledge graphTranscripts forget; stored state doesn't
You run a business, not a labManaged AI employees (Dooza)All of the above, productized - no infrastructure to build or secure

And three questions to ask before adding any complexity: Can success be verified? Can the actions be undone? Can the business afford the cost and latency? If any answer is no, fix that first - more agents will only scale the problem.

Conclusion: The Path From Loops to Graphs

In five months, the field went from "a human prompts an agent" to "an agent runs 700 unattended experiments overnight" to "swarms of agents coordinating through shared graphs." Karpathy's README ends with a deliberately cinematic vision of autonomous swarms running across compute megastructures. The near-term reality is less cinematic and more useful.

The durable lesson isn't "use more agents." It's that progress came from engineering the environment: verifiable metrics, reversible actions, short feedback loops, bounded permissions, and memory that lives outside the context window. Loops, swarms, DAGs, and knowledge graphs are just increasingly sophisticated ways of placing that memory and evaluation.

For most businesses, the winning move is to skip the infrastructure and apply the philosophy directly: pick work with measurable outcomes, give it to AI employees that operate inside guardrails, and verify results on a short cycle. That's the Karpathy loop, productized - and it's available today, no GPU required.

Frequently Asked Questions

What is the Karpathy loop?

The Karpathy loop is the autonomous experimentation pattern behind Andrej Karpathy's autoresearch project. An AI agent edits a small training program, runs a 5-minute experiment, measures a fixed metric (val_bpb), keeps the change if the number improves, and reverts it if not. Over two days it ran about 700 experiments and kept roughly 20 real optimizations, with no human in the loop.

What is autoresearch?

Autoresearch is Karpathy's open-source project from March 2026: roughly 630 lines of Python where an AI coding agent runs ML experiments overnight on a single GPU. It gained over 86,000 GitHub stars because the pattern is simple and reproducible: a verifiable metric, reversible Git commits, short feedback cycles, and a bounded environment.

What is AgentHub?

AgentHub was Karpathy's follow-up experiment, described as "GitHub is for humans. AgentHub is for agents." It replaced branches, pull requests, and merges with a sprawling commit DAG plus a message board so swarms of AI agents could coordinate research. It was explicitly a sketch, and Karpathy later took the repository private.

What are Anthropic's dynamic workflows?

Dynamic workflows are a Claude Code feature (launched May 2026) where Claude writes a JavaScript orchestration script that spawns fresh-context sub-agents in parallel - up to 16 concurrent and 1,000 per run. Jarred Sumner used them to port Bun's 535,496 lines of Zig to Rust in 11 days with 99.8% of tests passing.

What is graph engineering?

Graph engineering is the idea that multi-agent systems need durable shared memory: agents read and write typed entities, claims, and relations with provenance in a knowledge graph instead of stuffing every transcript into a context window. The context window forgets; the graph does not.

Does my small business need agent swarms and knowledge graphs?

Probably not yet. The practical takeaway is the underlying discipline: give AI a verifiable goal, keep actions reversible, and store results outside the chat. A managed AI employee platform like Dooza applies exactly this - measurable tasks, human oversight, and persistent memory - without you building any infrastructure.

Related Articles

AI Agents vs Agentic AI — What Nobody Tells You [2026]
AI Education

AI Agents vs Agentic AI — What Nobody Tells You [2026]

Confused by the jargon? We break down the differences between Generative AI, AI Agents, and Agentic AI in simple terms.

10 min read
Read
How to Build a 20X Company: The Playbook Any Business Can Follow
AI Education

How to Build a 20X Company: The Playbook Any Business Can Follow

Y Combinator companies are using AI to do the work of 20 people with teams of 4. Here's how any business can follow the same playbook — no engineers required.

14 min read
Read

Ready to scale your business?

Join thousands of companies using Workforce to automate their work. Get started for free today.

No credit card required · 7-day money-back guarantee · Cancel anytime