Ralph Loops: Build Dumb AI Loops That Ship

At 2 p.m. on Mondays, Chris Parsons kept getting the notification he dreaded: his newsletter workflow had failed. The n8n workflow selected blog articles, checked whether he had featured them before, summarized them and added commentary to saved links. Each failure meant reopening the graph, finding the broken step and repairing the automation. Eventually, simply writing the newsletter looked easier than maintaining the system that wrote it.

n8n had made orchestration and API-key management convenient. The problem was the complexity of this particular workflow. Parsons replaced it by pasting its exported JSON into Claude Code and asking for a skill based on the flow. The instructions survived, but the agent took responsibility for choosing the next action: read the relevant instructions, call a tool, inspect the result and continue until the newsletter was ready. The illustrated SKILL.md shown here organizes that work into voice principles, narrative structure and writing phases; it is an illustration, not his actual newsletter skill.

Parsons reports getting more coherent first drafts, although he still edits them. After a writing session, he asks the agent to update the skill with anything it should have done differently. That creates two feedback cycles: the agent works through the current newsletter, and the finished session improves the instructions for the next one. He associates this shift with more capable recent models, including the GPT-5 family, Claude Opus 4.6 and Claude Sonnet 4.6. His comments about Mythos are speculation rather than experience with it. The practical change is already concrete: a reusable skill can supply context while an agent loop handles the sequence of actions.

The original Ralph idea adds an outer loop around the agent’s own tool-use loop. Parsons credits Geoffrey Huntley, whose Ralph Wiggum as a software engineer describes the approach. The name comes from the Simpsons character: keep trying the same thing. Ask the agent to build a feature, let it announce completion, then give it the same request again. On another inspection, it may discover an omitted requirement or unfinished detail behind its confident completion message.

The workshop makes this visible with a deliberately incomplete Python Pomodoro timer. Its start command records a start time in ~/.pomodoro; one initial test checks that it starts. There is no command to inspect the remaining time or determine whether the session has finished. The first Markdown ticket asks for that status command. Parsons generated the backlog without carefully inspecting every ticket, so the exercise also leaves room for poor requirements—not just poor implementation—to surface.

Asked to implement ticket 001 under doc/tickets, Claude adds the status command and a new test. Repeating the request initially looks unnecessary: Opus recognizes that the feature is already implemented. But another pass catches something real—the ticket itself was not marked done. The code and the work tracker had diverged, and repetition repaired the tracker.

Parsons then clears the context and asks for the same ticket again. The fresh session finds the ticket, runs the tests and accepts the existing implementation. This separates two ways of repeating work: an early stop-hook approach resubmitted the request within a session, while an external shell loop starts the coding agent again. The minimal Bash form is:

while true; do
  claude -p 'Implement ticket 001 from doc/tickets.'
done

The -p flag matters because it invokes noninteractive print mode. Parsons initially omits it in the live shell attempt and accidentally executes an incomplete command. The loop above captures the mechanism, but it has no work-exhaustion condition, iteration budget or permission setup.

For the first exercise, run the timer and its initial tests, then ask Claude Code or Codex to implement only the first ticket:

python3 pomodoro.py start
python3 -m unittest test_pomodoro

Stopping after one ticket gives you something small enough to inspect. Experienced participants can compare another agent or try the same pattern in their own repository. An audience question about BMAD’s lifecycle-oriented skills raises the next issue: can the loop cover development, testing and delivery together? That requires specifying both the context the agent needs and what valuable completion means.

Repeating a completed request is useful, but pointing the loop at a backlog changes its purpose. Parsons credits a Matt Pocock video with making that extension click: instead of asking whether one feature is really finished, ask the agent to choose and finish the next useful thing. The state now advances through a queue of work, from pending to doing to done.

His earlier attempt had gone in the opposite direction. He decomposed a large project into tickets, smaller tickets and an explicit dependency graph. He then assigned streams to parallel agents. Multiple agents reached the same shared prerequisite, decided they needed to implement it and duplicated the work. Tracking what had actually been completed became a coordination problem of its own. Parsons recognized the resemblance to heavyweight waterfall planning: an elaborate specification handed over before implementation had taught anyone what needed to change.

The simpler instruction is to pick the next most important ticket. The agent reads the current repository and backlog, infers which prerequisites are already satisfied and chooses a useful next change. This does not eliminate dependencies; it evaluates them against current state instead of requiring a complete execution graph upfront. Parsons recommends starting with one continuously working agent before adding orchestration such as Gas Town. If the human already struggles to specify and review that worker’s output, more workers will increase the queue at the same bottleneck.

The timer backlog includes status, stop, custom durations and labels. Parsons asks for the next most important ticket, using TDD principles, followed by a commit:

claude -p 'Implement the next most important ticket from doc/tickets using TDD principles. Commit when done.'

The agent reads the first few tickets, chooses ticket two, works from the tests and marks the ticket done. A fresh session does not mean a fresh working tree, however: existing changes remain on disk, and the resulting commit does not isolate the changes as Parsons intended. Session isolation and repository isolation are separate concerns. Atomic commits need an explicit policy for pre-existing work.

Running that request repeatedly can work through the backlog. It does not establish that the backlog describes the product you actually want. In the demonstration, Parsons resets the repository before trying headless execution again; in your own exercise, use a disposable checkout if you want to compare prompts from the same starting state. Inspecting the product remains distinct from counting completed tickets.

The headless demonstration exposes a practical weakness immediately: Parsons cannot get streaming output configured, so the agent works without showing useful progress. He wonders whether stream-json was removed. The current CLI reference still documents --output-format stream-json; the live failure does not establish its cause. An unattended loop also needs permissions that let its intended operations proceed without blocking. That means selecting allowed actions, not necessarily bypassing every permission. Parsons introduces Lockbox as his attempt to restrict filesystem access after untrusted content enters an agent’s context, rather than as a demonstrated security guarantee.

Stopping the rough shell demonstration is awkward too. Work has happened—the status implementation is underway—but progress and control are poor. Parsons explicitly would not use this wrapper in production. The useful exercise is to improve the process through observed failures:

1. Let the agent select a ticket and write the change.
2. Read the code and inspect what it actually did.
3. Identify a missing process instruction, such as reducing duplication or running simplify.
4. Restore the disposable exercise to its starting state and try the revised prompt.

This improves the instructions from concrete output rather than adding an elaborate workflow before seeing what goes wrong.

Asked about Superpowers, Parsons says he had Claude inspect the repository and adapt missing capabilities into his own skills. He also tries experimental agent teams, enabling CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS and using Tmux. The revealing result is that Claude reads the backlog and decides the tickets should be implemented sequentially. The expected team setup is not clearly demonstrated; Parsons sees what appears to be a subagent instead. Delegating orchestration can still lead to the sensible decision not to parallelize.

A timer offers a relatively clear feedback signal: invoke a command and check its behavior. A newsletter needs editorial criteria. Parsons starts from newsletters he has written and examples he admires, asks the agent to extract the principles that make them effective, then checks those principles himself. The human supplies taste; the skill preserves enough of it to guide later drafts.

His experimental audience-simulation skill adds independent readers. Client and prospective-client personas review a draft in parallel, then suggest changes to either the newsletter or the writing skill. One useful critique is that a draft contains too many ideas and should focus on a single main point. A writer–reader loop can therefore produce a draft, evaluate it from another perspective and return specific revision requests to the writer. It remains a different kind of evidence from a functional CLI test.

Claude Code’s /loop command supplies another way to repeat work. Parsons asks it to build the next ticket every minute. The session creates a schedule through CronCreate, using the five-star cron expression * * * * *. Scheduled work runs between turns rather than interrupting an active implementation. This keeps the next-ticket loop inside Claude Code instead of requiring an external Bash wrapper.

A queue does not have to exist entirely in advance. An hourly loop could check Linear for new bug reports. A team-specific skill can encode what happens after discovery: select and claim the issue, examine architecture and context, implement the change, open a PR, respond to review, merge and release. The scheduler supplies the cadence; the skill supplies the work contract.

Skills package instructions, supporting context and scripts for loading when needed. Parsons demonstrates an images skill that includes a generation script and templates, and explains how it cooperates with a slide skill. Nano Banana Pro generated the workshop’s slide images, which were placed in Google Slides. Meanwhile, the background timer worker reaches ticket six and starts another scheduled turn. The practical benefit is that useful work continues while attention moves elsewhere.

Parsons describes refreshing the scheduled setup after about three days. That is a historical observation, not a universal Claude session lifetime: the current scheduling documentation specifies seven-day recurring-task expiry and execution while the session is running and idle. A scheduled task still needs an operating session; it is not an independent, permanently running service.

Visual work needs visible feedback as well. A participant reports using screenshot review to catch website spacing problems. Parsons discusses Playwright and Claude in Chrome for browser interaction, while distinguishing useful basic screenshots from his mixed results with more complex browser control. His image skill also inspects generated images for defects such as garbled text and rejects them before showing them to him. The output of the tool becomes input to the next judgment.

Does asking for an implemented ticket again check quality, or merely notice that its status says done? The loop checks what its instructions ask it to check. Parsons stops the scheduled worker to avoid consuming more quota and opens his fuller Ralph skill. The short request to build the next ticket leaves testing, completion and shipping ambiguous. His displayed skill uses doc/changes, while the workshop uses doc/tickets; either is just a storage convention. Beads, Linear or Jira can fill the same role if the agent can read and update them.

The fuller skill gives the agent a relay-team role: make exactly one change, stop and let the next session start with fresh context. It was designed for code that does not require human review before shipping. It tells the worker to read CLAUDE.md, understand ticket structure and status values, and inspect Git state before starting. The fresh-context design makes those files the handoff between workers.

Interrupted work needs a recovery policy, not an assumption that every iteration begins cleanly.

Parsons’s skill grew these rules through use. It also specifies project-specific test commands, parallel checks where appropriate, completion updates, handoff to testers, comment style and task-selection policy. A useful adaptation starts from those responsibilities and makes them concrete for the repository.

Outside the toy repository, Parsons combines several boundaries:

• Separate machine: Most work runs on a VPS away from his main computer.
• Restricted capabilities: Many developer tools are read-only; email access allows drafting but not sending.
• Dedicated credentials: The agent uses separate keys so its activity has a distinguishable audit trail.
• Selected permissions: Claude permissions constrain actions, although Parsons describes them as imperfect and is developing Lockbox to improve the situation.

These restrictions limit what an autonomous worker can affect even when it runs without continuous supervision.

He also presents Docker Sandboxes as a local isolation option. The current product describes microVM isolation; the workshop’s abbreviated spoken command should not be treated as current setup syntax. More fundamentally, filesystem isolation alone does not prevent an agent from leaking information between services it can access. Simon Willison’s lethal trifecta combines access to private data, exposure to untrusted content and the ability to communicate externally. Prompt injection can turn that combination into a data-theft path. Reducing how often those capabilities coexist is part of the security design.

Parsons clarifies that he does not use --dangerously-skip-permissions: he enables selected operations according to their risk. His concern about broadly empowered agents extends to OpenClaw, whose security he criticizes while acknowledging ongoing improvements. The useful distinction is between allowing a worker to complete its assigned job and giving it every capability available to its owner.

An audience member reports that validation began finding defects after moving it into subagents; review within the implementation context had mostly approved the existing work. Parsons connects that observation to fresh context: a reviewer that receives a focused task need not inherit the implementer’s whole account of why its choices were correct. He demonstrates simplify, the bundled Claude Code skill. In the demonstration, simplify runs three subagents over recent changes and finds issues to fix.

The accompanying question about OpenSpec leads to a distinction between planning and overspecification. Parsons supports thinking through a change, creating a plan and executing it. He prefers that specification to happen just in time, when implementation can still inform the next decision. His concern is that rigid tools can encode a workflow suited to today’s model limitations and preserve it after those limitations change. More useful context does not require a fully predetermined project or an immutable development process.

If an agent can choose tickets and write specifications, where does the human contribute? Parsons explores that question with a more ambitious Startup skill, drawing on startup books and crediting Ash Maurya. Its outer loop is supposed to identify the next important action for a product and then carry it out, potentially through subordinate loops. He explicitly says the experiment does not work yet.

It does produce a distinctive artifact. Asked how work was progressing on Air Skills, his skills-management project, the agent generates an investor-style update deck without being asked for that format. It organizes unresolved problems, evidence, prospective customers and pricing. Parsons rejects the numbers as wrong and pushes back on the premature confidence. The useful question in the final slide is still open: will organizations pay for skill governance? Its proposed next actions—build a scan command, publish an ecosystem post and validate willingness to pay in training sessions—are proposals, not proof of demand.

The next workshop exercise is to change the work source or improve the skill: try Beads instead of Markdown tickets, or connect a real ticket system without immediately submitting changes. The same pattern extends into recurring personal operations. Parsons describes a VPS heartbeat every 15 minutes that checks his calendar and other state and sends him Telegram updates, plus a 6 a.m. briefing covering the day, overnight activity and incoming email. Some worker details remain off-screen because they contain client information.

His personal Kanban application uses project files as the unit of work. A project contains front matter, questions for him, relevant context and a decision trail. The workshop-preparation project also brings together prior feedback and related notes. A worker reads that material and performs the next step, which might be preparing slides, checking information or drafting a reply. The interface itself is still imperfect: a feedback link fails during the demonstration.

Parsons reports typically finding about 15–16 draft email replies in the morning, all still requiring edits. His permission rule is whether an action is “reversible without embarrassment.” Preparing a slide deck qualifies; sending an email, posting on LinkedIn or sending an external message does not. At that boundary, the worker records what it has prepared and hands the decision back. The heartbeat’s notification to Parsons is a separate, explicitly configured behavior.

There is also a boundary based on preference rather than risk. Parsons does not want his job to become reviewing an endless stream of AI drafts. He wants to do client strategy and the thinking involved in helping organizations respond to AI. For that work, he asks the system to assemble the information and leave the strategic thinking to him. Choosing what to automate therefore includes choosing which work remains meaningful to do yourself.

Open-ended workers need explicit stopping rules. Parsons uses different loop files for different jobs. His worker stops when context is running low or the next action is irreversible, then updates the project file with progress and the decision awaiting review. He is experimenting with stepwise slides and a project interface because a wall of text—or a diff for a non-code artifact—can make the handoff difficult to understand. The report should help the human make the next decision, not merely document that the agent was busy.

Some requirements only become clear during implementation. Parsons handles that through two modes: automatic execution when he trusts the specification and feedback mechanism, and interactive work when the problem still needs clarification. His project interface exposes a VCP command intended to start a fresh Claude Code session on his VPS and load the project’s context. The interface is visible, although connectivity prevents him from demonstrating the VPS session itself.

Once loaded, the project file points the session to the surrounding information. Parsons and Claude can then work back and forth on tickets and unresolved choices. He often asks Claude to interview him: the agent asks questions, he supplies judgment and context, and it does the writing. This avoids requiring a complete specification before the conversation has uncovered what matters.

Review also depends on the artifact. For a newsletter, Parsons wants to read the newsletter itself. For important code serving other people, he reads the diff and checks behavior, particularly when security is involved. His preference for a better review presentation does not mean consequential code changes escape human inspection.

The two loop mechanisms make different context trade-offs:

Prior-ticket context can be useful, but Parsons often finds that the files contain what the next task needs. An unattended conversation adds little new human input worth preserving. He historically preferred fresh sessions, while finding /loop convenient and Opus’s long-context retrieval less troublesome than earlier behavior.

His workers may report a project finished, but they cannot close it. Parsons keeps that final verification step to avoid cognitive debt: losing track of what his codebase or projects now do. An audience member describes tracking individual tickets through sessions and status markers. Parsons instead collects sessions across his machines each night into JSON, asks for possible system improvements and produces a short account of the day’s work.

He can resume earlier work with a VCR command, but prefers the discipline imposed by a fresh start. If the next session must understand the project without the previous conversation, important decisions have to be written somewhere another agent or a human can find them. A saved session archive is only useful future context if it is retrievable. Treating sessions as ephemeral encourages the repository and project documents to become the durable record.

What about a loop that wakes up and finds nothing to do? Parsons would generally spend the tokens rather than spend his own time optimizing away every idle check. His description of an era of free tokens is an economic judgment about relative costs, not literal zero-cost execution. He reports paying $200 per month for Max 20 and being around 80% of his weekly quota during the workshop. He also points to improving cheaper models, including an unspecified GLM release from Z.ai, while continuing to use Claude himself. His preference is to avoid rebuilding the maintenance burden of the old newsletter workflow merely to minimize calls.

The loop’s prompt is code worth versioning. Parsons stores skills under a project’s .claude/skills directory or the corresponding directory in his home folder and versions them with GitHub. Commands such as /ralph and /bugtracking load those skill files as their operative instructions. The files can contain both personal expertise and customer intellectual property, so he does not publish every skill.

Version history does not establish that a prompt got better. Pressed on evaluation, Parsons says he uses other skills to critique and stress-test his skills, but the improvement process remains subjective. He proposes blind comparisons of ticket sets handled by different skill versions, without having performed them. Nondeterministic output makes a useful comparison harder, and more context helps only up to a point that he has not established. The workshop demonstrates iterative prompt repair, not an objective evaluation system.

Air Skills is Parsons’s attempt to make skills, bundles and team-specific skill sets easier to distribute and update without requiring every user to learn Git. It is still being built; GitHub remains his personal version-control system. The workshop’s sharing slide displays npx airskills chrismdp/ralph as the way to obtain his Ralph skill. That is the command shown in the recording, not a claim about the current installer interface.

The surrounding knowledge lives in two places: a code directory containing repositories and a vault directory containing his other work. Parsons often begins even coding-related sessions in the vault and points the agent to the relevant repository. The vault grew from Obsidian and contains accumulated research, notes and project information. A VPN fix, for example, becomes a file that a future session can retrieve rather than an answer stranded in a conversation. He mentions Karpathy’s LLM-wiki writing and MemPalace as related approaches, but recommends a simple starting point: Markdown files, Obsidian in one window and Claude in another.

His organization follows a Zettelkasten-style convention: one thought per note in a flat folder, with /projects holding units of work shared between him and the agents. Recorded-call transcripts and saved links, including their content, also go into the vault. A command-line embeddings tool indexes the material for retrieval. The resulting context is accumulated working knowledge, not something manufactured anew for every prompt.

Sharing skills creates a different management problem from maintaining them alone. Git repositories and symlinks are manageable personally; distributing files, ZIPs, submodules or plugin bundles introduces decisions about installation and updates. Parsons describes one-repository-per-skill friction with npx skills, but the current Skills CLI supports selecting multiple skills from one repository. The broader issue remains: a plugin can version a bundle, while a contribution to an individual skill may be either a useful general improvement or a personal adaptation that should not propagate to everyone. Deciding which changes to accept—and whether each skill needs its own backlog—is part of the product problem.

In a team, the first coordination mechanism is still ticket ownership. Connect the agent to the tracker so it can keep state current, check whether someone already owns the work, and claim the ticket before implementing it. Parsons also suggests reducing the number of people coordinating on one stream of work. That is an organizational experiment, not a fixed team-size prescription. Retrospectives should make room for meaningful workflow changes, and leaders need to sponsor trials that may fail rather than demand transformation without disruption.

The theory of constraints explains why faster implementation may not improve delivery. If review or release is the limiting step, accelerating code generation adds work to its queue. Parsons illustrates a monthly release growing from 20 PRs to 200 without a corresponding change in release capacity. The task is to improve the limiting process, observe where the constraint moves and then work there. He recommends Eliyahu Goldratt’s The Goal for this way of thinking.

A microservices question makes the constraint concrete: one service must release a tag before another can update its dependency. Parsons sees repository layout as secondary; an agent can start in a parent directory above multiple repositories. Ownership and release coordination are the harder questions. If cross-service release dependencies are the bottleneck, an atomic release system or a loop coordinating releases might help. Those are proposed remedies to investigate, not implementations demonstrated in the workshop.

The later Q&A returns to Gas Town and MCP Agent Mail. Parsons tried an early Gas Town version without getting it working, and has not tried MCP Agent Mail. He has not prioritized either because specification and review, rather than generation speed, constrain his work. An audience member offers a different reason for orchestration: agents can communicate, coordinate file access and bring Opus and Codex to the same project. The value need not be faster implementation alone.

Parsons connects that idea to his simulated audience. Its personas derive from transcripts and website survey responses, then assess content independently in parallel. Different perspectives—and a context reset that discards the authoring session’s assumptions—can produce more useful disagreement than another pass by the original writer. He sees promise in using different models for the same reason, while describing the orchestration tooling as early.

CI/CD, linting, good tests and a clean codebase give agents the same useful feedback they give human developers. They increase confidence that a change is functionally releasable. But when the agent writes both implementation and tests, both can encode the same misunderstanding of the requested feature. A green test suite may confirm consistency with the wrong requirement. Parsons limits unattended shipping to pre-release projects and continues reading consequential diffs, especially where customer data and security are involved. Production database migrations also require checking before execution in production.

Agent-driven UI click-through checks offer another feedback source, but Parsons estimates that they work about 50% of the time in his experience. He supplies no task set, denominator or scoring protocol for that estimate. Maintained end-to-end tests provide more concrete checks: for Air Skills, he describes constructing complete skill filesystems, exercising publisher and creator personas, and verifying that files end up in the right places. That tests a workflow across its boundaries instead of checking only an isolated function.

The aim is to let the agent determine whether it succeeded wherever that is feasible and desirable. Someone still has to design the criteria. In a solo project, Parsons does that work; in a team, product owners, product managers, designers and testers contribute their judgment about what good behavior means and how to recognize it. Their expertise can become executable feedback that improves every subsequent iteration.

The final audience example adds an adversarial reviewer: a development agent implements a specification, a separate reviewer challenges the result, and the feedback returns to the developer for revision. The participant reports catching more problems and gaining confidence, yet still becoming the bottleneck in human code review. Better automated critique helps without automatically removing the final queue.

Parsons recognizes the situation. He describes waking to a large set of outputs awaiting review, some handed back only because the system cannot be trusted to perform the next action. Hiring people to absorb that residual checking raises a further question: are we simply giving humans the tedious leftovers? The work still ahead is to design feedback and permission boundaries that make delegation trustworthy, while preserving the decisions people should—and want to—make themselves.