We need to talk about Ralph

Ralph loops are a way to run AI coding agents in a repeating “bash loop” so they can keep working until a project goal is reached—without relying on ever-growing chat history that eventually degrades performance. The core insight is that agent quality often collapses under bloated context (“context rot”), so the loop’s value comes from restarting each step with a fresh, purpose-built prompt while persisting only the information that truly matters.

In the original Ralph loop pattern, a script repeatedly pipes instructions into an agent (the transcript uses an example like a bash `while true` loop that keeps feeding prompts into Claude Code). That can run indefinitely, but it also highlights why “how the loop is implemented” matters. Many modern “Ralph loop” plugins behave differently: they run inside an existing coding session, meaning the agent’s context still accumulates inside that session. When context keeps overflowing, the system falls back to compaction—summarizing old history to fit the window—which can silently drop critical instructions (for example, an instruction like “always read this specific file”). The transcript frames this as the opposite of the original Ralph mindset: instead of letting the agent’s conversation history balloon and then compressing it, the loop should treat each iteration as its own new history.

That shift forces a harder engineering problem: if each iteration starts fresh, where does the agent’s “memory” live? The answer is persistence through external state—typically files that track plans, progress, and learnings. A concrete example from the transcript uses a PRD-driven workflow: the agent selects the next story from a plan document, implements it, runs type checks and tests, commits changes if they pass, marks the story done, logs learnings, and then repeats. Memory persists by writing updates to a progress file (e.g., `progress.ext`) and committing to git, rather than by carrying thousands of tokens of chat history forward.

Implementations vary in how they decide what to do next and when to stop. The transcript contrasts manual halting (classic Ralph loops) with model-driven completion signals—such as instructing the agent to output a specific “promise complete” marker when all planned work is finished. It also recommends setting a maximum iteration count to avoid burning tokens indefinitely.

A major practical theme is context engineering. Because each loop iteration may not include the full prior conversation, the initial prompt must point the model to the right artifacts: a spec file describing the project, an implementation plan, and instructions for how to find additional information. The transcript argues that it’s acceptable—even beneficial—for the prompt to tell the model where to read files, as long as the model knows the correct paths; the model can then use tools like search to retrieve what it needs.

Finally, the transcript positions Ralph loops as a reliability strategy that reduces coordination complexity. Instead of parallelizing tasks (which introduces conflicts, dependencies, and “blocked task” repetition when memory is lost), the loop picks one highest-priority task at a time, completes it, then re-evaluates what remains. The transcript also adds nuance: if the goal is simply to let an agent run longer, some tools (like Codex) may already handle long-running work well through different context behavior. The takeaway isn’t “use Ralph loops,” but “rethink how agent context is managed so the right information stays on the ‘train’ before the agent starts coding.”