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

Most people still treat AI agents like chatbots they manually poke with prompts. I argue that the more useful pattern is often a loop: a scheduled or goal-driven system that keeps prompting itself until a job is done. In this episode of How I AI, I build two examples live: a Claude Code routine that reviews aging pull requests every morning, and a Codex automation that searches for missing engineering skills, then launches subagents to validate them. See Build a Self-Improving AI to Generate Agent Skills in Codex.

My definition of a loop is intentionally simple. A loop is repeated or event-triggered prompting around a defined job. Sometimes that means a scheduled task that runs every day. Sometimes it means an agent continuing to work until it can prove a goal was met. The important distinction is that the prompting no longer depends on a person sitting at the keyboard.

I break loops into four common trigger patterns that already exist in traditional automation systems:

• 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.

I frame loop design less like prompt writing and more like onboarding an employee. The agent needs a clear job, tools, permissions, workspace isolation where appropriate, reusable skills, state tracking, and sometimes subagents that can take on specialized work. The prompt itself starts to look more like an operating procedure than a one-off request.

A daily PR triage routine in Claude Code

The first build starts with a very real coordination problem inside ChatPRD. The team ships a large number of pull requests, often with agents involved in the coding process, and older PRs were quietly aging out while everyone moved on to newer work. I wanted a routine that could monitor stale PRs without requiring somebody to manually check GitHub every morning.

Create a scheduled routine with delegated follow-up

I created a Claude Code routine called "daily aging PR review" and instructed it to inspect open pull requests older than 12 hours, evaluate whether they were merge-ready, and decide whether the work could continue autonomously or needed human attention. You can follow the full implementation in Automate Daily Pull Request Reviews with a Claude Code Agent. See Automate Daily Pull Request Reviews with a Claude Code Agent.

The routine was scheduled to run locally every day at 10:15 a.m. That detail mattered. Because the automation was running on my machine rather than in a hosted environment, the laptop still needed to stay awake and available for the job to execute.

Define what the loop should do next

The routine had access to both GitHub and Slack connectors. I also explicitly allowed it to create follow-on threads when a pull request needed ongoing monitoring. That turns a simple scheduled task into a lightweight manager that can delegate work instead of handling everything in a single session.

Example automation instruction: Review open pull requests in the ChatPRD app. For any PR open longer than 12 hours, assess merge readiness. If you can resolve failures or babysit the checks, start a task and stay with it until every merge check is green. Otherwise, send a direct Slack message in the product channel listing the PRs ready for approval and merge.

The prompt gave the routine two possible actions depending on the state of each PR:

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.

Run the automation and catch missing dependencies

When I ran the routine during the recording, one operational issue surfaced immediately: the Slack connector was not enabled yet, so the automation could not send notifications until I fixed the integration. That small moment is part of the larger point of this episode of How I AI. Loops are not just prompts. They depend on the surrounding environment being configured correctly, including connectors, permissions, schedules, and execution context.

The routine itself was straightforward. It checked for stale pull requests, attempted to babysit any work that could progress automatically, and otherwise prepared a Slack summary for humans. I did not wait for the full run to complete on camera, so the episode demonstrated setup and orchestration rather than measured impact on deployment speed or review throughput.

A Codex automation that discovers missing engineering skills

The second build is more ambitious. Instead of managing pull requests directly, the automation scans recent engineering work looking for tools, workflows, or testing patterns that should probably have reusable AI instructions attached to them.

I built the workflow in Codex, starting from one of the platform's built-in automation templates. I specifically called out the templates as useful scaffolding for people still learning how to structure loops and automations.

Constrain the search and require proof

I selected "From recent PRs and reviews suggest next skills to deepen" and configured it to run every Friday at 10:00 a.m.

I then rewrote the default instructions to focus specifically on command-line tools and validation systems that agents or developers could use to test work automatically. The automation was told to ground every recommendation in concrete repository evidence rather than generic advice.

I also added an important constraint: proposed skills could not simply be suggested and accepted. Each one had to be validated against the base branch before it counted as useful. That requirement introduced a second layer of looping behavior inside the automation.

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.

The workflow effectively became a manager supervising other agents. First, the weekly automation identifies candidate skills from recent engineering activity. Then it creates delegated validation threads, each with a specific goal to test whether the proposed instructions actually produce high-quality results when run against the repository.

Watch Codex spawn validation subagents

During the live run, Codex identified `chat-smoke-cli`, a command-line testing tool used to validate ChatPRD conversations without relying on the UI. The automation then launched a dedicated validation agent tasked with checking whether the corresponding skill instructions actually worked in practice against the base branch.

A second delegated thread appeared for a GitHub comment-addressing skill. Each subagent had its own narrowly defined objective and validation target. Rather than endlessly brainstorming improvements, the system was forced to produce evidence that the skill could execute successfully.

The interesting part of the demonstration was not just that Codex could discover candidate skills. It was the layered orchestration. A scheduled automation reviewed repository activity, created specialized subagents, and assigned those agents goal-based validation loops. The episode showed the system kicking off that work successfully, but not every proposed skill necessarily passing validation. Human review still matters because the automation can only be as reliable as its evaluation criteria.

Where loops become expensive or unreliable

I repeatedly warned that loops can burn through tokens very quickly. A scheduled automation that launches additional agents, each running until a goal is satisfied, can expand into a surprisingly large amount of work. The danger is not only runtime cost. Poorly bounded loops can keep iterating without producing meaningfully better output.

That risk grows when loops are allowed to fan out into multiple delegated threads. Monitoring runtime, cost, and concurrency limits becomes part of the workflow design, not an afterthought.

I was also unusually candid about the prompts themselves. The examples in the episode were rough working versions, not polished production systems. Goal-based loops in particular require precise success criteria and strong validation rules. If the agent cannot clearly determine what counts as completion, it may continue looping, waste tokens, or approve low-quality work.

I mentioned that I often use Codex to help draft better goal definitions because evaluation logic matters far more in loops than in ordinary back-and-forth prompting.

The strongest takeaway from this episode of How I AI is that loops work best when the task is repetitive, inspectable, and easy to validate. Reviewing aging PRs, monitoring test results, checking for missing skills, or preparing recurring summaries are all good candidates because the inputs and outputs are relatively clear.

What is worth copying here is not the exact prompts. It is the operating model: treat agents like workers with schedules, tools, permissions, and measurable goals. The PR workflow is especially practical for engineering teams drowning in coordination overhead. The Codex example is more experimental but useful for teams building reusable internal tooling.

The part that still requires human judgment is evaluation. Humans still decide whether a pull request should merge, whether a proposed skill is genuinely valuable, and whether the loop is spending too much money for too little signal. The automation reduces repetitive supervision. It does not remove the need for supervision entirely.