Reasoning as a systems problem

Language models are unreasonably good at looking at something they have never seen and saying what the things in it probably are. They are also remarkable translators. They move between an informal description, a mathematical formulation and a program. We should use this for everything it is worth.

Somehow we have also come to expect this one form of intelligence to do all the thinking. A prediction, a calculation, a search, a plan: put it all in a transcript and ask the model to reason harder. When it fails, add instructions. Post-train some more. Give it more tokens.

A prompt cannot enforce control flow, a model's chain of thought is not a proof, a transcript is not a world model, a verbalized plan is not an executable recipe, a plausible hypothesis is not an explanation. Each pair is two different kinds of computation, and they need not all be the job of a single language agent.

Cortex is all about these algorithmic complements to LLMs. We use models for what they do remarkably well, and add in other forms of computation that cannot be left to semantic intelligence. Our bet is that the system around the model will become an increasingly important part of machine intelligence, and that better models make it more valuable.

A reasoning engine

There is a layer here worth building: one that constructs an understanding of the task, makes it executable, and knows to revise it when the world disagrees. It uses language models alongside solvers, specialized models and programs, and carries forward what it learns. Somebody has to do this work. We intend to make it something developers can buy and build on, instead of rediscovering it in each application. It is easy to mistake this layer for things that already exist.

We call Cortex a reasoning engine, and its design a cognitive architecture. A harness is too small a description. If the work amounts to arranging model calls, keeping a transcript and retrying failures, much of it will become standard infrastructure. Harnesses matter today: on ARC-AGI-3 the same model scored 62.7% with one harness and 99.9% with another.^[1] But thin harnesses will keep getting absorbed. What lasts is the representations and algorithms underneath.

Managed agents can provide the runtime including sessions, sandboxes and execution state. But managing the execution is not the same as determining what computation a problem requires. There is this belief that once we feed in enough context, letting the model manage it all and find the right path is the bitter-lesson-pilled thing to do. We disagree! Where sound theory exists for a critical decision, you cannot leave it to the vagaries of what the model happens to think at inference time.

Routers will play a useful role in intelligence per watt.^[2] But merely choosing which LLM answers a question doesn't go far enough. You can interpolate along the convex hull of the capability/cost curve, but that assumes LLMs are all we need. What if the question calls for a different kind of computation altogether? Recognizing that and constructing the computation is part of the intelligence.

We are not content with being an SDK that supplies primitives and leaves developers to stitch them together. Developers should supply the task, the environment and the operations they permit. The engine has to do more of the intellectual work, so that building agents becomes a science rather than a set of alchemical practices.

Verification is not enough

More training makes a model more likely to respect a rule, but more likely is not correct. Prompts are merely suggestions, so where we know how to enforce a property, we should enforce it. An execution system can require approval or refuse to allocate a resource twice. We need not keep asking a language model to remember. Unless it is proven, verification from evals is a weak guarantee.

In some narrow domains, verification is all you need. A proof formalized in Lean is checked by Lean itself, so a model with the checker in the loop can keep trying until the proof goes through. A program gets execution feedback on every attempt. When we have the full model of the problem and a goal we can measure, generate-and-check works. Beyond such narrow, verifiable domains, we are deluding ourselves. A SQL query can run without error and answer the wrong question. A support agent can follow every step it was given and still break a policy that nobody turned into a check. There is no checker for whether the agent understood the task.

So the work moves earlier. Learn the hard rules of the policy and enforce them directly. Find the rules that hold up across cases, not just the ones that pass today's evals. Learn the representation, so that what the system believes about the task can be read, run and revised. That is what makes an agent dependable, and dependability is what lets it take on harder work.

Make understanding executable

Consider an unfamiliar game. You see a colored grid and a few buttons. Nobody tells you the goal or what the buttons do, and yet people do fairly well. You try something, observe what changes, and develop a theory of the world.

A language model can do a surprising amount of this. What bothers us is that its understanding often lives nowhere. It is smeared across a transcript of thoughts, some tentative, some wrong, some revised three conversations ago. You cannot run it, check it, or hand it to the next step as a model of the game.

We want the model to commit to a belief about the world in a laconic abstraction, and revise it. It describes the objects, the actions and the consequences it expects. From then on code can do the predicting, checking and planning. When an observation contradicts the theory, there is something specific to change.

This extends beyond the program synthesis that coding agents can spit out. If we want to be correct, we need to synthesize the representation. Unbounded Python can express almost anything, including an elaborate misunderstanding. The right abstraction, a small language shaped to the domain, makes the theory amenable to solvers and planners. The recipes for this are in Programs and Abstractions for Reasoning.

None of this is new. Science works this way: we write down concise laws, test them, revise them, and carry forward what is durable. An agent investigating a codebase or a business process should also have an understanding we can read, run and revise.

Better models, better complements

Our bet does not require scaling to stop working. Better models will follow instructions more reliably and synthesize better programs, so each round of proposing, testing and revising gets shorter. We expect to throw away parts of Cortex as models improve. But program execution, search, formal verification and stateful control are not workarounds for weak models. They are different kinds of computation, and better models make them more useful.

Compilers are a useful precedent. We invested in languages, abstractions, optimizations and correctness because turning intent into efficient computation is a deep problem. Faster processors did not make that investment obsolete. Particular optimizations disappeared, but programmers still needed good languages and compilers. Consider the remarkable effect of MLIR, which made it practical to build compilers for new hardware from shared layers of abstraction. Can we throw away correct-by-construction machinery and let LLMs simply write PTX, NVIDIA's low-level GPU instructions, directly for our kernels? We think not. Correctness would stop at whatever we managed to test, and we would be playing whack-a-mole with each failure as it surfaced. Better progress comes from improving the abstractions, and the efficiency of each layer.

Agentic engineering has to mature the same way. Today too much depends on the taste of whoever assembled the prompts. We want assumptions made explicit, properties preserved through execution, and failures traced to the part of the reasoning that broke. Cheap code generation makes this more urgent: more candidate programs, and more ways to be wrong.

Different problems need different compute

Intelligence is getting cheaper and more varied. The inference cost of GPT-3.5-level performance fell more than 280-fold between November 2022 and October 2024, and open-weight models closed most of their gap to closed ones on some benchmarks.^[3] There are more kinds of models too: foundation models for prediction from tables and relational data, and models that recover text, tables and layout from documents or transcribe speech.^[4] Add databases, search, solvers and simulators, and we have a remarkable collection of compute. We should not insist on turning all of it into one long conversation with one model.

This is the intelligence per watt argument too: more correct answers from every watt. A good representation makes a problem amenable to search. A solver explores alternatives that would be impractical to narrate in a chain of thought. A synthesized procedure applies one discovery to thousands of cases.

Every layer of the supply chain specializes, from energy and lithography to chips, inference providers, frontier models and applications. The layer between the model and the application should too. The labs will improve their harnesses and models, and their advantage in training general models is substantial. However, no single model is the complete computational substrate for every task. The system should be bigger than any provider of semantic intelligence. Our commitment is to the task, whatever it calls for: a competing frontier model, an open specialist, a procedure we synthesized earlier, or an algorithm that needs no language model at all.

Compounding knowledge

Take an application investigating why a forecast changed. A useful engine would construct the calculation and its dependencies, propose explanations and test them. If an explanation depends on a join that duplicates records, it should expose and correct that assumption. The result should include an analysis the application can rerun as the inputs change.

There is more to keep than the answer: the procedure for catching that class of error, the conditions under which it applies, and the evidence that forced the revision. General methods can be developed and tested without moving one customer's records to another. This is where the investment compounds. Each method is specialized to its task. The machinery that builds and tests methods is shared, the way a compiler serves many programs because its abstractions capture structure they share.

We are working to show that these methods transfer: to unfamiliar tasks, across applications, and through improvements in the underlying models. Cortex on τ³-bench is a first result, and we explain elsewhere why we distrust language models doing all the work.

Language models provide a remarkable ability to recognize structure and propose what might work. A reasoning engine must own more and turn those into computations that can be executed, checked, revised and reused. We aspire to elevate intuition to testable experiments, experience to durable knowledge,^[5] and proposals to executable recipes, and to build the future of intelligence for reliable systems.

References

1. ARC Prize Foundation, ARC-AGI-3 leaderboard and "GPT-6 Astra" results post, September 2026, arcprize.org/blog/astra. Both runs used ARC Prize's own harnesses, Standard and Provider Adapter. ↩

2. Jon Saad-Falcon, Avanika Narayan et al., "Intelligence per Watt: Measuring Intelligence Efficiency of Local AI," arXiv:2511.07885, 2025, and the Hazy Research write-up at hazyresearch.stanford.edu/blog/2025-11-11-ipw. ↩

3. Stanford HAI, Artificial Intelligence Index Report 2025, takeaway 7, hai.stanford.edu/ai-index/2025-ai-index-report. The open-weight gap fell from 8% to 1.7% on some benchmarks within a year; convergence varies by workload. ↩

4. For example TabPFN and Kumo Relational for structured data, Mistral OCR for documents, and NVIDIA Parakeet for speech. ↩

5. Xuefei Julie Wang, Lauren Hyoseo Yoon, Chengrui Qu, Amanda Zichang Wang, Atharva Sehgal, Eric Mazumdar and Yisong Yue, "Knowledge-Centric Self-Improvement", arXiv:2607.19592, 2026: agents stay generic, and what improves is a shared, curated knowledge base. See also Yisong Yue, "Knowledge Flywheels". ↩