The Ralph loop and the agent harness are ideas. Building a working app with them is a practice, and the practice has a shape. You point a harness at a goal, run it in a loop, and let files and git carry the progress until the goal is met. Done well, you can leave it running and come back to real software. Done badly, you come back to a burned budget and a pile of half-finished ideas. The difference is almost entirely in three things: the goal prompt, the verification gate, and the stop condition.
Write the goal prompt like a contract
The goal prompt is the one instruction that persists across every iteration of the loop. Each pass starts a fresh agent that reads this file and nothing else from memory, so the file has to carry the entire intent. Treat it like a spec, because that is what it is.
A good goal prompt states four things. The objective, in concrete terms, not "build a todo app" but the actual features and behaviors. The constraints, meaning the stack, the conventions, and the boundaries the agent must respect. The definition of done, written as checkable conditions. And the selection rule, telling the agent how to choose the next task each pass, usually "read the checklist, pick the highest-priority unfinished item, do only that." The selection rule is what keeps a forgetful agent from redoing work or thrashing.
Keep the state outside the prompt. The goal prompt is stable; the progress lives in a checklist file, a task list, or the git log. The agent reads the stable goal and the changing state together, which is how a stateless worker knows where it is.
Wire the verification gate into the loop
This is the step that separates building from spinning. Every iteration must end with a check the loop can run without a human. Tests are the obvious one. Types and linters catch a class of errors for free. An eval that exercises the actual behavior catches the rest. The agent does one unit of work, the loop runs the gate, and only a passing change gets committed. A failing change gets reverted or handed back for another pass.
Without this gate, the loop has no idea whether it is making progress or damage, and neither do you. With it, the loop is self-correcting: bad work does not accumulate, because the gate stops it before it commits. The harness is what runs this gate as a tool inside the loop, in a sandbox, so a broken attempt cannot touch anything real.
Define done, then let it run
Before you start the loop, decide exactly what will make it stop. All checklist items complete. All tests green. A target flow passing an eval. Whatever it is, make it a check the loop runs each pass, and make the loop exit when it passes. This is the single most skipped step and the single most common cause of failure. An agent with no real stopping condition will loop forever, because there is always one more thing it could plausibly do.
With the goal prompt written, the gate wired, and the stop condition set, the loop is boring in the best way. It reads the state, does one small thing, verifies it, commits, and repeats. The forgetfulness that seems like a weakness becomes a strength: every pass starts clean, so context never rots, and the git history becomes an honest record of how the app got built.
Start small and stay close
Do not point a loop at a green field and walk away on day one. Start with a narrow, well-verified goal, watch a few iterations, and tune the goal prompt where the agent misreads it. The first ten passes teach you where your spec is ambiguous and where your gate is too weak. Fix those, then widen the goal. The same discipline that runs a single bolt runs a thousand of them unattended; the loop just removes the human from between the passes.
This is loop engineering, and it is a skill a team can learn. If you want to train your engineers to build this way, on your stack and your backlog, that is exactly what AI Team Enablement is for. For the deeper members-only material on running these loops in production, the Agentic AI Lab goes further.
A goal prompt tells the loop what to build. A verification gate tells it whether it did. A stop condition tells it when to quit. Get those three right and the loop does the rest.