I talked about the Ralph Wiggum loop in my second blog post. Now I’ve finally implemented it.
Named after the iconically simple Simpsons character, the Ralph Wiggum loop is a revolutionary agentic engineering technique popularized by Geoffrey Huntley and now proven enough to be a regular part of the agentic engineer’s vocabulary, referenced by OpenAI, and the namesake of an official Claude plugin. It’s described by its creator as “deterministically bad in an undeterministic world.” To understand why Ralph is so powerful, you need to understand context rot. Context rot, affectionately called the “dumb zone,” describes the point (around 100k to 175k tokens) at which the context window becomes so bloated that your agent starts making silly choices.
For readers outside of the agentic dev sphere, a “context window” is the functioning memory of an agent. As you give more information and more is worked out by an agent, it has less and less space in its “mind” to actively remember everything. Unfortunately, that space quickly becomes congested and the agent’s performance begins to degrade. When the context window is too crowded, your agent may forget to follow certain instructions, code with techniques that don’t align with your project’s previously-established patterns, and introduce buggy material. This is why “vibe coding” in which a developer uses a ChatGPT chat for 86 hours to make a new platformer game ends up with so many bugs. After 15 or 30 minutes of work, your agent knows too much and will start disappointing you.
Ralph solves this by regularly refreshing it’s short term memory. You (or agents) store important information like project specifications and agent instructions in markdown files: this is the long-term memory. To begin the loop, you launch an agent and feed it the long-term memory files so that it has the necessary context to accomplish only one small task on your project. After the task is finished, the agent updates the long-term memory (perhaps by checking off a box on the implementation_plan.md). Then, you shut the agent down before it enters the dumb zone. For the next task, spawn a fresh agent with a blank slate memory to pick up where the previous agent left off. This fresh agent does one small task, then logs progress in the long-term memory and shuts down. Etcetera. Here is a wordy visual for how the Ralph Loop works:
The biggest obstacle to my making my own Ralph Loop is my inexperience doing things in the terminal. This week, we overcame that fear and got my own Ralph working. I used ChatGPT to guide me through my interactions with the terminal and create my simple agent in Python.
Critically, I needed a place for the agent to run. The agent must be able to execute bash commands and edit files across a directory, so there’s a risk that it could reach outside of its intended project and do something catastrophic if I don’t confine it. I used Docker desktop, which creates a mini-Linux computer that acts as a little cage for my agent to run around in. It is impossible for the agent to see or reach outside of the cage.
I also got the spec.md file and the agent.py file set up. The agent is super simple: it can read files, write to files, see files in my directory, and run bash commands. Its brain (LLM) is OpenAI’s gpt-5.6-luna, which I heard was both cost-effective and proficient for coding tasks (according to the engineer I referenced in my last blog.) I was delighted to see that I relatively understood the agent.py file written by ChatGPT, as the structure matches the same brain → tool definitions → toolmap → workflow format that I learned about from Geoffrey Huntley’s workshop and implemented myself.
Finally, it was time to start working. First, I started a chat with the agent to have it read the spec and write a detailed implementation_plan.md. Each single step in the implementation plan uses a distinct context window. Each iteration of an agent in the loop should check off the checkbox of the step they just completed in the implementation plan. The next agent picks up where the previous iteration left off.
This implementation plan is just for the making of a calculator. In reality, you could do this with 3 or fewer iterations of the Ralph loop, but this is more about trying the technique than reasonably making a calculator. This should take much longer than a calculator requires, because my prompt.md has each agent session write and run multiple unit tests for its work. It’s probably doing more testing than coding.
I also need a prompt.md, which is the core prompt that’s repeatedly fed to the agent in the loop. The prompt is given before each iteration, for each checkbox in the implementation plan. But for the first try, I want to start by only having the agent perform one checkbox before it stops and checks in with me. Here is the prompt.md for that process. You’ll see that it outputs “COMPLETE” in step 11. I’ll tell the terminal to watch for this and kill the agent process when it gets a “COMPLETE.”
After running the first time, it successfully completed the first checkbox but did not print the checkpoint that I asked for in step 10 of the prompt. Changing the wording from “Report a checkpoint...” to “Print the checkpoint...” fixed this. I ran one more single loop, and it was successful. The agent correctly identified that the first checkbox in implementation_plan.md was complete. It executed and tested the second task on the list before checking the box. Here is the output I received:
Finally, it was time to let Ralph go. I updated the prompt.md file so that the agents would issue out a report for each iteration, but not print out “ALL COMPLETE” until the final checkbox is checked. I used a shell loop that would continue activating agents until either “ALL COMPLETE” or unexpected output terminates the process.
It worked fantastically...until the very last checkpoint.
I thought that something was actually wrong, but it actually failed because the agent printed “1 TASK REMAINING” and the script was only prepared to accept “<X> TASKS REMAINING”. TaskS, with an “S”. Good grammar on the agent's part killed an otherwise-solid process. After setting the script up to accept the singular or plural of “task,” I reran the loop to accomplish the final item.
Congratulations - now we have a Ralph-made calculator.
There are a few important notes to make about my implementation here. For one, a Ralph loop is overkill for a calculator. I had the agent write and perform unit tests for each task in its loop. 37 rounds of unit tests for a calculator. I bet that it spent more time writing and executing tests than coding the product. Besides, 37 unique steps aren’t necessary for a project this simple. In reality, I would choose to “vibe-code” a calculator by giving any decent LLM a three-sentence prompt. Still, this was a great goal for me to use in my first try at a Ralph loop because it let me refine the process without getting distracted by project-specific technicalities.
I recently had a conversation about this with my dad, who expertly uses Perplexity’s chat interface to develop products with long-running agents. His style is different from my style, and we’re both deep in world of AI-driven product development. My current theory is that builders like my dad who come from a business, entrepreneurship, and management background will prefer developing with something like Perplexity, while programmer types may prefer tools like Claude Code that keep interactions in the shell or an IDE. A business genius is ready to manage agents that behave like employees. My dad wants his agents to have long memories, human-like awareness of the product, and an ability to self-govern. He’s willing to have to redirect them here and there, and he’s willing to remind them when they’re forgetting something important. A programmer, on the other hand, wants agents to behave like functions. Agents should be dumb, predictable, and contained so that they can be programmed. For proponents Ralph Loop, any problems with an agent’s activity should not be solved by re-prompting once but by changing something in the structure of how you’re using the agent. You should change the agent’s abilities, add guardrails, refine the looped prompt, narrow the specifications, or tune the implementation plan. This is how agents like Ralph are meant to work, and I’m curious to see what I learn about using agents as programs as I continue to learn.