Blog: My Ralph Wiggum Experiment
My Ralph Wiggum Experiment

My Ralph Wiggum Experiment

21st of March 2026

Solo Dev JourneyAI programmingOtto AgentRalph Wiggum

I built a Ralph Wiggum loop, and it made me think

Lately I’ve been working on what I call Otto Agent.

You can find the repo here: https://github.com/phillipphoenix/otto-agent

At its core, it is basically a Ralph Wiggum loop. A Ralph Wiggum loop is more or less just a very simple while loop around an AI agent that is started up with the same prompt again and again until it is stopped.

What I’m building is basically that idea, but with a bit more structure around it.

This version has some primitives like context, intructions and checks that can be injected into the prompt allowing for history, validation and customisation.

This was all inspired by Kasper Junge’s project Ralphify, from which I “borrowed” most of the structure. See his project on GitHub here: https://github.com/computerlovetech/ralphify

One thing I’ve added on top of Kasper’s project was stopping conditions, allowing the loop to decide, when it should stop.

A plain loop can easily just keep running forever until you stop it. That is fine right until you forget. If you are using something subscription-based like Claude Code, maybe that is not too bad. But if you are using API keys and usage-based pricing, that kind of mistake can suddenly become very expensive. So I wanted to be able to define when a workflow should complete.

That could be something like: work through all Linear issues that match a condition, and then stop when there are no more left.

That feels a lot safer and more token efficient.

I’ve mostly got it up and running, so soon I’ll probably try using it on a real project. So far I’ve have only used it to work on itself, which is very meta and also kind of funny, but I have not really used it properly on my other projects yet.

It is ready to test out on other projects, but I’m still figuring out exactly how the workflows should be.

The workflow I want

The main place I want to use this is with Otto Planner, my event planning app.

I’m using Linear there, and the workflow I keep thinking about is actually quite simple.

I want to be able to quickly write a rough issue without too many details. Just enough to capture the thing I want done.

Then I mark that issue as needing enrichment.

From there, an agent should pick it up and expand it into something more implementation-ready. It should look through the codebase, find relevant documentation and at the end it should rewrite the issue description into something that fully describes the issue.

Then I come in and review that enriched issue. I skim it, tweak a few things and I make sure it is correct. I then mark it ready for work.

After that, another agent should pick it up, do the work, and open a PR.

When the PR is ready, I’ll review it and either merge it or add comments.

A third agent will then be looking for open PRs with comments, and when found, pick up the PR and fix the issues noted down.

So the flow is basically this:

This could be a useful workflow for me.

I’m not ready to fully unleash agentic workflows all the way without human oversight, but this would still allow me to get a lot of work done.

The next question is how to run it

This workflow can be set up in many different ways and I’m still not sure about which fits me better.

One option is to split things into three separate agents.

That makes sense as they are three pretty distinct jobs.

The problem is that at least two of them want to work inside the repo and make changes. If both the worker and the PR fixer are doing that, they probably should not share the same working copy. They may want to be on different branches. Or the may want to touch on the same parts of the codebase. So the obvious solution is to give them separate copies of the repo to now have conflicts.

This would mean that I’ll have 3 agents running at the same time.

In theory, I could just live inside Linear and GitHub like that. Creating issues, reviewing plans, reviewing code, leaving comments, and never actually open an IDE.

And even better, if I can set up preview deployments to also see the result running.

But can I keep up?

The thing I keep thinking about to is that these agents will probably be faster than me most of the time.

The enricher is fast.
The PR fixer might also be fast depending on the comments.
Only the worker might stay busy for longer stretches.

So if I run all of them all the time, there will probably be a lot of waiting around. I run them, they do the available work and then keep checking for new work over and over, spending tokens in the meanwhile. It isn’t necessarily a problem in practice, but it feels a bit wasteful.

So then I started thinking about another option.

Maybe the right answer is one orchestrator on top

Right now, in the Otto Agent repo itself, I already have a kind of orchestrator for working on issues for Otto Agent.

It reads one issue at a time and for each issue it creates a plan with tasks. Then it spawns a task sub-agent that runs a Ralph loop and works through the tasks one at a time. When it is done, the orchestrator commits the changes and opens a PR.

That already exists and is working.

So the obvious question is: why not take that one step further?

Instead of having an orchestrator that can only spawn task worker sub-agents, it could perhaps spawn agents for different kinds of work?

The orchestrator get some context to decide what to do:

I could then set up priorities for the types of work to be done.

For example:

  1. Enrich issues first
  2. Fix PR comments second
  3. Work on new tasks last

This could be defined in the workflow file, so it is flexible and possible to change later.

Then the orchestrator would look at the current state, pick the highest priority thing available, and spin up the relevant sub-agent or sub-workflow for that one job.

So instead of three parallel workers, I would have one personal assistant that just keeps taking the next most important thing.

That means I would only need one copy of the repo.

This appeals to me on some level.

Why I like that idea more

I think the main reason I like the orchestrator idea is that it feels closer to my own speed.

I’m not really trying to build a fully autonomous software factory here. At least not right now.

What I actually want is a good balance.

I want to offload a lot of the annoying or time-consuming parts. I want help enriching issues and I want help turning reviewed plans into code. I want help responding to code review comments.

But I still want human checkpoints.

As mentioned earlier, I’m still not entirely comfortable with leaving everything up to the AI and I also don’t think that it is entirely realistic for a lot of programming tasks just yet.

And that means a single orchestrated workflow may actually fit better than a bunch of parallel agents racing ahead of me.

The downside, of course, is more complexity

The orchestrator part sounds good on paper, but I still need to figure out exactly how I would set it up. And does it make sense that the sub-agents are Otto Agent workflows themselves or does it make more sense that they are one-off calls to Claude Code without a loop?

And it would probably require changes to the Otto Agent setup.

So I’m not fully sure yet which way I’ll go.

It might be that I start with the 3 separate agents version because it is easier to set up and get started. Or it might be that I skip straight to the orchestrator because it seems more aligned with how I actually want to work.

Right now I’m still somewhere in the middle, thinking through it.

What I think is interesting about all this

Obviously there is something appealing about creating automations, but there is also another interesting part in all of this, which is to try and figure out how I want to collaborate with a more autonomous agent.

For now I’ve been mostly micro managing a couple of Claude Code instances running in my terminal, but are there ways to work with agents that make them feel more like having a junior developer at the ready?

This raises some questions:

Where do I want help?
Where do I still want control?
Where do I want review gates?
What kinds of work am I happy to delegate?
What kinds of mistakes am I okay with?
And how much complexity is worth adding just to make that collaboration feel natural?

And even more important: what kind of works make me happy to perform myself?

It’s been on my mind lately.

I’ve also been wanting to write something about Ralph Wiggum loops and Otto Agent for a while, mainly because starting to work with it really has created a lot of questions for me on how I am going to work going forward.

End notes

This post is a bit of a rant. But it is also basically where my head is at right now.

Otto Agent is starting to become real enough that I can start using it on real projects and I’m now at the point where I need to choose whether I want multiple parallel agents or one orchestrator that behaves more like a personal assistant.

I’m prone to overthinking, so maybe I should just pick one and get started 😅

But if you have worked on something similar, or have thoughts on how you would structure this kind of setup, I’d genuinely be curious to hear it.

And if you want to take a look, feel free to check out Otto Agent and also Otto Planner, which is the app where I’m hoping to use this setup in practice.

Phillip Phoelich

21st of March 2026

Back to blog