How to Design AI Agent Loops: Schedules, Goals, and Subagents in Claude Code and Codex

Artificial intelligence is moving past one-off prompts into autonomous workflows. AI agent loops are systems that run tasks repeatedly, watch conditions, and spawn subagents when the work needs to split.

In a recent hands-on session, Claire walked through practical automations in Claude Code and Codex: a daily pull request review loop and a weekly skills loop that improves itself. Mozilla engineer Brian Grinstead showed how similar ideas helped agents find and fix hundreds of Firefox security issues.

This piece breaks down the concepts, workflows, and lessons worth applying in your own stack.

What is an AI agent loop?

At its core, a loop is a prompt that triggers itself again until a condition is met.

Loops are not new. Cron jobs, scheduled tasks, and event hooks have existed for decades. What changed is swapping rigid scripts for agents that can reason about the next step.

Think of it as giving an AI teammate a recurring job description.

Examples:

Review open pull requests every morning.
Summarize important email threads.
Audit merged code every Friday.
Spot skill gaps and schedule learning work.

Types of agent loops

1. Heartbeat loops

Heartbeats run on a fixed interval.

Examples:

Check server health every five minutes.
Watch CI pipelines every hour.
Post a short status update on a schedule.

They are predictable and easy to reason about.

2. Cron (scheduled) loops

Cron loops fire at specific times.

Example prompt:

Every Friday at 10:00 AM, review merged pull requests and list skills our agents are missing.

That is not just a timer. It is a job spec.

Claire's demo included:

Daily PR review automations
Weekly skills assessments
Morning briefings that summarize calendar and email, then post to Slack

You do not need heavy infrastructure. A schedule plus a clear prompt is already a working loop.

3. Webhook loops

Webhook loops react to events:

A new GitHub pull request opens
A customer files a support ticket
A payment succeeds
Production deploy finishes

The agent wakes on the event instead of polling all day, which keeps cost and noise down.

4. Goal-based loops

Goal loops chase an outcome, not a clock.

Flow:

Receive an objective.
Work toward it.
Check progress.
Stop when success criteria are met.

Example goal:

Reduce authentication latency below 100ms while keeping security checks and passing all tests.

The loop ends only when verification confirms the target.

The common mistake: vague goals. If success is fuzzy, agents may loop forever, burn tokens, ship weak output, and run up cost.

Write measurable outcomes.

Weak: "Improve performance."
Strong: "Cut page load time by 30% and pass all integration tests."

Design loops like onboarding a new hire

Treat each agent like an employee.

You would define:

Responsibilities
Schedule
Expected output
When to escalate

Do the same for loops.

Weak:

Check pull requests.

Strong:

Every morning at 8:00 AM, review open pull requests, summarize blockers, assign reviewers, and alert the team if merge checks fail.

Clear instructions produce predictable behavior.

Subagents scale the work

The interesting part: agents can create more agents.

PR review loop

A parent agent can:

Scan all open pull requests.
Flag failing merge checks.
Spawn one subagent per PR.
Let each subagent watch its PR until checks pass or someone must intervene.

Work stays distributed instead of piling onto one process.

Self-improving skills loop

In Claire's Codex workflow:

Review merged pull requests.
Find knowledge gaps.
Create subagents for each gap.
Run a goal loop per subagent.
Validate new skills in real time.

You get a system that learns on a schedule instead of waiting for manual updates.

Mozilla's Firefox security loops

Mozilla's Claude Mythos setup combined loops, verification, and subagents to find and fix security issues in Firefox.

Result: 423 Firefox security fixes in one month.

The breakthrough was not only model size. Mozilla built a harness that gave agents:

The right tools
Verification steps
Prioritization rules
Human review before changes landed

Why agents are strong at bug hunting

Humans tire after many attempts. Agents do not.

Mozilla saw agents try 14, 15, or 20 different paths to trigger a bug without losing focus. That persistence surfaces issues easy to miss in a long manual session.

Verification loops cut false positives

Mozilla used two stages:

Stage 1: The agent must reproduce the crash.

Stage 2: A verifier subagent checks whether the report is valid, reproducible, and not caused by test-only setup.

By the time engineers see a report, noise is already filtered out.

Prioritization matters at scale

You cannot scan millions of lines blindly.

Mozilla used a lightweight judge model to score files by:

Likelihood of memory safety issues
Exposure from web content

That ranking steered agents toward high-value files first.

The same idea applies to performance work, tech debt, UX fixes, and code quality reviews.

The cost of bad loop design

Loops get expensive when:

Success criteria are unclear
Validation is weak
Agents repeat useless work
Nobody monitors spend

Track token use, runtime cost, output quality, and completion rate.

A loop that never stops is not automation. It is runaway spend.

Takeaways

Loops are self-triggering prompts with a stop condition.
Heartbeats, cron, webhooks, and goals are different triggers.
Goal loops are powerful but need precise success criteria.
Write loop specs the way you would write a job description.
Agents can spawn subagents with their own loops.
Verification and prioritization make large-scale automation practical.
Monitor cost and quality from day one.

Closing thought

Software work is shifting from isolated scripts toward systems of agents.

The question is less "Can AI do this task?" and more "Did I define the job, the success criteria, and the verification clearly enough?"

The best agents are not magic. They are well-briefed teammates that do not get tired.

— Programmer Calendar