Can algorithms control LLM reasoning better than LLMs alone?

LLM Programs embed an LLM within an algorithm rather than asking the LLM to be the algorithm. The critical design choice: instead of the LLM maintaining the current state of the program (its context), the LLM is presented with only step-specific prompt and context for each step. A classic computer program (Python) handles control flow, parsing of outputs, and augmentation of prompts for succeeding steps.

This is distinct from both Chain-of-Thought (where the LLM manages state through its token stream) and agentic frameworks (where the LLM decides what to do next). In LLM Programs, the algorithm structure is external and explicit, not learned or generated:

• LLM handles: isolated subproblems where its pattern-matching and generation capabilities excel
• Program handles: control flow, state management, output parsing, context filtering

The key benefit is information hiding. By concealing information irrelevant to the current step, each LLM call focuses on an isolated subproblem whose results feed future calls. This addresses two fundamental limitations:

1. Capability limits: Complex tasks that are currently too difficult because they require coordinating multiple reasoning steps
2. Architectural constraints: The finite context window restricts processing to what fits within it

The approach recognizes the LLM as a limited general agent and avoids further training. Instead, the expected behavior is recursively deconstructed into simpler steps the LLM can perform to a sufficient degree.

This connects to Can modular cognitive tools unlock reasoning without training? — both decompose reasoning into modular operations. But LLM Programs are more structured: the control flow is predetermined by the algorithm, whereas cognitive tools are flexibly invoked. It also extends Does separating planning from execution improve reasoning accuracy? — the program IS the decomposer, and each LLM call IS the solver, with clean separation enforced by architecture rather than training.

Decomposed Prompting as the software library formalization: Decomposed Prompting (Khot et al., 2022) makes the software library analogy explicit. The decomposer defines a top-level program using interfaces to simpler sub-task functions. Sub-task handlers serve as "modular, debuggable, and upgradable implementations" — if a particular handler underperforms, it can be debugged in isolation, replaced with an alternative prompt or even a symbolic system (e.g., Elasticsearch), and plugged back in. This is more general than least-to-most prompting: it supports recursive decomposition, non-linear structures, and mixed neural-symbolic pipelines. The key architectural insight is that sub-task handlers are shared across tasks, creating a reusable prompt library — the closest existing analog to how software engineers build with functions. Source: Prompts Prompting.