Smashing Intelligence into a Million Pieces: MAKER and Million-Step LLM Reliability

Key claims (up front, so we can argue about them later)

• If you need a system to execute hundreds of thousands to millions of dependent actions, then per-step error rates in the usual “looks pretty good on a benchmark” range are effectively indistinguishable from guaranteed failure.
• The MAKER framework suggests that instead of training a single heroic model that never blinks, you can achieve near-algorithmic reliability by smashing the task into tiny micro-steps and wrapping each step in cheap, classical error correction.
• With that recipe – maximal decomposition, sequential voting, and aggressive red-flagging – a modest, non-reasoning model can execute the full 20-disk Towers of Hanoi solution (1,048,575 moves) without a single wrong move.
• Under sane assumptions, the expected cost to maintain high reliability scales like
  

  

  where is the number of logical steps. This is uncannily close to the kind of guarantees we take for granted in classical algorithms – and very far from the usual “we tested it on 500 questions and it seemed fine” LLM story.

• The catch is non-trivial: MAKER is about execution, not insight. You still need a good high-level strategy and a sensible way to decompose it. The framework doesn’t magically invent the architecture; it just keeps the bricks from crumbling.

Everything that follows is basically me defending these claims, picking at their assumptions, and asking how far the underlying ideas can be pushed before the entropy catches up.

1. Long-horizon reliability is not just “more of the same”

We’ll start with the obvious, because ignoring it has doomed a lot of LLM projects: the tyranny of multiplicative error.

Most model evaluations implicitly live in the “one-shot” or “few-shot” world: we ask a model to answer a question, solve a math problem, or write a function. If it’s right 80–95% of the time, we call it good and move on. The fact that it fails 1 time in 5 or 1 time in 20 barely registers – we shrug, rerun, or ensemble. We are fundamentally terrible at intuitively grasping exponentials.

But the moment you want to chain model decisions, the arithmetic quietly turns adversarial. Suppose each step succeeds with probability , and you need dependent steps all to be correct. Then the success probability for the whole pipeline is

Everyone knows this in principle, but it’s worth plugging in numbers to feel the visceral reality of it:

• If (which would be outrageously good on most current benchmarks) and , then . That means the process basically never succeeds end-to-end.
• If and , then
  

  

  which is spiritually “zero”, in the same way that your chance of spontaneously tunnelling through a wall is “zero”.

The immediate implication: pushing per-step accuracy from, say, 95% to 99% doesn’t even begin to address the million-step regime. The curve is unforgiving.

This is the core lesson behind the “Illusion of Thinking” work on Towers of Hanoi and similar tasks: models that look impressively “reasoning-capable” on short puzzles disintegrate as you crank the horizon. They do not degrade gracefully; they fall off a cliff.

Once you see this clearly, you have two options:

1. Try to train a model with so close to 1 that stays usable even when is huge (good luck with that).
2. Change the architecture so that you never demand a million dependent steps from a single uncorrected stochastic process.

MAKER picks option (2). It abandons the hope of perfection in the component for resilience in the system.

2. Towers of Hanoi as a deliberately hostile benchmark

To understand what MAKER is doing, you need a concrete adversary. The authors choose Towers of Hanoi, which is perfect for this role.

• There are three pegs and disks of distinct sizes, initially stacked on peg 0 from largest at the bottom to smallest at the top.
• You may move one disk at a time, and you may never place a larger disk on top of a smaller one.
• The goal is to move the stack to peg 2.
• The optimal solution has length . For , that’s 1,048,575 moves.

This setup has two key properties that are extremely unfriendly to sloppy models:

1. The overall plan is simple and fully known: there’s a standard iterative or recursive strategy that any CS undergrad can implement. There’s no excuse for “creative interpretation.”
2. The process is brittle: one incorrect move breaks the solution. For evaluation, if you ever violate the rules or diverge from the intended trajectory, the run is a failure.

Previous work has shown that naïvely prompting even strong “reasoning” models to output the entire move sequence works for maybe 5–6 disks before reliability collapses. You can give them hints, have them self-critique, or add chain-of-thought; it doesn’t matter. At some point, with a million moves in play, a blink is effectively guaranteed.

MAKER’s contribution is not to find a smarter Hanoi strategy (there isn’t one) but to build an architecture where the strategy is fixed, and the model’s job is reduced to something much more humble:

Given the current state and the last move, what is the very next legal move under the agreed strategy?

This is the first big idea: radically scope down what any single call to the model is responsible for.

3. Massively Decomposed Agentic Processes (MDAPs): from monoliths to microagents

The paper’s umbrella term for what it’s doing is Massively Decomposed Agentic Processes (MDAPs). The philosophy reduces to:

Don’t build one big agent that does everything; build a huge swarm of tiny agents that each do almost nothing – and then error-correct them.

It is Digital Taylorism applied to inference. In the specific MAKER instantiation, this breaks down into three main pieces:

1. Maximal Agentic Decomposition (MAD) – one logical action per microagent.
2. First-to-ahead-by- voting – sequential error correction at each micro-step.
3. Red-flagging – aggressively discard responses that look structurally wrong or off-distribution.

You can think of MDAPs as an answer to the question: “What if we treated LLMs as noisy arithmetic units and wrapped them in the same kind of redundancy and voting we use for, say, spacecraft computers?”

Let’s go through each component.

4. Maximal Agentic Decomposition: one step, one agent

In a typical “agent” demo, we do something like this:

• Give the model the current state (maybe a long context with the entire history).
• Ask it what to do next, possibly along with an explanation.
• Append that to the log and repeat.

This has obvious issues. The context keeps growing; errors in earlier steps pollute later reasoning; and you’re implicitly asking the model to maintain a coherent long-range plan while being bombarded with its own previous outputs.

MAKER does the opposite. For Towers of Hanoi:

• A step is defined as a single legal move: .
• Each microagent is responsible for exactly one step and then disappears.
• The microagent sees only:
  • the current state (which disks are on which pegs, in stack order), and
  • the previous move.
• In addition, every microagent receives the same global strategy description: a concise English explanation of the iterative Hanoi algorithm (essentially, “move the smallest disk in a fixed cycle; every other move is the only legal move”).

So the job description for one microagent call is:

“Given this state, that previous move, and the global strategy, emit the next legal move and the resulting next state.”

No long context. No need to recall what happened 200 moves ago. No global memory of the entire run. Amnesia is a feature here.

This buys two things immediately:

1. Short prompts, limited confusion. The model’s attention is focused on exactly the information it needs; you’re not feeding it a novel-length log of previous thoughts.
2. A natural place to hook in error correction. Because each step is a small, self-contained decision, you can cheaply query the model multiple times, throw away suspicious responses, and vote.

The outer loop looks roughly like this (schematic, not production code):

from typing import Any

State = list[list[int]]  # pegs as lists of disk IDs
Move = tuple[int, int, int]  # (disk_id, from_peg, to_peg)


def maker_solve(
    initial_state: State,
    strategy_prompt: str,
    model: Any,
    k: int = 3,
    max_steps: int = 1_000_000,
) -> list[Move]:
    """Execute MAKER loop with first-to-ahead-by-k voting."""
    state = initial_state
    prev_move: Move | None = None
    moves: list[Move] = []

    for _ in range(max_steps):
        votes: dict[tuple[Move, tuple], int] = {}

        while True:
            response = call_agent(model, state, prev_move, strategy_prompt)
            if is_red_flag(response):
                continue  # discard malformed outputs

            move, next_state = parse_response(response)
            key = (move, tuple(map(tuple, next_state)))
            votes[key] = votes.get(key, 0) + 1

            # First-to-ahead-by-k: accept when leader is k votes ahead of all others
            if all(
                votes[key] - votes.get(other, 0) >= k
                for other in votes
                if other != key
            ):
                moves.append(move)
                state, prev_move = next_state, move
                break

    return moves

If you squint, this is just a fancy loop around model(...) with strict parsing and a little sequential test on top. There’s no magic. The interesting part is what happens when you run this a million times.

5. First-to-ahead-by- voting: basic probability, weaponised

Suppose that on any given step, a fresh microagent call returns the correct move+state pair with probability , and some incorrect candidate with probability . (We’ll start with the simplified two-candidate case.)

If we sample once, our chance of a correct step is just . But MAKER samples repeatedly, and accepts a candidate only when it’s ahead by votes. Intuitively, this is like watching two gamblers with a biased coin; the one with higher win probability will tend to pull ahead over time. It is signal extraction from a noisy channel.

This process is a classic biased random walk / gambler’s ruin setup. Under the simple two-candidate assumption, the probability that the correct candidate eventually wins the “first to a lead of ” game turns out to be

A few things to notice:

• If , then and shrinks exponentially in . So gets exponentially close to 1 as you increase .
• If , we’re doomed (as you’d expect): the “wrong” candidate is more likely to win.

Now apply this to an -step process, where we decompose into subtasks of size (so there are subtasks, and each subtask has its own voting process). Under reasonable assumptions, the full success probability looks like

The significant qualitative point is:

• With maximal decomposition (, one move per subtask), you can keep high while grows, by increasing only logarithmically in .
• The expected number of samples per step grows like , so the total expected number of model calls is
  

  

In other words: you trade extra inference calls (and thus money, and latency) for reliability, in a way that is analytically tractable and scales reasonably.

This is conceptually very different from just “sample 5 times and take the majority answer” at the entire-problem level. Here, voting is applied at the smallest possible unit of action, and the math connects the knob you turn () to the end-to-end reliability of a million-step process.

6. Red-flagging: using format as a sanity check

Voting assumes that each sample is a reasonably clean draw from some distribution where the correct candidate has probability . Real LLMs are messier: there are contexts where they go badly off the rails, hallucinate structure, or spew verbose thoughts that have little to do with the required format.

MAKER’s answer is red-flagging. Instead of trying to coax the model back into line with careful on-the-fly corrections, it treats certain output patterns as evidence that “the model is in a bad part of its state space”. Those samples are silently discarded. It’s an immune response.

In practice, a microagent is required to output something like:

move = [disk_id, from_peg, to_peg]
next_state = [[...], [...], [...]]

The system rejects a response if, for example:

• It’s longer than a token length threshold (too much explanation, irrelevant chatter).
• It fails strict parsing: malformed brackets, wrong number of entries, invalid disk IDs, etc.

Notice the philosophy here:

• We do not attempt to salvage malformed outputs by, say, running a regex or another model pass to clean them up.
• We treat structural failure as a hard signal that this sample should get zero weight in the voting process.

Empirically, this does two things:

1. It slightly increases , the per-sample probability that a retained output is correct.
2. It helps reduce correlated errors, where particular contexts systematically elicit wrong but superficially well-formed answers.

In a million-step pipeline, correlated errors are the real enemy: if a specific step has a much lower effective , it can dominate the cost (or cause failure) regardless of average behaviour elsewhere. Red-flagging is a blunt tool against this, but an effective one.

7. What actually ran: a million steps with a small model

All of the above is still just a nice story until you run it against reality. The authors do the obvious stress test:

• Task: 20-disk Towers of Hanoi ( moves).
• Decomposition: maximal (one move per microagent).
• Voting: first-to-ahead-by- with .
• Red-flagging: length threshold + strict JSON-like parsing.
• Model: a relatively small, non-reasoning model (gpt-4.1-mini).

They first estimate per-step error rates by sampling random individual steps from known Hanoi trajectories and checking whether the model emits the correct move and next state. One small but important empirical fact emerges: per-step accuracy is roughly flat in the number of disks.

That’s counterintuitive at first – shouldn’t “harder” puzzles be harder for the model? But with maximal decomposition, the local problem doesn’t change much as you scale the global depth. A move near the end of a 20-disk run looks like a move near the middle of a 10-disk run; in both cases, the local pattern and constraints are similar.

Given this roughly constant , the theory says we should be able to pick a moderate that keeps the full million-step run on the safe side of the reliability cliff, at the cost of some logarithmic overhead.

That’s exactly what happens:

• With , the system executes all 1,048,575 moves without a single error.
• For most steps, the voting process converges in just a few samples (often 2–3).
• A small tail of pathological steps needs many more samples – into the low double digits – which is where you see correlated difficulty.

They also try various open-source models (larger, smaller, different training recipes) and find that while a few have competitive per-step error rates, operational details like SDK reliability and rate limits make them less suitable for a million-call experiment. The key conceptual point is that nothing about MAKER requires a frontier “reasoning” model; if anything, a cheap, stable model with modest reasoning ability is ideal. Quantity has a quality all its own.

8. A picture of the architecture

Sometimes text overcomplicates what a simple diagram makes obvious. Here’s a compact view of MAKER:

Every loop through this diagram is tiny: the state description, previous move, and strategy prompt are short; the model is being asked a narrowly defined question; error correction is done at the smallest unit of action.

From a systems perspective, this is closer to a distributed algorithm than to the monolithic “agent” trope. And that’s the point.

9. Beyond Hanoi: can this help when the decomposition is unknown?

Towers of Hanoi is adversarial in length but trivial in structure: the optimal strategy is known in closed form, and the decomposition into moves is obvious. So an obvious objection is: isn’t this just a very complicated way to prove that we can reliably run a known algorithm using an unreliable component?

The paper anticipates this and explores a more interesting case: multi-digit multiplication. Here, the structure is still algorithmic but less trivial, and they do not hard-code the decomposition.

Instead, they define several specialised agent types:

• Decomposition agents: propose ways to split a problem into subproblems and a rule for recombining their results.
• Decomposition discriminators: vote among these candidate decompositions.
• Atomic solvers: handle base cases (small problems) directly.
• Solution discriminators: vote among candidate recompositions of sub-results.

The recursive skeleton looks like this:

from typing import Any

MAX_DEPTH = 10
N_SAMPLES = 5


def solve(x: str, depth: int = 0) -> str:
    """Recursively solve via MDAP-style decomposition and voting."""
    if depth >= MAX_DEPTH:
        return atomic_solve(x)

    # Propose decompositions and vote
    decomps = [decomposer(x) for _ in range(N_SAMPLES)]
    P1, P2, compose_rule = vote_decompositions(decomps)

    if P1 is None or P2 is None:
        return atomic_solve(x)

    # Recursively solve subproblems
    s1 = solve(P1, depth + 1)
    s2 = solve(P2, depth + 1)

    # Propose composed answers and vote
    candidates = [compose_candidate(compose_rule, s1, s2) for _ in range(N_SAMPLES)]
    return vote_solutions(candidates)

On 5×5 and 6×6 digit multiplication, this MDAP-style approach improves with higher and can beat a single-pass baseline. It’s not a state-of-the-art arithmetic system; that’s not the goal. The point is to demonstrate that even when the decomposition itself is model-generated and fallible, voting plus recursion can help.

There’s clearly a long way from this toy to “recursive theorem proving” or “multi-day project planning”, but it’s a non-trivial step away from hand-coded Hanoi.

10. How MAKER relates to existing reliability tricks

If you’ve built production systems around LLMs, much of this will feel familiar in isolation:

• Self-consistency / majority voting: sample multiple chains of thought and choose the majority answer.
• Constrained decoding: require JSON, use grammars, enforce schemas.
• Temperature ensembles: run multiple low- and high-temperature passes and reconcile.

MAKER is what you get when you industrialize these tricks:

1. Push those ideas to the limit (voting at the smallest granularity, harsh red-flagging).
2. Combine them with maximal decomposition so that each vote is cheap and local.
3. Actually do the math to connect per-step behaviour to end-to-end reliability.

A useful way to phrase the conceptual shift:

The LLM is a noisy primitive inside a larger algorithm, not the algorithm.

This is the same stance we take with physical hardware: we don’t expect a single transistor to be reliable; we build error-corrected memory, redundant systems, and protocols that tolerate flaky components.

In that sense, MAKER is almost conservative: it brings LLM-based systems closer to how we already know how to engineer robust infrastructure.

11. Where this shines – and where it probably doesn’t

I don’t think MAKER is a universal recipe. But there’s a recognisable regime where it looks very attractive.

11.1. Sweet spots

1. Long-horizon, brittle pipelines

   Anywhere a single mistake ruins the run – think formal verification, transaction processing, complex protocol execution, or multi-stage compliance checks – MDAP-style designs offer a principled reliability knob.

2. Deterministic or nearly-deterministic domains

   Hanoi is fully deterministic under a fixed strategy. Many real-world tasks are “deterministic enough”: ETL pipelines, code transformations, structured data workflows. There, “exactly one right next move” is a reasonable approximation.

3. Cheap-but-ok models

   Because each microagent’s job is tiny, you don’t need a giant high-end model per call. A small, steady model with per-step is sufficient; the slack can be taken up with .

4. Auditability and safety

   When each decision is small and structured, logs become meaningful. You can inspect the entire million-step run, locate contentious steps (where voting took many rounds), and post-mortem failures. That’s much harder with a single giant generation block.

11.2. Failure modes and limits

1. You still need a good decomposition

   MAKER takes the decomposition and high-level plan as given. In novel creative tasks, discovering the decomposition is often the hard part. MDAPs help you execute a plan; they don’t obviate the need for insight.

2. Non-local dependencies

   Tasks like writing a long essay, designing an API, or planning an experiment often require revisiting earlier choices in light of later considerations. It’s unclear how far you can get with a strictly feed-forward micro-step architecture.

3. Cost

   is mathematically nice, but for large the constant factors matter. A million-step job with multiple samples per step and red-flagging easily means tens of millions of tokens. That’s not free.

4. Pathological steps

   The empirical tail of steps that need many votes is a warning: some contexts are genuinely hard for the model. In those regions, you may need more than just voting – prompt randomisation, model ensembles, or fallback to different tools.

12. Microagents as the microservices of reasoning

One analogy that keeps coming to mind is microservices:

• Monoliths bundle all logic into a single massive process.
• Microservices split the system into many small services, each with a narrow responsibility, communicating over defined interfaces.

We’ve gone through the same transition in software architecture for reasons of scaling, team structure, reliability, and evolutionary change. MDAPs are, in some sense, microservices for reasoning:

• Each microagent has a narrow, well-specified contract (“given , produce in this format”).
• Failure is localised; we can retry, vote, or escalate at that boundary.
• We can swap out the underlying model for a given role as better ones appear.

If you are already building LLM-based systems with tools, orchestrators, and workflows, MAKER is an argument for pushing decomposition further than you probably find comfortable:

• smaller prompts,
• more specialised roles,
• more explicit error handling,
• voting and red-flagging as first-class citizens.

The extreme version in this paper – millions of one-step agents – is a useful parable even if you never plan to run Towers of Hanoi in anger.

13. My verdict: smashing is a feature

I started out sceptical of “LLM solves million-step puzzle” results, because they often involve moving the goalposts (“we allowed some errors but graded leniently”) or very carefully tailored prompts that don’t generalise.

MAKER feels different, because it is explicitly about system design under unreliable components. The headline demo – executing 1,048,575 perfectly correct micro-steps with a modest model – is interesting less as a party trick and more as a sanity check on the theory.

The real contribution, as I see it, is the stance:

• Treat language models as noisy primitives, not oracles.
• Decompose tasks until each call is brutally simple.
• Wrap those calls in the oldest tricks in the book: redundancy, voting, and strict interfaces.
• Do enough probability to know how changes at the micro level propagate to the macro level.

If you buy this, then “smashing intelligence into a million pieces” stops looking like an unfortunate side-effect of context windows and becomes a deliberate design choice. We don’t need a single unified agent that never blinks; we need systems built to survive the fact that it inevitably will.

MAKER, and MDAPs more generally, are one concrete step in that direction. We are simply building error-correcting codes for cognition.