Compose small decisions before reaching for a generative model

Raymond Weitekamp demonstrates recursive decision models and sketches a voice-first computer interface.

RWRaymond WeitekampVortrag · OpenProse
Kanal
AI Engineer
Veröffentlicht
10. Nov. 2026
Video
51:48
Lesezeit
4 Min.
Folien
3
Original
Englisch
Auf YouTube öffnen
Beim Scrollen schrumpft das Video in die rechte untere Ecke und läuft weiter. Untertitel folgen Ihrer Lesesprache.
LesespracheIn 2 Sprachen verfügbar
Diesen Artikel gibt es noch nicht auf Deutsch, daher wird das Original (Englisch) angezeigt.
ZUSAMMENFASSUNG

In 30 Sekunden

Raymond Weitekamp explores whether tasks often given to a generative model can be organized as many fast judgments. His recursive decision model keeps context outside the model, lets decisions call other decisions and can combine with an LLM through a shared action map. Examples include hierarchical search, a game and a supervised audio prototype; an arbiter controls competing actions that might change shared state.

  1. 1A decision model can coordinate, not merely serve as a toolWeitekamp explores a decision-first root that can invoke generative models when needed.
  2. 2Hierarchical search narrows a large option spaceA category search selects branches rather than loading every category at once.
  3. 3A shared action map connects decisions and generationNamed options link descriptions to executable functions.
  4. 4Parallel decisions need a gate before changing stateAn arbiter chooses which proposed action may proceed.
  5. 5A small audio model learns when to respond quicklyThe Earshot prototype uses supervision and a separate trust decision.

Das Wichtigste

  1. Decision models select among options; code carries out the action.
  2. Recursive calls can narrow a search without presenting every option at once.
  3. Generation can extend an action map when predefined choices are insufficient.
  4. An arbiter can gate competing parallel decisions before they change state.
VOLLTEXT

Den bearbeiteten Text nach Kapiteln lesen

Nur das Transkript
01

Decision models and recursion

Weitekamp explains the decision-first architecture and its design rules.

Raymond Weitekamp introduces recursive decision models and his broader goal of an interface he calls Operating System One. He asks which tasks can be accomplished with many small decisions instead of continuous text generation.

He notes that names such as system-one model, decision model and zero-shot classifier are contested. In his framing, a model ranks or judges choices while code decides what action to take.

The central question is whether some behavior that appears to require extended reasoning can be organized as many fast, limited judgments.

His recursive decision model idea combines recursive language models with decision models. He contrasts open-ended generation, which expands possibilities, with choosing among available options.

A recursive language model can call smaller instances until a depth limit. Weitekamp applies a similar tree to decision calls and also considers combinations with ordinary agents.

A common pattern makes a decision model a tool for an LLM, for example to route a request or assess a tool call. His focus is the reverse: a decision model at the root, which may call an LLM when needed.

He revisits a Doom demonstration in which one decision composition handles immediate movement and another handles map exploration. Together they control a game-playing agent.

Weitekamp sets three design rules: keep context outside the model so code can slice it; allow decisions to invoke further decisions; and first make the system work without generation while still allowing generative components to be composed.

Three rules for recursive decision models
FOLIE 1 / 3Three rules for recursive decision modelsContext stays outside, decisions can recurse, and the system can work without generation.
02

Search and game examples

Toy sorting, product search and game demonstrations illustrate repeated judgments.

A Galton-board analogy illustrates successive choices sorting items by properties. He calls it a toy example and notes that the same simple task could be done in one classifier call.

In hierarchical product search, a model chooses which branch of a large category tree to explore next rather than seeing all 12,000 categories at once. Code can choose how many candidates to follow.

Hierarchical search narrows a category tree
FOLIE 2 / 3Hierarchical search narrows a category treeThe demonstration follows selected branches rather than presenting all categories at once.

He shows visual search examples that repeatedly narrow an image region, while acknowledging that a capable vision model might solve some examples in one pass.

In a Factorio demonstration, the system identifies a problematic production line and an element to repair using decisions without a generative language-model call. He notes that its path through the game was not optimal.

03

Combine decisions with generation

A shared action map and an arbiter support more flexible coordinated behavior.

A decision-only system has a limitation: available actions must already be enumerated by an application, script or another component. It cannot invent arbitrary text on its own.

Weitekamp suggests that some games, browser interfaces and computer-use tasks expose actions that can be enumerated, making decision trees useful even without generation.

Generation can complement fixed decision trees by creating or modifying the available structure. He frames the two kinds of models as complementary rather than interchangeable.

A smart-home example expands a simple command into actions for rooms and devices. The decision system can select actions while a language model handles cases requiring generation.

He calls the shared interface between them a map: named options connect descriptions to functions, while the language model can add or revise entries as user behavior changes.

A map connects decisions to actions
FOLIE 3 / 3A map connects decisions to actionsNamed options link model-readable descriptions to code.

An arbiter governs which proposed actions may change shared state. This matters when several fast decision paths run speculatively in parallel and could otherwise collide.

He uses streaming audio as an example: several paths may form hypotheses before a sentence ends, and the arbiter decides when there is enough confidence to act.

The initial implementation used DSPy; he also describes a standalone Rust package for experimenting with the approach.

04

Toward a voice-first interface

Music experiments and a supervised audio prototype motivate the planned OSO project.

Operating System One is his longer-term effort to control computers with less physical strain. He describes discomfort from prolonged keyboard and mouse use.

He looks back at music experiments in which laptop sensors and the Princeton Laptop Orchestra turned gestures and devices into instruments. This was also how he learned programming and machine learning.

In his Earshot prototype, one layer transcribes audio and selects an action while a tiny model learns to map short audio slices to the same actions.

A teacher supervises the small model, and another decision layer determines when its predictions are trustworthy enough to use. In his demonstration, the response becomes faster as it learns.

He mentions a separate local visual-classification experiment to illustrate that small models can support responsive interfaces beyond audio.

His planned OSO computer-use agent starts with voice, uses decision-first coordination and can hand suitable tasks to ordinary coding agents. He says the project is not yet ready.

The longer-term idea is to learn user preferences and move familiar decisions to smaller, faster models when the system has enough evidence to trust them.

Weitekamp invites viewers to explore the recursive decision model implementations and follow the OSO project.

Mehr aus diesem Kanal

4 Folien26:49EN
AI Engineer· 11. Nov. 2026Ara Khan: Choose work that improves with AI without being replaced by itAra Khan · ClineCline’s Ara Khan explains an automated evaluation loop and urges engineers to pick problems that benefit from model progress.Coding-AgentenEvals & ObservabilityCareers
4 Folien38:50EN
AI Engineer· 10. Nov. 2026LinkedIn’s self-improving agent first had to fix its judgesZiwei Guo, Saloni Gandhi · LinkedInA prompt-optimization loop improved a career agent, but unreliable evaluators required human calibration first.Agent EngineeringEvals & ObservabilityAgent orchestration+1
12:48EN
AI Engineer· 10. Nov. 2026Brian Douglas: Turn agent corrections into reusable review knowledgeBrian Douglas · Paper ComputeThe Paper Compute developer captures expert pushback in coding sessions and tests ways to reuse it during review.Coding-AgentenEntwicklungs-Workflows & TestsSoftware engineering+1
Folien12:20EN
AI Engineer· 10. Nov. 2026Ayush Bhardwaj: Agent workarounds are feedback for your CLIAyush Bhardwaj · Allos AIAn audit of coding sessions shows where output, errors and stale instructions force agents to improvise.Coding-AgentenEntwicklungs-Workflows & TestsAgent Engineering+1
5 Folien12:57EN
AI Engineer· 10. Nov. 2026Harvey’s agents scaled until their platform and merge queue brokeJoey Wang · HarveyAfter an alert spawned 900 agents and one engineer launched 950 tasks, Harvey added deduplication and fair scheduling.Agent EngineeringAgent orchestrationDeveloper productivity+1
Folien23:00EN
AI Engineer· 10. Nov. 2026A passing PR check needs evidence tied to the submitted codeStephen Chin, Cassandra Chin · Neo4jStephen and Cassandra Chin show how Tracetoon connects agent traces, code changes and checks before writing a reviewable pull request.Coding-AgentenEntwicklungs-Workflows & TestsSoftware engineering+1