There is now one in every office. The person who says agentic a little too often, forwards Twitter threads about autonomous workflows, and announces in meetings that "we really need to automate this" without being specific about what this is. They are not malicious. They have read the same posts you have. They are just early and loud.

The genuinely useful AI person at work — the one whose projects ship — usually says less. What they understand is duller than agents, autonomy and the singularity: AI agents need loops, not magic prompts. The loop pattern getting the most attention right now has a faintly ridiculous name: the Ralph Loop.

In plain language, it is a way of telling an AI: keep working on this specific thing, in this specific place, until it meets this success standard. The rest is detail.

This guide is for the reader who is interested in AI, not stupid, not a developer, and tired of not knowing what half the words mean. By the end of it you should be able to walk into Monday's meeting with a small, safe experiment in mind — and explain it in a way that does not embarrass you.

The one-prompt fantasy

Most people still use AI the way they used Google in 2005: type a request, hope for a result, sigh, rephrase, try again. This works for short tasks. It collapses on anything that involves more than one step, more than one file, or more than one round of judgement.

The collapse is not really about the model being stupid. Real work is not a single question. A weekly report is not a single question; cleaning a year of expenses is not a single question. The model gets the first pass roughly right and then loses its place. This is the same drift we covered in our piece on context rot — long sessions fill up with stale instructions and abandoned attempts, and the agent ends up arguing with its own earlier output.

The workplace AI question, then, is not which model is best but how you keep the model on task long enough to finish. That is the job a Ralph Loop is built for.

What a Ralph Loop actually is

Strip away the jargon and a Ralph Loop is a small mechanism: a clear task, a written trail of what has been done, and an instruction to start again until the work is finished.

The agent receives the task. It works. It writes down what it did and what is still open. The loop runs the same instruction again. The agent reads its own notes, sees what is left, and continues — rather than starting from a blank page every time.

That last part is what makes it a loop and not a chat. In a chat session, every long conversation accumulates noise until the agent starts contradicting itself. In a Ralph Loop the conversation is short, but it runs many times, and the working memory lives in files the agent updates between runs. Each pass starts clean, reads the plan, does the next bit, updates the plan, stops.

The pattern was popularised by the developer Geoffrey Huntley, who described Ralph in its simplest form as "a Bash loop" — a tiny script that feeds an AI agent the same prompt until the task is done. Anthropic now ships an official Claude Code plugin based on the same idea, though practitioners disagree about which version works better. None of that matters at the level this guide cares about. The underlying technique is not technical — it is a way of organising work, and it applies to any task that can be broken into checkable steps with a written trail.

Why the name

It is named after Ralph Wiggum from The Simpsons — the earnest, stubbornly persistent child who just keeps going. The joke in developer circles is that this is sometimes what you want from an AI agent: not genius, but cheerful willingness to keep at the same problem until the result improves.

The name is a warning as much as a description. A Ralph Loop is patient and dumb on purpose, and you reach for it when the task is well-defined enough that you do not need cleverness so much as completion.

Why this matters if you do not code

A Ralph Loop started life as a developer tool. But the part of it that does the real work is not the code; it is the framing.

A non-technical professional running a Ralph Loop — whether through Claude Code, a no-code agent platform, or by carefully structuring a long ChatGPT or Claude session — does not need to write bash scripts. They need to answer five questions cleanly. Most of this guide is about those five questions, because most workplace AI failures happen when no one has answered them.

This is the emerging skill, and it has more to do with operations than coding. It is taking a piece of messy human work and turning it into something an agent can attempt, check, and improve on without supervision in the middle. The people who already write good briefs — editors, analysts, lawyers, ops managers, the middle managers who actually keep things running — tend to be good at it. The technical layer is the easy part to learn or delegate.

The five questions that make a loop work

Every workable Ralph Loop, technical or not, answers these.

What is the task, in one sentence? If you cannot write it in one sentence, the task is not ready for an agent. Break it down further before going near a model.

What does "done" look like? Not "a good report" — what specifically must be true when the agent stops. A filled spreadsheet. A summary under 200 words. Every row categorised or flagged. A drafted email in your sent folder. Done has to be checkable by someone who is not the agent.

What can the agent touch? Which files, which folders, which tools, which systems. Equally important: what it must not touch. The default answer for sensitive systems — payroll, customer PII, the live website — is nothing. A useful first loop almost always operates on copies in a sandbox folder.

How does it leave a trail? A file the agent updates each pass. A plan it ticks off. A log of decisions. Without this the loop has no memory between runs and you have no way to review what happened.

When does a human step in? Loops should not run unsupervised on anything that matters until they have run supervised, with you watching, several times. The "step-in" points should be explicit in the brief: flag and stop if X, otherwise continue.

These questions sound obvious. They are the ones the loud AI person at work tends to skip, which is why their experiments produce demos rather than outcomes.

A worked example: the messy weekly report

Take a non-threatening task and run those five questions against it. Every office has a version of this one.

You receive a CSV export from some internal system each Friday. It contains the week's customer issues. The columns are inconsistent. Some weeks have a priority field, some do not. Dates are in three formats. Half the rows have a category, the others have a free-text note that contains the category buried in a sentence. The current process is: someone spends an hour cleaning it and writes a one-paragraph summary for the Monday meeting.

The bad AI version of this task is one prompt: "Take this CSV and make it into a clean weekly report." You will get something. It will look plausible. It will be wrong in places you cannot see without checking row by row, which defeats the point.

The Ralph Loop version of the same task is unglamorous and works. You write, once, a short brief that answers all five questions:

  • Task: produce a weekly customer-issue report from the attached CSV.
  • Inputs: the CSV file, the format guide for what a clean row looks like, last week's published report as a style reference.
  • Working files: a plan.md tracking what has been done and what is left, a cleaned.csv containing rows the agent has normalised, a flags.md listing rows it could not classify confidently.
  • Each pass: read plan.md. Pick up where it left off. Normalise the next batch of rows. Update plan.md. Stop.
  • Stopping condition: every row in the CSV appears either in cleaned.csv or in flags.md, and a one-paragraph summary has been written using only data from cleaned.csv.
  • Human review: you read flags.md before the report is sent.

You run the loop. Between runs the agent does not need to remember anything — it reads the files. When it finishes you spend five minutes on flags.md, decide the edge cases yourself, and ship a summary you can audit. The whole thing takes longer to set up the first time and a fraction of the time every week after that.

The point is what you did not have to do: write code, pick a model, learn what a context window is. You wrote a brief an agent can actually execute against, with inputs, outputs, a stopping condition, and an audit trail you can spot-check.

Your first boring Ralph Loop — a Monday checklist
  • Pick one recurring, low-stakes task. Clean up this CSV. Format these slides against the template. Check these numbers against the policy. Draft these standard reply emails.
  • Create one dedicated folder. Put a copy of the inputs in it. Nothing the agent does should reach out of that folder.
  • Write a one-paragraph success definition and a short list of stop and flag rules.
  • Run it once with a human — you — watching the first two or three passes from start to finish.
  • Review the output and the trail of files together with one colleague. Decide what would have to be true to run it unattended next week.

If you cannot complete those five lines for a task, the task is not ready for a loop. That is information, not failure.

Where loops go wrong

The same patterns recur and they are mostly not about the technology.

The task was never a single task. "Improve the onboarding process" is not a Ralph Loop, it is a project. Loops handle the steps inside a project — draft the welcome email, audit the existing documents for inconsistencies, generate a checklist from the policy doc. The instinct to give an agent something big and vague is the most common single failure mode in workplace AI.

No stopping condition. Loops without a defined endpoint run until they hit a wall or run out of credits, neither of which is a useful place to stop. "Stop when every row is categorised or flagged" is a stopping condition. "Stop when it looks good" is not.

Too much access, too soon. The temptation is to give the agent the keys: production database, customer email, the company drive. The disasters in this category are mostly boring — an agent dutifully cleaning the wrong folder, an automated email going to a real customer instead of a test address. Start read-only; move to sandboxed write access only when you have watched the loop work several times; touch live systems only with explicit confirmation steps in place.

The agent fluently lies about progress. This is the uncomfortable one. Long-running agents can claim a step was done when it was not, particularly when they can no longer tell their own plan from their own notes. The fix is to make progress checkable in the files rather than narrated in the chat. If the agent says it cleaned 400 rows, the file should contain 400 rows. Trust the artefacts, not the commentary.

It was never going to be a loop. Some work is genuinely judgement-led from end to end — a sensitive personnel email, a strategic pitch, a piece of writing in your own voice. Trying to make these into loops produces sludge. The skill is partly knowing which work suits the pattern and which does not.

How to sound useful, not like an AI guru

Most of the difference between sounding informed and sounding ridiculous at work is a small number of phrases. Trade these in.

Do not say: We should deploy autonomous agents. Say: I think we can test one bounded loop on one low-risk task.

Do not say: The agent will handle the report. Say: The agent will prepare the first pass, write down uncertain rows, and a human will review the flags.

Do not say: The agent will handle the whole process end-to-end. Say: The agent will do the repetitive first pass and flag everything uncertain for us.

Do not say: This will replace manual work. Say: This will show us which parts of the work are repetitive enough to systematise.

Do not say: We need an AI strategy. Say: We need three or four small loops running reliably before we have anything worth calling a strategy.

Do not say: The agent is intelligent. Say: The agent is good at the parts of the work we can describe clearly.

None of this is humility theatre. It is a more accurate description of where useful AI work actually is. The people doing it well inside companies tend to sound like operations people rather than visionaries, and that is worth paying attention to.

How to pitch a Ralph Loop at work

The mistake non-technical AI enthusiasts make at work is overclaiming. They walk in with autonomous agents and AI workforce and deploying, and get the immediate, sensible scepticism such language deserves. The pitch that lands is much more boring:

I would like to try a controlled experiment on one specific internal task. The task has clear success criteria, no access to sensitive systems, a written audit trail, and human review at the end of each run. If it works, we can decide whether to extend it. If it does not, the cost is my time and a few API calls.

That is a memo a CFO will sign. It is also closer to what serious AI work looks like inside companies that are quietly doing well with it: a growing collection of small, observable, well-bounded loops, each one doing a single dreary task reliably.

Pick the task carefully. Good candidates for a first loop tend to be ones a human currently does in a repetitive way, where the inputs and outputs live in files rather than in someone's head, and where a wrong answer is recoverable. Weekly reports, document comparisons, draft-stage writing against templates, structured data clean-up, first-pass research synthesis — these all qualify. Work where the judgement is the work — promotions, hiring decisions, customer-facing positioning — does not. If your loop ends up needing to reach into other systems — calendar, CRM, the company drive — that usually means it is time to look at the MCP plumbing that lets agents read those tools safely.

The new workplace skill

Model leaderboards will keep moving and new agent frameworks will appear every month. None of that is the skill.

The skill is taking work that lives messily in someone's head and rewriting it as a loop another system can attempt, check and improve. It is closer to writing a clean process document than to writing code, and the people who turn out to be good at it are often not the ones the AI discourse expects — operations leads, middle managers who keep things running, ex-journalists, analysts trained to think in terms of inputs and outputs.

You do not become useful with AI by asking better one-off questions. You become useful by designing better loops. The unglamorous part is that this looks like the work that has always made organisations function: clear briefs, defined outputs, written-down decisions, deliberate review. The people who were already good at that work have an advantage right now, and the loud AI person at work tends not to realise it exists.

Start small. Pick one task. Run the loop by hand several times before letting it run unattended. Keep the trail in files you can read. When something goes wrong — and it will — those files are what tell you why.

The name Ralph Loop comes from a character known for stubborn, cheerful repetition, which turns out to be an underrated quality in a field where most demos give up at the first contradiction. The future of AI at work is not going to belong to the people with the most impressive demos. It will belong to the people who can design the smallest, clearest, most reviewable loops, and who know when to turn the agent off.