Toolboxes are not glamorous.

Nobody gives a keynote about the screwdriver. Nobody writes breathless think-pieces about the socket wrench. But when a complicated system fails, the difference between “genius” and “expensive confusion” is often whether the operator had the right tool, used it at the right moment, and trusted it to do the part humans should not pretend to do mentally.

That is the useful reading of Tool Building as a Path to “Superintelligence”, a new paper by David Koplow, Tomer Galanti, and Tomaso Poggio.1 Despite the title, the paper is not another mystical essay about machines waking up under a shower of scale. It asks a narrower and sharper question: when reasoning becomes long, does a model keep a stable probability of taking the correct next step?

The paper studies this through a quantity called $\gamma$ — gamma — the step-success probability. In the Diligent Learner framework, reasoning is treated as validator-guided search. A model proposes a next step; a validator accepts or rejects; the system continues. This looks reassuring until we notice the condition hidden inside the comfort blanket:

$$ \Pr[\text{the model proposes a good next step}] \geq \gamma $$

If $\gamma$ stays meaningfully above zero as the reasoning chain grows, search can remain manageable. If $\gamma$ decays with depth, test-time search becomes a very expensive way to watch the system slowly lose the plot.

The paper’s main contribution is a benchmark designed to measure that decay without letting models survive on shortcuts. The result is not simply “bigger models are better.” The more interesting result is that long-horizon success appears to depend on a system architecture: state, fresh evidence, validation, and tool-based execution. In other words, the path to “superintelligence” may look less like a scaling law and more like systems engineering. Deeply inconvenient for people who prefer one-axis charts.

The real question is whether gamma survives depth

The Diligent Learner idea is attractive because it turns reasoning into search with verification. The model does not need to be perfect at every possible path. It only needs to keep proposing good next steps often enough, while a validator prevents bad branches from consuming the whole process.

The relevant search cost in the paper’s framing is roughly:

$$ O\left(T_{\max} \cdot \frac{\log(T_{\max}/\delta)}{\gamma}\right) $$

Here, $T_{\max}$ is the maximum reasoning depth and $\delta$ is the target failure probability. The important part is not the formula’s decorative complexity. It is the denominator. If $\gamma$ is constant, the process can scale polynomially with depth. If $\gamma$ shrinks as the problem gets longer, the guarantee becomes increasingly theatrical.

This is where many reasoning benchmarks are too blunt. A model may solve a final problem while using memorized patterns, lucky shortcuts, alternative solution paths, or benchmark-specific regularities. That may be useful for leaderboard entertainment, but it does not isolate the stepwise probability that matters for search-based reasoning.

The authors therefore build a task where each step has exactly one correct continuation. No many-path generosity. No “close enough.” No hidden shortcut through familiar training examples. The model must recover the next term of a Boolean circuit, and the benchmark measures whether it can do that at increasing depths.

That is the gamma test: not “can the model answer this question once,” but “can it keep making the next correct move when the required state keeps growing?”

The benchmark makes the prefix act like a key

The task is based on Boolean circuit reconstruction over $GF(2)$, using Algebraic Normal Form. A target function is represented as an XOR of monomial terms. At step $g$, the learner has two inputs:

  1. the prefix — the circuit terms already revealed;
  2. new evidence — a fresh batch of labeled examples for the current step.

The next term is unique. To recover it, the solver must combine the prefix with the fresh evidence. Either source alone is deliberately insufficient.

The paper’s mechanism is easiest to understand as masking. The fresh data contains a useful signal, but it is hidden behind a mask produced by the already-revealed prefix. If the solver conditions on the prefix, it can subtract the mask and reveal the next term. If it ignores the prefix, the data looks statistically unhelpful. If it ignores the data, the history gives no information about the next support.

This is the clever part of the benchmark. It turns “reasoning” into a controlled test of state-conditioned evidence integration.

Benchmark component What it forces Shortcut it blocks Business analogue
Revealed prefix Maintain and use accumulated state Guessing from current data alone Workflow memory, case history, audit trail
Fresh evidence React to new step-specific information Extrapolating from history alone New document, transaction, customer input
Statistical obfuscation Combine prefix and evidence correctly Pattern matching from biased samples Data that only makes sense after reconciliation
Unique next term Measure exact step-success Multiple acceptable reasoning paths Deterministic process control
Validator Check each proposed step cheaply Drifting through invalid branches Rule engine, test suite, compliance gate

The result is intentionally artificial. That is not a weakness by itself. A synthetic benchmark is valuable when it isolates a mechanism that messy real-world tasks obscure. Here, the mechanism is whether the model can keep integrating a growing internal state with new observations.

A data-only solver fails because the samples are masked. A history-only solver fails because the next term is sampled independently. A partial solver fails increasingly as the depth grows, because using only some of the prefix leaves too much of the mask in place. Only the diligent solver — the one that uses both history and data — retains high step-success.

This is a benchmark about disciplined integration, not verbal cleverness.

Polynomial recoverability prevents the wrong excuse

A common escape hatch for disappointing model performance is to say the task is simply too hard. The paper closes that door rather carefully.

In Appendix B, the authors show that a diligent solver can recover the monomial in polynomial time. Once the prefix mask is removed, recovery reduces to identifying the unknown payload support from labeled examples. The paper gives a decoder based on residual labels and intersections over positive examples, then proves recovery under fixed-weight payloads with high probability under stated sample conditions.

That matters because model failure cannot be dismissed as “the task is impossible.” It is recoverable if the solver uses the available information correctly.

The failure mode is more specific: models do not reliably maintain and apply the growing prefix-conditioned cancellation. That is a more damaging result for long-horizon reasoning than mere failure on a hard puzzle. It says the model may have the information, the evidence, and a polynomially recoverable path — and still collapse because the computation is not stably organized.

For enterprise AI, this distinction matters. Many operational tasks are not impossible. They are just brittle when the model has to carry too much state internally while also deciding what to compute and then executing the computation. The correct diagnosis is not always “buy a bigger model.” Sometimes the correct diagnosis is “stop asking the model to be the database, the parser, the calculator, the validator, and the intern who pastes everything correctly.”

The estimator simulations show what real reasoning must combine

The paper first evaluates estimator classes with different information access.

The diligent estimator has both prefix and data. The data-only estimator sees new samples but lacks the prefix. The history-only estimator sees the prefix but lacks the new evidence. The partial estimator has incomplete access.

The result is clean. Only the diligent estimator keeps high $\gamma$ across depth. Data-only and partial estimators collapse toward low probability as depth and payload size increase. History-only remains at chance. The heatmaps extend this pattern across parameter settings, showing that imperfect-information estimators become unreliable as the problem grows.

This is main evidence for the benchmark design. It confirms that the task is doing what it is supposed to do: separating real prefix-plus-data reasoning from shortcut behavior.

Evidence item Likely purpose What it supports What it does not prove
Estimator curves Main benchmark validation Only history plus data sustains step-success That LLMs fail for the same internal reason
Estimator heatmaps across $p$ and $g$ Sensitivity / scaling test Imperfect information collapses as complexity grows That all real tasks have the same geometry
Non-adversarial appendix diagnostic Robustness / construction check The adversarial construction changes shortcut availability That adversarial sampling is the only useful benchmark design
Polynomial decoder proof Theoretical guardrail A diligent solver can recover the term efficiently That language models will naturally implement the decoder

The business reading is straightforward. A workflow that requires both accumulated context and fresh evidence should be evaluated at the step level. Final-answer accuracy is not enough. A system can look competent on short traces while its step-success probability decays quietly under longer operating histories.

That is how expensive automation failures often begin: not with a dramatic hallucination, but with a small state-conditioning error that propagates.

Small models behave like partial users of their own context

The paper then tests Qwen3-2507 variants: 4B-Instruct, 4B-Thinking, 30B-A3B-Thinking, and 30B-A3B-Instruct. The experiments use generated instances with $p=12$ and $d=4$, across depths $g \in {1,3,7,15,31}$.

The strongest small model performs better at shallow depths, especially the 30B thinking variant. But the pattern is still depth-sensitive. Performance drops sharply at intermediate depths and approaches the trivial baseline by the hardest tested setting. For $p=12$ and $d=4$, the model must identify a support of size $d-1=3$, so random guessing is about:

$$ \gamma_{\text{triv}} = \frac{1}{\binom{12}{3}} \approx 0.0045 $$

That is not a flattering neighborhood to retire into.

The effective-prefix analysis is especially useful. The authors fit model accuracy as if each model were using only $k$ of the $g$ revealed prefix terms. One fit assumes proportional scaling, $k=ug$; another assumes constant capacity, $k=v$.

The reported table favors proportional scaling for the Qwen3-30B-A3B-Thinking model, with $u=0.47$ and a large $\Delta$AIC in favor of the proportional model. The 30B instruct model has weaker scaling, with $u=0.15$. The 4B variants do not meaningfully distinguish the fitted forms.

A small caveat: the paper text near the results section appears to describe the 30B thinking model as using roughly $0.77$ of the prefix, while the appendix table reports $u=0.47$. The table is more explicit, so I would treat $0.47$ as the safer value unless a later revision clarifies the discrepancy. Either way, the interpretation remains the same: models are not fully using the prefix as depth grows.

This is not merely a context-window story. The paper notes that long contexts are required for consistent decoding, and the tested models have large context limits. The issue is not just whether the tokens fit. It is whether the model can operationally use the right parts of the prefix to cancel the mask at every step.

That is the gap between “has access to context” and “uses context correctly.” Enterprise AI buyers routinely confuse the two. Vendors do not always rush to correct them. How surprising.

Frontier models improve, but tools change the failure mode

The frontier-model tests are smaller because the runs are expensive. The paper evaluates GPT-5.2 with extended Thinking, Claude Opus 4.5 with max Thinking, and Gemini 3 Pro, using 60 queries per model across depths $g \in {31,63,127}$ with $p=12$ and $d=4$. Half the prompts instruct the model not to use tools. The other half allow any solution strategy, including tool use.

The frontier models do much better than the smaller Qwen models. At conditions where small models approach random performance, frontier systems still often solve the step with high probability.

But the sharper result is the tool split. Tool-enabled runs are much stronger and more stable over long horizons. No-tool runs degrade substantially as depth grows. The paper also notes a complication: Claude Opus sometimes appeared to use tool-like behavior even when instructed not to, inflating its no-tool score and making the contrast less clean.

This is why the result should not be summarized as “frontier models can reason.” That phrasing throws away the mechanism.

The paper’s interpretation is that each step has two jobs:

  1. infer the correct constraints from the prefix and evidence;
  2. execute the computation implied by those constraints.

Without tools, the transformer must perform both internally. With tools, the model can specify the computation and delegate execution to an external program. The effective algorithm becomes sparser. The system no longer relies entirely on the model’s internal weights to represent constraints, maintain state, and simulate execution.

That is the key systems-engineering lesson. Tools do not merely make the model “more powerful” in a vague productivity-deck sense. They move part of the computation into a more reliable substrate.

A calculator is not a smarter mathematician. It is a different failure surface.

The paper shows a mechanism, not a product recipe

The direct result is narrow:

The authors construct a GF(2) circuit-reconstruction benchmark where the next step is uniquely defined, shortcuts are blocked, and step-success probability can be measured. In that benchmark, small LLMs show depth-induced collapse. Frontier models perform much better, especially when precise tool use is allowed.

The Cognaptus inference is broader but should be stated carefully:

Long-horizon AI workflows should not be designed as pure conversation loops. They should be designed as systems where the model proposes, tools execute, validators check, and state is stored in external structures that can be inspected and repaired.

That suggests a practical architecture:

Layer Role in a long-horizon AI system Why it matters for $\gamma$
State store Keeps durable workflow memory Reduces reliance on fragile internal recall
Retrieval / evidence layer Supplies fresh step-specific data Prevents stale-history extrapolation
Tool execution Performs deterministic or structured computation Separates constraint selection from execution
Validator Rejects invalid next steps Prevents drift from becoming an accepted trajectory
Trace log Records decisions and intermediate states Enables debugging when step-success decays
Model policy Chooses constraints, plans, and tool calls Focuses the model on semantic control rather than raw execution

This is not glamorous. It is also probably where much of the value is.

The market often talks about “agentic AI” as if the agent is a personality with a browser. A better framing is that an agent is a control policy embedded in a tool-governed environment. The model is important, but the surrounding machinery determines whether the system can keep making correct next moves under depth, noise, and operational pressure.

In business terms, the important metric is not whether a model can impress in a short demo. It is whether the workflow maintains step reliability after 30, 60, or 120 state-conditioned operations. Gamma is not directly observable in most business settings, but the idea behind it is operationally testable: measure step-level correctness, not just final output satisfaction.

Where the result should not be overextended

The benchmark is synthetic. GF(2) circuit reconstruction is not invoice processing, legal review, procurement planning, or investment research. Real business tasks may be messier, but they may also be less adversarial than this benchmark. A document workflow often contains redundant cues; a customer-service case may tolerate several valid intermediate paths; a planning task may be judged by usefulness rather than exact next-step reconstruction.

The frontier-model sample is also limited. The authors report 60 queries per model, not a full-scale exhaustive benchmark. Tool-use comparisons are informative, but the no-tool condition is not perfectly clean when a model may still produce tool-like internal procedures or invoke hidden external mechanisms.

The paper does not prove that tools alone produce superintelligence. It also does not prove that current agent frameworks are reliable. In fact, it implies almost the opposite: tool use helps only when the system can call tools precisely, pass data correctly, validate outputs, and preserve state. A sloppy toolchain is just a new way to be wrong with more infrastructure.

The strongest conclusion is therefore architectural, not prophetic. If search-based reasoning depends on non-collapsing step-success probability, then model scale is only one part of the story. The rest is whether the system can keep the model from doing jobs better handled by external mechanisms.

The gamma lesson for AI builders

The paper’s title talks about “superintelligence,” but its most useful audience may be much more ordinary: people building AI systems that must work for more than one step.

A long workflow is not a long prompt. It is a sequence of state-conditioned decisions. Each decision requires the system to reconcile what has already happened with what has just arrived. If the model must carry all of that internally, performance may decay in ways that short benchmarks hide.

The practical lesson is not “replace reasoning with tools.” It is “stop confusing reasoning with unassisted mental execution.” The model should identify the constraint, choose the operation, and interpret the result. The tool should perform the operation. The validator should check whether the result is acceptable. The state store should remember what happened. The trace should make the whole process debuggable.

This is why the paper’s result is more interesting than another model ranking. It points to a failure mode that model comparisons alone cannot explain. Small models collapse because they behave like partial-information solvers. Frontier models improve, but their strongest long-horizon behavior appears when tools stabilize execution. The important variable is not intelligence in isolation. It is intelligence embedded in a reliable system.

Gamma, in this reading, is not just a Greek letter in a theory paper. It is a warning label for every AI workflow that says, “Don’t worry, the model has the context.”

Having the context is not the same as using it.

And using it once is not the same as using it correctly 127 steps later.

References

Cognaptus: Automate the Present, Incubate the Future.


  1. David Koplow, Tomer Galanti, and Tomaso Poggio, “Tool Building as a Path to ‘Superintelligence’,” arXiv:2602.21061, 2026. https://arxiv.org/abs/2602.21061 ↩︎