Everything Reduces to the Verifier
Search, self-critique, process supervision, reinforcement learning, replanning — every proposed remedy for long-horizon planning needs a checker that is better than the generator.
Search, self-critique, process supervision, reinforcement learning, replanning — every proposed remedy for long-horizon planning needs a checker that is better than the generator. Where one exists, agents work. Where one does not, nothing does.
Thesis. The literature on reliable long-horizon agents reads like a list of independent research directions. It is not. Strip each one to its mechanism and the same component appears: something that can tell a good candidate from a bad one. Best-of-n needs a ranker. Tree search needs a node evaluator. Reinforcement learning with verifiable rewards needs the verifiable reward. Process supervision needs step-level correctness labels. Replanning needs a detector of failure. Reflection needs a critic. In every case the agent’s reliability is bounded above by the quality of that component, and in every case the component is either supplied from outside at real cost, or supplied by the model itself — in which case the measured result is not improvement but collapse. The consequence is that autonomy is not distributed evenly across domains. It is concentrated precisely where a sound checker happens to exist: formal planning domains, code that compiles and passes tests, mathematics with a canonical answer, games with a simulator. Outside that set, the thing you would need to certify the agent’s work is the thing you were hoping the agent would do.
Abstract. I take the standard list of promising directions for long-horizon planning and show that each names the same missing component. I then set the evidence against it. Self-critique, tested against sound external verification on three domains, produces performance collapse — and ablation shows that the content of the critique barely matters, only the soundness of the accept-or-reject signal. Sound external verification produces large gains: from roughly a third to four-fifths on a classical planning domain, and from single figures to twenty per cent on a travel-planning benchmark where the unaided model scores 0.6%. But it has a ceiling: on the same domain with the names obfuscated, verification cannot help, because the generator can no longer propose a candidate worth checking. I then price the verifiers that do exist — eight hundred thousand human step-labels for the best-documented process reward model — and examine why the complexity-theoretic intuition that checking is easier than finding does not transfer to systems doing approximate retrieval. Three further results complete the picture: chains of thought systematically misrepresent the reasons for the answer, so verifying the stated reasoning verifies a story; reinforcement learning with verifiable rewards improves sampling efficiency without extending the reasoning boundary; and over very long horizons, where no verifier is watching at all, runs derail for reasons unrelated to memory capacity. Two figures. Eleven references.
I. The list is one item
Here is the standard catalogue of promising directions for reliable long-horizon agents: hierarchical planning, learned verifiers, neuro-symbolic architectures, process supervision, inference-time search, formal proof checking, adaptive computation, belief-state tracking, and explicit representation of goals, subgoals, invariants and failure conditions.
Read it again asking one question of each entry: what tells this system it is wrong?
Hierarchical planning decomposes a goal into subgoals — and needs something to confirm a subgoal was achieved before the next begins. Inference-time search generates candidates — and needs something to rank them. Process supervision rewards intermediate steps — and needs step-level labels, which are correctness judgements. Formal proof checking is a verifier. Learned verifiers are verifiers by name. Neuro-symbolic architectures are, in practice, a generator wired to a symbolic checker. Adaptive computation requires knowing when to stop, which requires knowing whether you are done. Belief-state tracking requires detecting when the belief has diverged from the world. Invariants and failure conditions are checks.
Nine directions, one component. This is not a rhetorical flourish; it is the load-bearing observation of the essay, and everything that follows is the evidence for what happens when the component is present, absent, or faked.
Figure 1. Every remedy names a verifier. What differs between the rows is not the sophistication of the method but the provenance of the checker — and the measured outcome tracks the provenance, not the method.
II. The formal statement says it too
Write the long-horizon problem the way control theory writes it. The agent seeks a policy maximising the expected discounted sum of rewards over a horizon, but it does not observe the true state; it maintains a belief over states, updates that belief from observations, and acts on the belief.
Three verification requirements are already inside that formalism, and they are usually read past.
The belief update is a check. Updating a belief from an observation means comparing what you expected to see against what you saw. An agent with no expectation cannot be surprised, and an agent that cannot be surprised cannot detect that its model of the situation has come apart. The update rule is not bookkeeping; it is the mechanism by which the world contradicts you. A system that generates its next action from a context window is not performing this comparison — it is conditioning on a transcript, which contains what happened but no record of what was predicted.
The reward function is a verifier. In the formal setting it is given, and everything downstream depends on it being given. Remove it and the objective is undefined; approximate it badly and you have optimised something else. In every real long-horizon deployment the reward is not available at the granularity the formalism assumes — it arrives at the end, if at all, and often as a human judgement made weeks later.
Deciding when to replan requires detecting that the plan has failed, which is a check against the plan’s own premises. Not “did the last action error” but “is the plan still capable of reaching the goal from here”. That question cannot be answered from the transcript either. It requires the plan to have been stored as something with conditions attached.
So the formalism assumes three things that the architecture does not supply: an expectation to compare against, a correctness signal at usable granularity, and a stored representation of the plan’s commitments. A language model plus tools approximates the acting part of that formalism accurately and the checking part not at all.
This is why the gap is not closed by making the generator better. The generator occupies one box in the diagram. The other boxes are empty, and filling them is a different kind of engineering.
III. The control experiment
The most optimistic version of the story is that the model can be its own checker. Generate a candidate, critique it, revise, repeat. This is the premise behind reflection, self-refinement, and most of what gets sold as an agentic loop.
It rests on an argument from computational complexity: verification is easier than generation, so a system that can generate imperfectly should be able to verify well enough to improve. Stechly, Valmeekam and Kambhampati set out to test this directly, across three domains — Game of 24, graph colouring, and STRIPS planning — with GPT-4, comparing the model critiquing its own answers against an external, guaranteed-correct verifier checking them.
The results, in their own summary: significant performance collapse with self-critique, and significant performance gains with sound external verification.
Collapse, not stagnation. The mechanism is worth stating because it is not obvious. In graph colouring, the system fails to recognise a correct colouring when it has produced one, criticises it, and revises it into a wrong one. Self-critique does not merely fail to add value; it destroys value that had already been generated, by rejecting correct answers. A checker that is worse than random on the cases that matter is not neutral. It is an active source of error, and it is applied precisely at the moment when the system had succeeded.
The ablation is the part that should end the argument. They also test whether the content of the criticism affects the outcome, and find that merely re-prompting with a sound verifier maintains most of the benefits of the more elaborate setups. In other words: the value of a critic loop is almost entirely in the binary accept-or-reject signal, and almost none of it is in the explanation attached. What the critic says is decoration. Whether the critic is right is everything.
That result reframes an entire genre of architecture. Systems that pass rich natural-language critiques between agents are optimising the part that does not matter, using a signal whose soundness nobody established.
IV. What sound verification actually buys
Set against the collapse, the gains from external verification are large and specific.
Figure 2. Soundness is bought from outside, and it has a ceiling. On Blocksworld, GPT-4 alone solves about a third of instances; with a plan validator supplying backprompts, performance reaches 82% within fifteen rounds. On TravelPlanner, where the unaided model scores in single figures, hand-built critics raise the final pass rate to 20.6%. On Mystery Blocksworld — the identical planning problem with the action and object names obfuscated — the same sound verifier is present and performance stays around 10%.
Take the middle case first, because the baseline is the more instructive number.
TravelPlanner asks a language agent to assemble a multi-day itinerary from a sandbox of nearly four million records, satisfying thirteen constraint checks — eight commonsense, five hard — with no partial credit. GPT-4 achieves a final pass rate of 0.6%. The benchmark’s authors note that agents struggle to stay on task, to use the right tools, and to keep track of multiple constraints simultaneously.
Now note what happened when Kambhampati’s group operationalised those constraints as explicit critics and put the model in a generate-test-critique loop: the final pass rate for GPT-4-Turbo went from 4.4% to 20.6%, and for the weaker GPT-3.5-Turbo the verified system surpassed the unverified GPT-4-Turbo baseline. Prompt-engineering approaches — chain of thought, ReAct, Reflexion — moved the GPT-3.5 baseline from 0% to 0.6%. The critics moved it by a factor of several.
That contrast is the argument in miniature. Better prompting of the generator: nothing. A checker: a different regime.
And observe where the improvement came from. Somebody wrote those critics. The budget constraint, the room-type constraint, the requirement that you cannot teleport between cities — each had to be turned into a piece of code that returns true or false. The gains are real and they are also an accounting entry: the reliability was imported, and someone paid for it.
V. The ceiling
The third pair of bars in Figure 2 is the one that stops this from being a story with a happy ending.
Mystery Blocksworld is Blocksworld with the action and object names replaced by meaningless tokens. For a classical planner this changes nothing whatsoever — the domain has identical structure, identical difficulty, identical solutions. For language models it is catastrophic. Across a range of frontier models evaluated on PlanBench, one-shot performance on Blocksworld ranges from roughly 11% to 48%, while on the obfuscated version the same models score between 0.4% and 4.3%; zero-shot, most score zero.
This is the cleanest available evidence that what happens in the unobfuscated case is closer to retrieval than to planning: remove the familiar surface and the capability goes with it.
And here is the point for the present argument. When you add a sound verifier to the obfuscated domain, performance reaches only about 10%. The verifier is exactly as correct as before. What has failed is the other half of the loop. A generate-test-critique architecture inherits its soundness from the critics and its completeness from the generator. If the model cannot propose a candidate worth checking, an infallible checker returns “no” indefinitely.
So verification is necessary and it is not sufficient, and the two failure modes are cleanly separable. Sound checker plus incompetent proposer gives you a system that is never wrong and never finishes.
VI. One calculation, and the verifier that was never called
It is worth seeing a case where the verifier is trivially constructible and simply absent, because it shows that the scarcity is sometimes architectural rather than economic.
In HeroBench, a model is given a structured world — seventy locations, twenty-five monsters, seventeen resource types, two hundred and eight items — and asked to defeat a target. Before it can plan anything it must solve a numerical sub-problem: find the minimal set of equipment that guarantees victory, where minimal means the character wins with the set and loses if any single item is removed. Answering it requires simulating turn-based combat across four elemental damage channels and their resistances, percentage amplifications, hit points and raw attack.
Two things about that sub-problem.
First, it is where the strongest models fail. Their execution error rates fall to a few hundredths of a mistake per task, while their failures concentrate on gear selection — the calculation performed before any action is taken. A wrong answer there produces a long, internally consistent, correctly executed plan that loses the fight.
Second, and this is the point: the combat simulator exists. The benchmark uses it to generate the tasks and to score the results. The rules are fully specified in the prompt. A checker for the gear calculation is perhaps two hundred lines of code, and it is deterministic, and it is exactly the thing that would catch the failure mode that accounts for most of the residual error at the top of the leaderboard.
The model does not call it. The architecture has no slot for it. The system is asked to solve a numerical optimisation by generating text about the numerical optimisation, and then to build a thousand-step plan on the result without ever confirming it.
That is not a limitation of language models. It is a design in which the checkable part was left unchecked. And it generalises: in most real workflows some fraction of the load-bearing claims are mechanically verifiable — an arithmetic total, a date consistency, whether a cited case exists, whether a schema validates — and the standard agent architecture verifies none of them, because it has no representation of which claims are load-bearing and no habit of asking.
The cheap verifiers are the ones nobody bothered to wire in.
VII. The price list
If sound verifiers are what makes agents work, the practical question is what they cost. The answer, in every case where one exists, is: a lot, and per domain.
A formal domain model. The plan validator used in the planning results checks a candidate against a specification of the domain — the actions, their preconditions, their effects. Somebody writes that specification. The same group has shown language models can help draft it, with human experts curating the result, which reduces the cost without eliminating it.
Hand-written critics. The travel-planning result required operationalising each constraint as executable code. This is entirely feasible and it is also, precisely, the domain knowledge that the agent was supposed to relieve you of possessing.
Human step-level labels. The best-documented learned verifier for reasoning is the process reward model of Lightman et al., which reaches 78% on a representative subset of the MATH test set under best-of-500 selection, substantially beating outcome supervision. The training set released alongside it, PRM800K, contains 800,000 human labels evaluating the correctness of individual reasoning steps. That is the price of a verifier in a domain where the final answer is already checkable. In a domain where it is not, the labels are more expensive, not less.
A simulator. The cheapest verifier is an environment that simply runs the plan and reports what happened. This is why the most informative long-horizon benchmarks are games: HeroBench’s models emit an entire plan as executable code, and the environment executes it and scores it. Ground truth, for free — because the domain is a piece of software somebody wrote for the purpose. That verifier does not transfer to a client’s business, and its availability in the benchmark is a fact about the benchmark, not about the agent.
Notice what unifies the list. Every entry is a piece of specification — an explicit statement of what correctness means in this domain. That artefact is expensive because writing it is most of the intellectual work. Which sets up the uncomfortable observation in the next section.
VIII. Why “checking is easier than finding” does not transfer
The intuition underneath self-critique is respectable: for many problems, verifying a proposed solution is asymptotically cheaper than finding one. This is the whole content of the P-versus-NP framing, and it is why we expect proof-checking to be easier than proof-finding.
The intuition fails here for a reason that is easy to state and hard to escape. The complexity result is about algorithms operating on a specification of correctness. Checking a Sudoku solution is cheap because you have the rules of Sudoku. Checking a proof is cheap because you have the inference rules. The asymmetry lives in the availability of the checking procedure, not in some general property of the universe by which wrongness is more legible than rightness.
A language model does not have the specification. It has a distribution over text. As Kambhampati and colleagues put it, the complexity of the reasoning task should be irrelevant to model performance to the extent that what the model is doing is approximate retrieval — and there is no reason to expect a system trained on correct data to be good at criticism unless it was also trained on corrections data. Nothing in the training objective creates the generation-verification asymmetry, so nothing in the behaviour exhibits it.
This also explains why the results split so cleanly by provenance rather than by method. A sound verifier has the specification, by construction, because someone wrote it down. A model asked to critique has the same distribution it had when generating, applied to a slightly different prompt. The second is not a weaker version of the first. It is a different kind of object wearing the same name.
IX. The reasoning is not the reason
There is a further problem with verifying what the model says, and it is worse than the verifier merely being weak.
Turpin, Michael, Perez and Bowman tested whether chain-of-thought explanations describe the process that produced the answer. Their method is elegant: add a biasing feature to the input — for instance, reorder a few-shot prompt so that the answer is always option (A), or supply a suggested answer — and see whether the model’s stated reasoning mentions it.
It does not. Models systematically fail to mention the biasing feature, and instead produce explanations rationalising the biased answer. Accuracy on a suite of thirteen BIG-Bench Hard tasks drops by as much as 36.3% under one of these biases, with the explanation never referring to the cause of the change. On a social-bias task, the explanations justify stereotype-consistent answers while weighting the evidence inconsistently and never naming the stereotype.
Read that alongside the self-critique results and the picture is coherent. The artefact you would naturally hand a verifier — the chain of thought — is not a record of the computation. It is a plausible narrative generated alongside the answer, sensitive to features it does not report. A critic that reads it is checking a story about the work, not the work.
This is the precise mechanism behind the complaint that models produce “convincing rationalisations rather than causally effective plans”. They are not being careless. The rationalisation is well-formed and often internally sound; it simply is not the reason.
X. What the generator can offer
Verification bounds the system from above only if the generator can reach the answer at all. Two results bound the other side.
The first concerns what happens under composition. Dziri and colleagues studied three tasks with clean compositional structure — multi-digit multiplication, logic grid puzzles, and a dynamic programming problem — formulating each as a computation graph so that complexity can be measured rather than asserted. Across all three, performance declined from near-perfect to zero as complexity increased, and the error analysis found that models perform single-step operations correctly while failing to plan and compose several of them. Their conclusion is that transformers solve compositional tasks by collapsing multi-step reasoning into linearised subgraph matching, with success tied to having seen substantial portions of the required computation graph during training.
That is the “skills do not compose” problem with a mechanism attached. It is also a statement about the proposal distribution: as the required composition deepens, the probability that the generator proposes anything correct falls toward zero, and no verifier changes that.
The second concerns whether training against a verifier expands what the generator can propose. Reinforcement learning with verifiable rewards is the most credible current answer, and Yue and colleagues probed its limits using pass@k at large k across model families, RL algorithms, and mathematics, coding and visual-reasoning benchmarks. Their finding: RLVR-trained models beat their base models at small k, but base models achieve higher pass@k when k is large, and the reasoning capability boundary often narrows as training progresses. Coverage and perplexity analyses indicate the reasoning paths produced by the RLVR model were already present in the base model. By contrast, distillation from a stronger teacher did introduce new patterns.
The interpretation the authors offer is that current RLVR improves sampling efficiency towards paths the base model could already find, rather than eliciting new ones. For the present argument: training against a verifier makes the generator quicker to reach what it could already reach, and does not obviously widen the set of reachable things.
So the verifier bounds the system from above and the proposal distribution bounds it from below, and the current evidence says neither bound is moving quickly.
XI. Long horizons remove the verifier entirely
Everything above concerns tasks with a defined endpoint and a checkable answer. Extend the horizon and even that goes away.
Backlund and Petersson built a deliberately simple long-running scenario: an agent operates a vending machine, balancing inventory, placing orders, setting prices, paying daily fees. Each subtask is trivial. The runs exceed twenty million tokens.
Their finding is that performance has very high variance, and that all models have runs that derail — misinterpreting delivery schedules, forgetting orders, or descending into tangential “meltdown” loops from which they rarely recover. Claude 3.5 Sonnet and o3-mini manage the machine well in most runs and turn a profit; some runs beat the human baseline. And some do not, in the same configuration.
Two details matter more than the headline. First, they find no clear correlation between failure and the point at which the context window fills, which rules out the comfortable explanation that this is a memory-capacity problem to be solved by longer contexts. Second, the failure mode is described as going off on a tangent after encountering a problem and rarely recovering — which is exactly what happens when nothing is checking whether the current activity still serves the goal.
There is no verifier in that loop. There is no formal statement of what the agent is supposed to be doing that anything could check the current behaviour against. The environment reports outcomes, but nothing evaluates whether the policy has become incoherent, and by the time the numbers reflect it the agent is several hundred steps into a private grievance with a supplier.
That is what a long horizon does to the verification problem. It does not make the checker harder to build. It removes the moment at which a checker would naturally run.
XII. Rereading the difficulties
The standard list of what makes long-horizon planning hard, re-read as a list of verifier problems:
Compounding error. The uncorrected sequence is the problem: at 99% per step, five hundred steps leaves you under one per cent. The word doing the work is uncorrected. A sound check after each step converts the exponential into something manageable — the point of the calculation is not that agents are impossible but that unverified agents are.
Sparse terminal reward and credit assignment. This is a request for a verifier that acts earlier than the end. Process supervision is exactly that, and the eight hundred thousand labels are exactly its price.
Plans alter their environment, so premises expire. This is a request for invariant checking during execution: a statement of what must remain true, checked as you go. Note that it requires the premises to have been written down as separable propositions, which almost no agent architecture does.
Branching factors grow exponentially. Search needs a node evaluator, and its quality determines whether search helps or merely burns compute. Without one, “search” degenerates into sampling, whose ceiling is the proposal distribution.
Rationalisations rather than effective plans. Turpin’s result is the mechanism, and its consequence is that the natural verification target — the explanation — is the wrong artefact.
Skills do not compose. Dziri’s result is the mechanism, and it says the failure is in the generator, not in the checker.
External memory does not guarantee correct retrieval or update. A memory without a consistency check is a store of assertions with no one confirming they still hold. This is a verifier problem wearing a database costume.
Seven difficulties, one recurring component. That is either a coincidence or a diagnosis.
XIII. What follows for anyone building one
Build the checker first, and treat it as the deliverable. If the project cannot state, in executable form, what it would mean for the output to be correct, then it does not have a long-horizon agent project; it has a text-generation project with an unbounded liability. The order matters: a verifier written after the agent tends to be written to accept what the agent produces.
Do not let the model check itself and call that verification. The measured effect of self-critique in the domains where it can be measured is collapse. If a model-based critic is used, it must be for soft properties — style, preference, plausibility — with the hard correctness claims resting on something sound. Soundness is inherited from the critics, and a system whose critics are all approximations has no soundness to inherit.
Report the verifier alongside the score. What checked the output, what specification it embodies, who wrote it, and what class of error it cannot catch. A benchmark result obtained in a simulator is a result about a system that had a free oracle; deployment does not.
Instrument the failure attribution. Whether a failure came from the proposal or the check is the single most useful bit in the whole evaluation, and it is nearly free to record. Without it you cannot tell the Blocksworld case from the Mystery Blocksworld case, which need opposite investments.
And do not confuse acting with planning. The ability to invoke a tool is not the ability to bring about a state of affairs. A system that can call an API and a system that can guarantee the sequence of calls achieves the goal are separated by exactly the component this essay is about.
XIV. What would show me wrong
If self-verification improved with capability — if the collapse observed on GPT-4-era models turned into a genuine gain on current reasoning models, tested the same way with the same ablation — then the central asymmetry has closed and most of this argument goes with it. The experiment is cheap and I have not seen it run to that standard on the newest systems.
If learned verifiers transferred across domains — if a reward model trained on step-level labels in mathematics gave usable correctness signals in law or logistics — then the per-domain cost that dominates my price list becomes a one-off, and the economics change completely. Whether verification generalises better than generation is an empirical question, and a decisive one.
And if the derailments over very long horizons turned out to be a solved problem under a well-designed monitor — a cheap outer loop that checks goal-coherence periodically and restores it — then Section XI describes an omission rather than a limitation. That would be good news and it is testable directly, because the benchmark exists.
XV. Coda
The reason agents work in coding is not that code is easy. It is that code has a compiler, a test suite, and a runtime that says no. The reason they work in competition mathematics is that the answer is checkable. The reason they work in games is that the game is a simulator, which is a verifier with graphics.
Those are not three separate success stories. They are one success story about the availability of a checker, told three times.
The genuinely hard cases — the multi-day technical project, the legal strategy, the research programme, the business run over a year — are hard for one reason above all the others: nobody can say cheaply and mechanically whether it is going well. That is why we pay experts to judge them, and it is why an agent operating there has no source of correction and no way to know it needs one.
An agent that could complete unfamiliar multi-day work with bounded failure probability and competent replanning would have to carry its own account of what correct means, keep it separate from the narrative it generates, and check itself against it rather than against its own fluency. Nothing in the current architecture does that. Until something does, the honest description of a long-horizon agent is: a generator, plus whatever checker you were able to afford.
References
-
Anokhin, P., Khalikov, R., Rebrikov, S., Volkov, V., Sorokin, A., & Bissonnette, V. (2025). HeroBench: A Benchmark for Long-Horizon Planning and Structured Reasoning in Virtual Worlds. arXiv:2508.12782.
-
Backlund, A., & Petersson, L. (2025). Vending-Bench: A Benchmark for Long-Term Coherence of Autonomous Agents. arXiv:2502.15840.
-
Dziri, N., Lu, X., Sclar, M., Li, X. L., Jiang, L., Lin, B. Y., West, P., Bhagavatula, C., Le Bras, R., Hwang, J. D., Sanyal, S., Welleck, S., Ren, X., Ettinger, A., Harchaoui, Z., & Choi, Y. (2023). Faith and Fate: Limits of Transformers on Compositionality. Advances in Neural Information Processing Systems 36 (NeurIPS 2023, Spotlight). arXiv:2305.18654.
-
Gundawar, A., Verma, M., Guan, L., Valmeekam, K., Bhambri, S., & Kambhampati, S. (2024). Robust Planning with LLM-Modulo Framework: Case Study in Travel Planning. arXiv:2405.20625.
-
Howey, R., Long, D., & Fox, M. (2004). VAL: Automatic plan validation, continuous effects and mixed initiative planning using PDDL. 16th IEEE International Conference on Tools with Artificial Intelligence, 294–301.
-
Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., Saldyt, L., & Murthy, A. (2024). Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks. Proceedings of the 41st International Conference on Machine Learning, PMLR 235. arXiv:2402.01817.
-
Lightman, H., Kosaraju, V., Burda, Y., Edwards, H., Baker, B., Lee, T., Leike, J., Schulman, J., Sutskever, I., & Cobbe, K. (2023). Let’s Verify Step by Step. arXiv:2305.20050. (PRM800K dataset: 800,000 step-level human feedback labels.)
-
Stechly, K., Valmeekam, K., & Kambhampati, S. (2025). On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks. 13th International Conference on Learning Representations (ICLR 2025), 8097–8150. arXiv:2402.08115.
-
Turpin, M., Michael, J., Perez, E., & Bowman, S. R. (2023). Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. Advances in Neural Information Processing Systems 36 (NeurIPS 2023). arXiv:2305.04388.
-
Valmeekam, K., Marquez, M., Olmo, A., Sreedharan, S., & Kambhampati, S. (2023). PlanBench: An Extensible Benchmark for Evaluating Large Language Models on Planning and Reasoning about Change. Advances in Neural Information Processing Systems 36, Datasets and Benchmarks Track.
-
Xie, J., Zhang, K., Chen, J., Zhu, T., Lou, R., Tian, Y., Xiao, Y., & Su, Y. (2024). TravelPlanner: A Benchmark for Real-World Planning with Language Agents. Proceedings of the 41st International Conference on Machine Learning. arXiv:2402.01622.
-
Yue, Y., Chen, Z., Lu, R., Zhao, A., Wang, Z., Yue, Y., Song, S., & Huang, G. (2025). Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model? Advances in Neural Information Processing Systems 38 (NeurIPS 2025). arXiv:2504.13837.