Agentic Loops & Swarm is the New Moat

Everyone is building AI coding agents. Almost nobody is engineering their loops. That's the moat.

Andrew Ng said it plainly: "100% of my tasks are now done by AI agents. In 3-6 months, everyone will be using self-improving loops. No more prompting." Boris Cherny, the creator of Claude Code, went further: "You're not supposed to prompt Claude. You're supposed to build a system that prompts itself." Jensen Huang echoed the same thing on a different stage. Three of the most influential voices in AI, all converging on the same conclusion in the same week — the prompt era is over. The loop era has begun.

But here's what nobody is telling you: most teams building "agentic" workflows right now are doing it wrong. They're writing better prompts and calling it a loop. They're running a single model in a for-loop and calling it orchestration. They're duct-taping three agents together with markdown files and if/else statements and calling it a swarm. The teams that win won't have the smartest model. They'll have the best loop.

The Problem: Prompt Engineering Is a Dead End

Let me paint the picture. You're building a SaaS product — a Django backend with a Vue.js frontend, Celery workers, PostgreSQL, the standard stack. You've got 100+ backend files and 50+ frontend components. You ask Claude or GPT-5 to "find and remove dead code." It gives you a list. You review it. Half of it is wrong. You iterate. It gets better. You iterate again. Three hours later, you've removed some dead code and you're exhausted.

That's not an agent. That's a search engine with extra steps.

The single-prompt → single-output → manual-review cycle is the bottleneck. Not because the models aren't smart enough, they ARE. The bottleneck is the human in the middle, hand-holding every step, catching every hallucination, validating every output. You're not building an AI agent. You're building an AI assistant that needs a babysitter.

This is the 70% problem that Addy Osmani named: AI gets you 70% of the way there, and the last 30% takes 80% of the time. The code looks right. The tests pass. But then you hit production and discover the thing you almost deleted was actually live data. The model was confident. The model was wrong. And if you'd trusted it, you'd have shipped a bug.

The shift isn't from prompts to better prompts. It's from prompting to loop engineering.

What Changed: Why Loops, Why Now

Three things converged in 2026 to make agentic loops viable:

First, model costs cratered. Running a frontier model used to cost real money per request. Now you can run Claude, GPT-5, DeepSeek, and Gemini in the same workflow without blowing your budget. The economics of running 100 agents in parallel — what Anthropic engineers do internally — went from "enterprise only" to "any startup can afford it."

Second, model quality commoditized. The gap between the best model and the fifth-best model is now smaller than the gap between a good prompt and a great prompt. Maya Zehavi nailed it: "The marginal value of a single monolithic frontier model is compressing into a function of orchestration + cheap inference, not of owning the biggest weights." If your moat is "we use the best model," you don't have a moat.

Third, orchestration became the bottleneck. Right now, the hard problem isn't getting an AI to write code. It's getting multiple AI agents to verify each other's work, catch hallucinations, and reach a trustworthy conclusion without a human reviewing every line. The bottleneck moved from intelligence to coordination.

An agentic loop is a system where AI agents generate, evaluate, route, and remember — cycling until the output is verified, not just produced.

The canonical loop has four components:

1. Generator — produces the output (code analysis, bug fix, feature implementation)

2. Evaluator — checks the output against a verifiable goal

3. Router — sends failed outputs back with specific error context

4. Memory — persists what worked and what didn't across iterations

That's the loop. Generate → evaluate → route → remember. Repeat until verified.

The 3-Layer Agent Architecture

Here's the architecture we use, stripped of proprietary details but preserving the pattern that actually works.

Layer 1: The Team Lead. One orchestrator agent that receives the task, decomposes it into parallel sub-tasks, and delegates to specialists. It doesn't do the work. It assigns the work. Think of it as a tech lead who knows who to ping for what.

Layer 2: The Research Agents. A fleet of narrow specialists, each assigned a specific slice of the codebase. One checks backend imports. Another traces API endpoint usage. A third analyzes frontend component dependencies. Each agent has a narrow, testable scope. They run in parallel. They don't talk to each other — they report up.

Layer 3: The Review Agents. A second fleet that takes the research agents' outputs and independently verifies them. The research agent says "this function is dead." The review agent says "let me check that against production data." If they disagree, the orchestrator routes it back with context.

The review loop is the defining architectural pattern. Not the generation — the verification.

Why does this matter? Because LLMs lie. Not maliciously — structurally. They hallucinate imports, invent dependencies, and confidently assert things that are provably false. Sakana's Fugu research showed that multi-agent cross-verification achieves an 82% success rate on tasks where single-agent systems fail. When you add a third verification layer — triple-checking against production data, not just source code — you get almost zero false positives.

Almost Zero. Not "mostly accurate." Not "pretty good." ver close to Zero false positives.

The key insight: each agent doesn't need to be perfect. The system needs to be perfect. And systems achieve perfection through redundancy, not through any single components brilliance.

Case Study: Dead Code Removal at Scale

Let me walk you through a real implementation — using our SaaS product as the example, but stripping it down to the general methodology. This is a Django + Vue.js productivity tool with the expected scale: 100+ backend files, 50+ frontend components, Celery task queues, PostgreSQL.

The task: Remove dead code. Sounds simple. It's not.

Phase 1: Research (Parallel Exploration)

Twenty research agents fanned out across the codebase. Each one received a narrow assignment: "Analyze these 5 backend files for unused imports, unreachable functions, and unreferenced database fields." Another batch got: "Trace frontend component usage — which Vue components are never imported?"

Each agent ran independently. No shared context. No coordination. Just focused analysis on their assigned slice. They produced structured reports: file path, line number, what appears dead, confidence level.

Why parallel? Because sequential analysis is slow and error-prone. An agent analyzing file 47 after analyzing file 46 carries accumulated context that might be wrong. Fresh context, narrow scope, parallel execution — that's the pattern.

Phase 2: Review (Cross-Verification)

Twenty review agents received the research agents' reports and independently verified each finding. The research agent said process_task() in tasks.py was never called. The review agent searched the entire codebase for references, checked imports, traced call chains. If the review agent confirmed "dead," it went to the kill list. If it disagreed, the finding was flagged for human review.

This is where the magic happened. The review agents caught things the research agents missed — not because the research agents were wrong about the code, but because they were looking at the wrong layer.

Phase 3: Production Verification (The Discovery)

Here's the part that should keep you up at night.

After the research and review phases agreed on a list of dead code, we ran a final check: query the production database. We looked at what data actually existed, what tasks were actually running, what features users were actually using.

Multiple functions that looked 100% dead in source code were actively used in production.

Not because of direct imports or obvious call chains. Because of Celery task routing — tasks dispatched dynamically by string name. Because of Django admin actions registered through metaclasses. Because of Vue components loaded conditionally based on feature flags that lived in environment variables, not code.

The source code said "dead." Production said "very much alive." If we'd trusted the code analysis alone, we'd have deleted features that customers use daily.

This is the production loop — the third layer of verification that most "AI agent" tools skip entirely. They analyze code in isolation. They never touch the database. They never check the running system. And they ship bugs as a result.

The final score: 1,300+ lines of genuinely dead code removed across 49 files. Zero broken features. Zero production incidents. Because three layers of verification caught every false positive before it reached the kill list.

The Hard Truth: Most "AI Agent" Tools Are Scripts

Here's the uncomfortable part.

Most tools calling themselves "AI agents" right now are doing autocomplete with extra steps. They take a prompt, generate an output, and hand it back. No verification. No self-correction. No memory of what worked last time. If your agent can't catch its own mistakes, it's not an agent — it's a script.

The 70% problem persists because single-shot generation hits a ceiling. The model produces plausible output. You review it. You find errors. You re-prompt. The model produces slightly better output. You review again. You're still in the loop — but you're the loop. The human is the evaluator, the router, and the memory.

Agentic loops eliminate the human from the verification cycle. Not from the decision cycle — you still approve what gets shipped. But from the "did the AI hallucinate this import?" cycle. From the "is this function actually dead?" cycle. From the "did the model check production data?" cycle.

The Anthropic engineers running 100+ self-improving agents internally aren't running 100 better prompts. They're running 100 loops. Each loop has a narrow scope, a verifiable goal, and a stop condition. The agents don't just generate — they evaluate their own output, learn from their mistakes, and improve across runs.

That's the difference between a prompt and a loop. A prompt gets you an answer. A loop gets you a verified answer.

Naming Your Loops

The industry needs vocabulary. Here's the framework:

Research Loops

Parallel exploration where multiple agents independently analyze the same target from different angles. No agent sees another agent's work. They report findings up to an orchestrator. Use research loops when you need breadth — scanning a large codebase, reviewing a backlog, analyzing competitor products.

The key property: independence. Research agents don't influence each other. Independence prevents correlated errors.

Review Loops

Cross-verification where a second set of agents checks the first set's work. The review agent receives a specific claim ("this function is dead") and independently verifies or refutes it. Use review loops when false positives are expensive — code deletion, security changes, database migrations.

The key property: adversarial framing. Review agents are incentivized to disagree. If they agree, you have confidence. If they disagree, you have a signal to investigate.

Production Loops

Environment inspection where agents query the running system — databases, APIs, feature flags, runtime logs — before taking action. Use production loops whenever the code alone doesn't tell the full story. Which is always.

The key property: grounding. Production loops ground code analysis in reality. Source code says what could happen. Production data says what does happen.

The 3-Loop Architecture

Research → Review → Production. Each loop catches what the previous one missed. Research loops find candidates. Review loops eliminate false positives. Production loops catch the edge cases that code analysis can't see.

Three loops. Zero false positives. That's the architecture.

What This Means for Dev Tools

The competitive moat in developer tools is shifting fast.

Six months ago, the moat was "we have access to the best model." If you could get Claude Opus or GPT-5 into your product before competitors, you won. That advantage is gone. Every tool now runs frontier models. The model layer is commoditized.

Today, the moat is orchestration. It's how you route work between agents. How you verify outputs. How you handle the case where Agent A says "delete this" and Agent B says "don't." How you persist memory across sessions so your loops improve over time.

Sakana's Fugu packaged multi-agent routing into a single API. OpenAI shipped their Swarm toolkit. Kiro built a goal-driven loop interface. These are all bets on the same thesis: the value is in the loop, not the model.

Look at what practitioners are actually building. Reddit users are running 4-5 different LLMs per project — Claude for orchestration, GPT-5 for code review, Gemini for large-context scanning, DeepSeek for mid-difficulty coding, Qwen for testing. The routing logic? "If statements in markdown files." One practitioner asked: "Is there already a tool where you register your agents and it figures out the delegation for you?" The answer is barely.

The tooling gap is enormous. The orchestration layer — agent routing, memory management, cost controls, heterogeneous model support — is where the next generation of developer tools will be built. Cursor, Claude Code, Codex — they're commoditizing the model interaction layer. The differentiation is one level up: who has better loops.

If you're building a dev tool right now and your moat is "we use GPT-5" or "we have a fine-tuned model," you're six months away from irrelevance. If your moat is "we have a 3-loop verification architecture that catches hallucinations before they ship," you have something defensible.

Build Your Loops, Not Your Prompts

Here's the actionable takeaway.

Stop optimizing prompts. Start engineering loops.

A loop is defined by four properties:

1. Narrow scope — each agent does one thing, testably

2. Verifiable goal — success is measurable, not subjective

3. Cross-verification — another agent checks the output

4. Stop condition — the loop terminates when verified, not when tokens run out

If you're building AI-assisted workflows today, audit them against these four properties. If any agent in your system produces output that isn't verified by another agent, you have a prompt, not a loop. If your system doesn't have stop conditions, you have a token incinerator, not an agent.

The best loop wins. Not the best model. Not the best prompt. The best loop.

Anatoli Kopadze said it: "The winners won't have the smartest model. They'll have the best loop." We believe that. We built our entire engineering methodology around it. And the results — zero false positives, production-safe code changes, agents that catch what humans miss — speak for themselves.

Build your loops. The moat is in the architecture, not the model.

---

We're documenting our agentic loop methodology as we go. If you're building multi-agent workflows, multi-agent coding systems, or autonomous code review agents, we'd love to compare notes. The loop engineering discipline is too important to figure out alone.