Transcription
A revolutionary new paper has just been published this month, November 2025, titled "Solving a Million-Step LLM Task with Zero Errors," coming out of the Cognizant AI lab. It directly confronts the single biggest failure mode we are all facing right now in the AI industry.
We have all seen the demos: AI agents that can write code, plan trips, or manage spreadsheets. They look incredible for the first 5 minutes. But have you noticed what happens when you ask them to do something long? When you ask them to migrate a database, or write a novel, or conduct a scientific experiment that requires hundreds of sequential steps, they fail. They drift. They hallucinate.
We usually blame the model, thinking, "Oh, if only GPT-5 were here." Or we blame the context window, thinking, "If only I could fit a million tokens in memory." This paper proves that we are looking at the problem entirely wrong.
The authors managed to get an LLM to execute a task requiring over 1 million logical steps without making a single mistake. And the kicker: they didn't use a super-intelligence we don't have yet. They didn't use a context window the size of a library. They effectively used no context window at all.
They achieved this through an architectural framework they call MAKER, or Massively Decomposed Agentic Processes. The implications of this are massive because it suggests that reliability is not a model capability problem. It is an engineering architecture problem.
To understand why this is such a big deal, we have to look at the brutal math of probability. This is the "why" behind every failed agent you have ever built. Imagine you have a state-of-the-art model that is 99% accurate at following instructions. That sounds production-ready, right? If your task has one step, you have a 99% success rate. If your task has 10 steps, you are down to about 90%. But if your task requires 1,000 steps, your probability of success is 99% to the power of 1,000. That number is effectively zero.
And real-world tasks—engineering, science, logistics—are not 10 steps long. They are thousands.
The researchers demonstrated this using a benchmark called the Tower of Hanoi. It is a recursive puzzle where you move discs between pegs without placing a larger disc on a smaller one. Solving it for 20 discs requires exactly 1,48,575 moves. When they tried to solve this with a standard monolithic GPT-4 agent, it failed almost immediately. Why? Because of context drift. As the conversation history grows, the model gets distracted by its own past outputs. It carries the weight of the entire history and eventually, it gets confused.
This is where MAKER comes in. The framework stands for Maximal Agentic Decomposition, and it is built on three pillars that completely invert how we usually build agents.
The first pillar is maximal decomposition. The core philosophy here is radical: do not let the agent remember the past. In a standard agent loop, you usually append the new action to the chat history list. In MAKER, you don't. Each step is treated as a brand-new, isolated problem. The agent receives the rules, the current state of the world, and the immediate goal just for that one step. It calculates the move, updates the state, and then dies. The next agent spins up, receives the new state, and repeats. Because the agent has no history of the previous 10,000 steps, it cannot get confused by them. The state object is the only memory that matters. This turns the agent from a conversationalist into a stateless function. It solves the context drift problem by simply removing the context.
The second pillar is what they call "red flagging." This is a fascinating insight into LLM psychology. The researchers found that when a model is about to make a logic error, it often makes a syntax error first, or it starts rambling. If you ask for a JSON object and the model gives you a paragraph of text talking about JSON, it is probably confused. If the model usually takes 100 tokens to answer but suddenly generates 500 tokens of "thinking," it is hallucinating. MAKER uses a strict parser. If the output isn't perfectly formatted, or if it's too long, it throws it away immediately. It doesn't try to repair the bad JSON. It treats the syntax error as a proxy for a logic error and forces a retry.
The third pillar, and this is the secret sauce that gets you to zero errors, is "first to the head" by K-voting. For every single step of the million steps, they don't just ask the LLM once. They ask it multiple times in parallel. They use a voting algorithm derived from the Gambler's Ruin problem in statistics. Let's say K=3. They sample answers from the model. If "move disk A" gets five votes and "move disk B" gets two votes, the difference is three. "Move disk A" wins.
The math in the paper proves that even if your base model is only 80% accurate, which is pretty bad, if you use this voting mechanism, you can push the composite accuracy of the system to 99.9999%. This is how they took a "fable" model and ran it for a million steps without a single mistake.
Now, I know what you're thinking: "That sounds incredibly slow and expensive. You want me to run a swarm of agents for every single step?" But this leads to the most important economic finding of the paper. They discovered a scaling law that changes the economics of AI.
They found that small models plus voting are actually cheaper than big models. We often assume we need the smartest model, like a high-end GPT-4 or Claude Opus, to solve hard problems. But those models are expensive. The paper proves that it is cheaper to ask a "dumb" small model like GPT-40 Mini or Llama 3 8B 10 times and vote on the answer than to ask a smart model once. Because of the decomposition, the task becomes simple: just one logical step. You don't need a genius model to solve one step; you just need a model that can follow a rule.
The researchers calculated that to get zero-error reliability, the cost scales logarithmically. That means solving a task that is 10 times harder doesn't cost 10 times more. It costs only a little bit more in terms of voting overhead.
So why is this paper from November 2025 so important? Because it gives us a blueprint for building software right now. If you are a developer, here is how you apply MAKER today:
First, stop relying on chat history as your state management. You need to define your atomic state. If you are writing code, the state is the file system and the compiler error log. If you are analyzing data, the state is the data frame.
Second, decompose your tasks to the micro-level. Don't ask an agent to write a function to calculate taxes. Break it down. Have one agent define the inputs. Have another agent write the signature. Have a third agent write the logic for one specific tax bracket.
Third, implement voting for critical steps. You don't need to vote on everything, but for critical decision points where a mistake would ruin the chain, spin up five parallel calls. If they disagree, that is a signal that the model is unsure.
This paper teaches us that reliability is an engineering problem. We don't have to wait for the model companies to solve hallucinations for us. We can solve them today by changing the architecture around the model. By treating LLMs as stochastic components—unreliable parts that need redundancy, verification, and strict inputs—we can build systems that are exponentially more reliable than the models that power them. This is the difference between a chatbot and an agent that can actually do work.
Thanks so much for watching. If you found this breakdown useful, please hit the like button and subscribe to the channel for more deep dives into the latest AI research. See you in the next one.