How I AI: Designing AI Agent Loops in Claude Code and Codex

In this episode of How I AI, Claire Vo explains agent loops through two live builds: a scheduled Claude Code routine for aging pull requests and a Codex automation that looks for missing skills, then delegates validation to goal-driven subagents.

A loop is repeated or event-triggered prompting around a defined job. It is useful when the same task recurs on a schedule or when an agent should continue until explicit success criteria are met. It does not require every interaction to become autonomous.

Several trigger patterns can start or continue the work:

• Heartbeat: a recurring check, such as looking for new Jira tickets every five minutes.
• Cron: a run at a defined time, such as every Sunday at 9 p.m.
• Hook: an external event such as a new email, or an internal lifecycle event such as a tool call.
• Goal: an agent keeps working toward a stated outcome and uses validation criteria to decide when the job is complete.

A practical loop also needs the environment for the job: an appropriate trigger, repository isolation where needed, reusable skills, access to required connectors, delegated agents when useful, and state that survives each iteration. The prompt should read more like a job definition than a single request.

Workflow 1: review aging pull requests each day

ChatPRD had a backlog of pull requests, including older changes that were easy to forget after the team moved to other work. Claire used that repeated coordination problem as the input for a Claude Code routine.

Step 1: create the routine

She named it “daily aging PR review” and asked it to find open pull requests older than 12 hours, assess merge readiness, and either monitor actionable work or alert the team.

The local routine was scheduled for 10:15 a.m. each day. Because it ran locally in the demonstration, the computer needed to remain available.

Step 2: define the two outcomes

The instructions gave the routine access to GitHub and Slack and allowed it to create another thread for work that an agent could continue.

Look at the prs open on the chat PRD app app. If there are any prs open more than 12 hours. Please review their merge readiness. If there is anything that you can babysit, spin up a thread to babysit that PR until all merge checks are green. Otherwise send a slack in the product channel to the team about the open prs that are ready for approval and merge be mean when you send the slack.

The prompt described two paths:

1. If an older pull request could be moved forward by an agent, create a thread to monitor it until its merge checks are green.
2. If it was ready for human approval or merge, send the product team a Slack message.

Step 3: verify the connectors and run

Claire started the routine during the recording, but did not wait for it to finish. The live setup exposed one dependency immediately: the Slack connector was not surfaced until she enabled it. The expected result was a set of merge-ready pull requests and a Slack summary, not a demonstrated improvement in merge speed.

Workflow 2: find and validate missing agent skills

The second workflow asks a scheduled automation to inspect recent engineering work for tools or test suites that do not yet have reusable agent instructions.

Claire built it in Codex using an automation template as the starting point.

Step 1: narrow the search and require evidence

She selected “From recent PRs and reviews suggest next skills to deepen” and scheduled it for Fridays at 10:00 a.m.

The revised prompt prioritizes command-line tools and test suites that agents or developers can use to validate work. Every suggestion must be tied to repository evidence, and every proposed skill must be tested before it is accepted.

If you identify a skill, spin up its own thread and use that skill... validated against the base branch of the repo. We want to confirm that the skill actually works and outputs high quality... You should use a goal when validating the skill.

This creates two layers. The weekly automation identifies candidates. For each candidate, a delegated thread receives a goal to validate the skill against the base branch and report whether its instructions produce a high-quality result.

Step 2: inspect the delegated validation work

In the live run, Codex identified `chat-smoke-cli`, a command-line tool for testing ChatPRD conversations without the user interface, and created a dedicated validation agent.

The chat list also showed a second agent validating a GitHub comment-addressing skill. Each thread had a specific goal and evidence target.

The episode showed the automation finding candidates and starting delegated validation. It did not establish that every proposed skill passed, so completion still depends on the results each thread returns.

Cost and control boundaries

Loops can consume tokens quickly, especially when a scheduled job can create more agents and each agent continues until it decides a threshold has been met. Monitor cost and runtime, and place limits around the jobs that can fan out.

Goal-based loops also need precise success and stopping criteria. Claire said the demonstration prompts were rough and should not be copied as finished production instructions. Weak validation can waste tokens or leave the task circling without a useful result.

Begin with one repeated job whose inputs, permissions, output, and stopping condition are easy to inspect. A loop is valuable when it removes repeated coordination while leaving consequential approvals and ambiguous decisions with a person.