Beyond Ralph Loops: orchestrate-map-reduce and Other Higher-Order Skills

In the Claude Christmas of 2025 – when tokens were effectively unlimited – I wrote a set of skills to ensure that agents, before interrupting my family time to present a solution, had first exhaustively explored the problem-solution space.
The core skill in this workflow is orchestrate-map-reduce. If a Ralph loop is an intentionally dumb orchestrator, orchestrate-map-reduce is intentionally complex.
For anyone not familiar with map-reduce, the core idea is that you take a set of things, apply a transformation to each one of those things (that's the "map" part), and then reduce that transformed set down to one final candidate.
You can see how given an unlimited token budget this kind of diverge-converge approach can save on a lot of back and forth with agents. Instead of reviewing at each stage, and asking agents to try different approaches, you just ask them to explore all the possible approaches in one go and then present you with the best one.
The really fun part (for me at least) is that orchestrate-map-reduce is a higher-order skill. In programming, a higher-order function is one that takes another function as an input. In agentic engineering, a higher-order skill is one that takes another skill as an input.
Why is this useful? Because any agentic loop that follows a diverge-converge approach can be neatly split into two parts:
- The general process of orchestrating sub agents to fanning out, each exploring a specific solution, and then consolidating those solutions into a final candidate solution
- Your specific instructions on how to diverge (current solution + new approach), and how to converge (criteria for picking the best candidate).
With this separation in effect, you can now create skills that leverage orchestrate-map-reduce to whatever ends.
Here's an example from my personal skill library that uses orchestrate-map-reduce to simplify a solution:

In anticipation of questions about what is this language, and where is the syntax highlighting coming from – that is an experimental project, MDZ. If you're interested in that, follow along – I'll share more in the future. Right now, I just want to draw out a couple of observations:
- Frontier LLMs respond well to programming syntax and explicit instructions. LLM programs (or "spells" as I like to call them) execute more reliably than conversational prompts, and provide more flexibility than deterministic workflows.
- Frontier LLMs are effectively turing machines capable of executing programs and tracking state. You can ask them to track the state of a long-running task in their "memory" and they'll generally do an absolutely fine job.
As a consequence, I've found the key to writing powerful agentic loops is treating LLMs as fuzzy runtimes, and using good ol' programming techniques – variables, loops, functional composition – to create more powerful prompts.
Thanks for reading! If you enjoyed this, subscribe for free to get next month's post delivered direct to your inbox.